高性能，短URL服務，設計及實現！
為什么這里面的url都是短的呢?有什么好處呢?怎么做到的呢?
短url的好處有:
1、 短. 短信和許多平臺(微博)有字數限制,太長的鏈接加進去都沒有辦法寫正文了。
2、 好看. 比起一大堆不知所以的參數,短鏈接更加簡潔友好。
3、 方便做一些統計.你點了鏈接會有人記錄然后分析的。
4、 安全. 不暴露訪問參數。
這就是為什么我們現在收到的垃圾短信大多數都是短URL的原因了。
那么短URL是怎么做到的呢?
短URL基礎原理
短URL從生成到使用分為以下幾步：
1、 有一個服務,將要發送給你的長URL對應到一個短URL上.例如www.baidu.com -> www.t.cn/1。
2、 把短url拼接到短信等的內容上發送。
3、 用戶點擊短URL,瀏覽器用301/302進行重定向,訪問到對應的長URL。
4、 展示對應的內容。
本文主要集中于第一步,即如何將一個長URL對應到短URL上。
服務設計
如果你在往長短URL真實的對應關系上想,那么就走遠了。
最理想的情況是: 我們用一種算法,對每一個長URL,唯一的轉換成短URL.還能保持反向轉換的能力。
但是這是不可能的,如果有這樣的算法,世界上的所有壓縮算法都可以原地去世了。
正確的思路是建立一個發號器,每次有一個新的長URL進來,我們就增加一,并且將新的數值返回.第一個來的url返回"www.x.cn/0",第二個返回"www.x.cn/1"。
接下來以QA形式寫幾個小問題：
對應關系如何存儲?
這個對應數據肯定是要落盤的,不能每次系統重啟就重新排號,所以可以采用mysql等數據庫來存儲.而且如果數據量小且qps低,直接使用數據庫的自增主鍵就可以實現。
如何保證長短鏈接一一對應?
按照上面的發號器策略,是不能保證長短鏈接的一一對應的,你連續用同一個URL請求兩次,結果值都是不一樣的。
為了實現長短鏈接一一對應,我們需要付出很大的空間代價,尤其是為了快速響應,我們可以需要在內存中做一層緩存,這樣子太浪費了。
但是可以實現一些變種的,來實現部分的一一對應, 比如將最近/最熱門的對應關系存儲在K-V數據庫中,這樣子可以節省空間的同時,加快響應速度。
短URL的存儲
我們返回的短URL一般是將數字轉換成32進制,這樣子可以更加有效的縮短URL長度,那么32進制的數字對計算機來說只是字符串,怎么存儲呢?直接存儲字符串對等值查找好找,對范圍查找等太不友好了。
其實可以直接存儲10進制的數字,這樣不僅占用空間少,對查找的支持較好,同時還可以更加方便的轉換到更多/更少的進制來進一步縮短URL。
高并發
如果直接存儲在MySQL中,當并發請求增大,對數據庫的壓力太大,可能會造成瓶頸,這時候是可以有一些優化的。
緩存
上面保證長短鏈接一一對應中也提到過緩存,這里我們是為了加快程序處理速度.可以將熱門的長鏈接(需要對長鏈接進來的次數進行計數),最近的長鏈接(可以使用redis保存最近一個小時的)等等進行一個緩存,保存在內存中或者類似redis的內存數據庫中,如果請求的長URL命中了緩存,那么直接獲取對應的短URL進行返回,不需要再進行生成操作。
批量發號
每一次發號都需要訪問一次MySQL來獲取當前的最大號碼,并且在獲取之后更新最大號碼,這個壓力是比較大的。
我們可以每次從數據庫獲取10000個號碼,然后在內存中進行發放,當剩余的號碼不足1000時,重新向MySQL請求下10000個號碼.在上一批號碼發放完了之后,批量進行寫入。
這樣可以將對數據庫持續的操作移到代碼中進行,并且異步進行獲取和寫入操作,保證服務的持續高并發。
分布式
上面設計的系統是有單點的,那就是發號器是個單點,容易掛掉。
可以采用分布式服務,分布式的話,如果每一個發號器進行發號之后都需要同步給其他發號器,那未必也太麻煩了。
換一種思路,可以有兩個發號器,一個發單號,一個發雙號,發號之后不再是遞增1,而是遞增2。
類比可得,我們可以用1000個服務,分別發放0-999尾號的數字,每次發號之后遞增1000.這樣做很簡單,服務互相之間基本都不用通信,做好自己的事情就好了。
實現
由于我懶得寫JDBC代碼,更懶得弄Mybatis,所以代碼中使用到MySQL的地方都使用了Redis。
package util;
import redis.clients.jedis.Jedis;
public class ShortUrlUtil {
private static final String SHORT_URL_KEY = "SHORT_URL_KEY";
private static final String LOCALHOST = "http://localhost:4444/";
private static final String SHORT_LONG_PREFIX = "short_long_prefix_";
private static final String CACHE_KEY_PREFIX = "cache_key_prefix_";
private static final int CACHE_SECONDS = 1 * 60 * 60;
private final String redisConfig;
private final Jedis jedis;
public ShortUrlUtil(String redisConfig) {
this.redisConfig = redisConfig;
this.jedis = new Jedis(this.redisConfig);
}
public String getShortUrl(String longUrl, Decimal decimal) {
// 查詢緩存
String cache = jedis.get(CACHE_KEY_PREFIX + longUrl);
if (cache != null) {
return LOCALHOST + toOtherBaseString(Long.valueOf(cache), decimal.x);
}
// 自增
long num = jedis.incr(SHORT_URL_KEY);
// 在數據庫中保存短-長URL的映射關系,可以保存在MySQL中
jedis.set(SHORT_LONG_PREFIX + num, longUrl);
// 寫入緩存
jedis.setex(CACHE_KEY_PREFIX + longUrl, CACHE_SECONDS, String.valueOf(num));
return LOCALHOST + toOtherBaseString(num, decimal.x);
}
/**
* 在進制表示中的字符集合
*/
final static char[] digits = {'0', '1', '2', '3', '4', '5', '6', '7', '8',
'9', 'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L',
'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y',
'Z', 'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z'};
/**
* 由10進制的數字轉換到其他進制
*/
private String toOtherBaseString(long n, int base) {
long num = 0;
if (n < 0) {
num = ((long) 2 * 0x7fffffff) + n + 2;
} else {
num = n;
}
char[] buf = new char[32];
int charPos = 32;
while ((num / base) > 0) {
buf[--charPos] = digits[(int) (num % base)];
num /= base;
}
buf[--charPos] = digits[(int) (num % base)];
return new String(buf, charPos, (32 - charPos));
}
enum Decimal {
D32(32),
D64(64);
int x;
Decimal(int x) {
this.x = x;
}
}
public static void main(String[] args) {
for (int i = 0; i < 100; i++) {
System.out.println(new ShortUrlUtil("localhost").getShortUrl("www.baidudu.com", Decimal.D32));
System.out.println(new ShortUrlUtil("localhost").getShortUrl("www.baidu.com", Decimal.D64));
}
}
}
