https://juejin.im/post/6844903873950269454
https://juejin.im/post/6844903873950269454
想必大家也經(jīng)常收到垃圾短信吧...短信中的鏈接一般都是短鏈接,類似于下圖這樣:

為什么這里面的URL都是短的呢?有什么好處呢?怎么做到的呢?
短URL的好處
短信和許多平臺(微博)有字數(shù)限制 ,太長的鏈接加進去都沒有辦法寫正文了.
好看。 比起一大堆不知所以的參數(shù),短鏈接更加簡潔友好.
方便做一些統(tǒng)計。 你點了鏈接會有人記錄然后分析的.
安全。 不暴露訪問參數(shù).
這就是為什么我們現(xiàn)在收到的垃圾短信大多數(shù)都是短URL的原因了.
那么短URL是怎么做到的呢?
短URL基礎原理
短URL從生成到使用分為以下幾步.
有一個服務,將要發(fā)送給你的長URL對應到一個短URL上.例如
www.baidu.com -> www.t.cn/1
把短URL拼接到短信等的內(nèi)容上發(fā)送.
用戶點擊短URL,瀏覽器用301/302進行重定向,訪問到對應的長URL.
展示對應的內(nèi)容.
本文主要集中于第一步,即如何將一個長URL對應到短URL上.
服務設計
如果你在往長短URL真實的對應關系上想,那么就走遠了.
最理想的情況是: 我們用一種算法,對每一個長URL,唯一的轉(zhuǎn)換成短URL.還能保持反向轉(zhuǎn)換的能力.
但是這是不可能的,如果有這樣的算法,世界上的所有壓縮算法都可以原地去世了.
正確的思路是建立一個發(fā)號器,每次有一個新的長URL進來,我們就增加一,并且將新的數(shù)值返回.第一個來的URL返回"www.x.cn/0
",第二個返回"www.x.cn/1
".
接下來以QA形式寫幾個小問題:
對應關系如何存儲?
這個對應數(shù)據(jù)肯定是要落盤的,不能每次系統(tǒng)重啟就重新排號,所以可以采用mysql等數(shù)據(jù)庫來存儲.而且如果數(shù)據(jù)量小且qps低,直接使用數(shù)據(jù)庫的自增主鍵就可以實現(xiàn).
如何保證長短鏈接一一對應?
按照上面的發(fā)號器策略,是不能保證長短鏈接的一一對應的,你連續(xù)用同一個URL請求兩次,結果值都是不一樣的.
為了實現(xiàn)長短鏈接一一對應,我們需要付出很大的空間代價,尤其是為了快速響應,我們可以需要在內(nèi)存中做一層緩存,這樣子太浪費了.
但是可以實現(xiàn)一些變種的,來實現(xiàn)部分的一一對應, 比如將最近/最熱門的對應關系存儲在K-V數(shù)據(jù)庫中,這樣子可以節(jié)省空間的同時,加快響應速度.
短URL的存儲
我們返回的短URL一般是將數(shù)字轉(zhuǎn)換成32進制,這樣子可以更加有效的縮短URL長度,那么32進制的數(shù)字對計算機來說只是字符串,怎么存儲呢?直接存儲字符串對等值查找好找,對范圍查找等太不友好了.
其實可以直接存儲10進制的數(shù)字,這樣不僅占用空間少,對查找的支持較好,同時還可以更加方便的轉(zhuǎn)換到更多/更少的進制來進一步縮短URL.
高并發(fā)
如果直接存儲在MySQL中,當并發(fā)請求增大,對數(shù)據(jù)庫的壓力太大,可能會造成瓶頸,這時候是可以有一些優(yōu)化的.
緩存
上面保證長短鏈接一一對應中也提到過緩存,這里我們是為了加快程序處理速度.可以將熱門的長鏈接(需要對長鏈接進來的次數(shù)進行計數(shù)),最近的長鏈接(可以使用redis保存最近一個小時的)等等進行一個緩存,保存在內(nèi)存中或者類似redis的內(nèi)存數(shù)據(jù)庫中,如果請求的長URL命中了緩存,那么直接獲取對應的短URL進行返回,不需要再進行生成操作.
批量發(fā)號
每一次發(fā)號都需要訪問一次MySQL來獲取當前的最大號碼,并且在獲取之后更新最大號碼,這個壓力是比較大的.
我們可以每次從數(shù)據(jù)庫獲取10000個號碼,然后在內(nèi)存中進行發(fā)放,當剩余的號碼不足1000時,重新向MySQL請求下10000個號碼.在上一批號碼發(fā)放完了之后,批量進行寫入.
這樣可以將對數(shù)據(jù)庫持續(xù)的操作移到代碼中進行,并且異步進行獲取和寫入操作,保證服務的持續(xù)高并發(fā).
分布式
上面設計的系統(tǒng)是有單點的,那就是發(fā)號器是個單點,容易掛掉.
可以采用分布式服務,分布式的話,如果每一個發(fā)號器進行發(fā)號之后都需要同步給其他發(fā)號器,那未必也太麻煩了.
換一種思路,可以有兩個發(fā)號器,一個發(fā)單號,一個發(fā)雙號,發(fā)號之后不再是遞增1,而是遞增2.
類比可得,我們可以用1000個服務,分別發(fā)放0-999尾號的數(shù)字,每次發(fā)號之后遞增1000.這樣做很簡單,服務互相之間基本都不用通信,做好自己的事情就好了.
實現(xiàn)
由于我懶得寫JDBC代碼,更懶得弄Mybatis,所以代碼中使用到MySQL的地方都使用了Redis.
package util;
import redis.clients.jedis.Jedis;
/**
?* Created by pfliu on 2019/06/23.
?*/
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);
????????// 在數(shù)據(jù)庫中保存短-長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進制的數(shù)字轉(zhuǎn)換到其他進制
?????*/
????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));
????????}
????}
}
特別推薦一個分享架構+算法的優(yōu)質(zhì)內(nèi)容,還沒關注的小伙伴,可以長按關注一下:
長按訂閱更多精彩▼
如有收獲,點個在看,誠摯感謝
免責聲明:本文內(nèi)容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!