作者：京東零售 郝彥軍
什麼是短網址？
短網址，是在長度上比較短的網址。簡單來說就是幫您把冗長的URL地址縮短成8個字元以內的短網址。
當我們在騰訊、新浪發微博時，有時發很長的網址連線，但由於微博只限制140個字，所以微博就自動把您發的長網址給轉換成短網址了。在微博和手機簡訊提醒等限制字數的地方來使用短網址，的確是一個不錯的方案。
短網址通常使用“短域名/短碼”的形式，開啟短網址網頁會直接跳轉到長網址頁面。例：3.cn/CdEyF2、t.cn/RlB2PdD、dwz.cn/134128 等短網址，分別是由以下短網址服務縮短後的網址 京東短網址：http://s.3.cn/， 新浪短網址：https://sina.lt/ ，百度短網址：http://dwz.cn/。
短網址服務主要包含功能： 生成短網址（長網址縮短）、二維碼簡化、修改短網址、短網址跳轉（訪問短網址跳轉到長網址）、喚醒APP、短網址統計 等。
短網址能解決什麼問題？
長網址存在的問題：
1、長網址的長度太長，下面的長網址，共記312個字元，在微博場景中，限制140字元，已無法釋出出去。在簡訊場景中，限制70字元，會產生5條簡訊費用，被拆分後還無法訪問，嚴重影響使用者體驗。http://wjorder-http.jd.com/scan/np?encodePrcode=2hP_lwNr&encodeShcode=2-S83&businessSource=1&scanSkuType=2&ec=1&salerId=167916&discountsUrl=%2F%2Fcoupon.m.jd.com%2Fcoupons%2Fshow.action%3FlinkKey%3DAAROH_xIpeffAs_-naABEFoePLd7eC4GJgwsPUkFtDqklu805DO1cEqFyTHVT7fbD12AHD7DElAKgh0pfvQpX-E5PbgwLQ&unionId=1001465750
2、長網址生成的二維碼，極其複雜 ，導致手機掃描識別極其困難，低端手機甚至無法識別，嚴重影響使用者體驗。
短網址則完美解決了上述問題：
1、使用短網址服務縮短上面長網址後的短網址（3.cn/1jK-CDAE），僅有13個字元，在微博、簡訊等場景中傳送十分容易，而且簡潔清晰，使用者體驗極好。
2、短網址生成的二維碼，極其簡潔 ，非常容易識別，使用者體驗良好。
京東短網址的業務場景：
京東短網址http://s.3.cn/，是京東唯一的短網址服務平臺，已應用到京東體系的各個業務場景中，日均產生1億條帶有3.cn的短訊息，點選短網址還可直接喚起對應的APP和小程式。
如下圖1-2是來自七鮮、金龍魚、京東金融、蒙牛、京東等業務的營銷訊息，下圖3-4是喚起七鮮小程式、京東APP、金融APP並跳轉至落地頁的截圖。
圖1
圖2
圖3
圖4
京東短網址服務的架構最佳化：
改造前短網址生成流程圖說明：
1、系統首先查詢長網址（長鏈）是否已存在於redis（jimdb）或hbase中，
2、如果長鏈已存在，則表示該長網址已經生成過，可直接返回查到的短網址，流程結束。
3、如果長鏈不存在，則使用長網址進行MD5隨機演算法生成一個長串，並分成3段，轉化成62進位制短碼，拼裝成短網址，然後查詢短網址（短鏈）是否存在於redis或hbase中
4、如果短鏈不存在，則儲存長網址到短網址的對映、以及短網址到長網址的對映，到redis或hbase中，返回短網址，流程結束。
5、如果短鏈已存在，說明隨機演算法生成的短碼發生了衝突碰撞，需要迴圈回到步驟3，加鹽重新生成一個短碼，直到生成的短碼檢測沒有衝突後，走到步驟4結束。
從原流程圖分析原系統優劣勢：
優勢：採用隨機演算法，同一長鏈在同一賬號下始終唯一，適用於長網址大量重複生成的情景，可以在步驟2快速返回，且隨機演算法遍歷難度相對較高。
劣勢：外部操作太多，效能影響較大，每次生成短網址涉及的網路請求次數至少8次（2次查redis、2次寫redis、2次查hbase、2次寫hbase）。
且從上面步驟5可以看出，系統存在一個碰撞迴圈，隨著短碼資料量日益增加，碰撞率也會大大增加，每次碰撞都要額外增加1次redis與1次hbase查詢，導致效能越來越差。
分析原流程&歷史資料，尋找原流程最佳化點：
1、 從原流程可以看出，如果繼續採用隨機演算法，很難進行最佳化，因此，想到了可以採用自增演算法，因為自增不存在碰撞，就不需要進行雙向檢索儲存，能夠極大的降低外部請求數。
2、 分析歷史資料發現，很少存在長網址被大量重複生成的情況，也就是說，可以採用自增演算法的單向儲存（僅儲存短網址到長網址的對映），並不會增加儲存量，反而會比隨機演算法的雙向儲存（儲存短到長的對映，及長到短的對映，即雙倍儲存）節省儲存量。
3、 分析歷史資料發現，90%超過1個月的短網址都不再有訪問量了，同時調研業務也發現，43%使用者1個月有效期就夠了，46%使用者3個月，10%使用者1年，極少有使用者需要短網址永久有效。
4、 分析歷史資料發現，生成的資料量很大，日均1億+，且大多數短網址並不需要永久儲存，需要做好清理規劃
5、 分析歷史資料發現，生成量遠大於跳轉量，跳轉服務流程簡單僅做查詢，最佳化空間不大，倒是對生成服務效能要求極高，最佳化重點在於生成服務。
最佳化後的短碼生成流程說明：
1、 系統直接採用自增演算法生成了一個短碼，因為自增演算法沒有了隨機碰撞，也就不需要再檢索短網址是否存在redis或hbase中。
2、 直接儲存短網址到長網址的對映到redis中，因為沒有了檢索長網址是否存在於redis或hbase，也就不再需要儲存長網址到短網址的對映，也就可以把hbase的寫入改成非同步寫入，然後直接返回短網址，流程結束。（可以看到系統僅剩下1次同步的redis操作，流程極大簡化，可以預見介面效能將得到極大提升）
自研專利演算法介紹
細心的同學可能會有疑問，上面的分散式自增演算法是怎麼實現的呢？
目前市面上已知方案，1、透過資料庫自增（併發QPS數有限）2、透過redis自增（存在單key熱點問題，也就是所有的發號請求都會打到同一分片上），兩種方案均會增加效能損耗，且存在擴充套件瓶頸，無法滿足京東的海量業務請求。3、雪花演算法（長度太長不符合，短網址要求長度一般在7個字元）
因此設計了下面的專利自增演算法：（效能近乎於記憶體，損耗可忽略）
下面介紹一下核心的自增演算法原理：主要採用快取發號加記憶體自增方式，既無碰撞率又效能極高，主要體現在下圖的三條彩色通道上面。
1、綠色通道：記憶體發號，速度極快，每次從快取取出10000個無重複號碼，然後在記憶體中便可連續生成10000個短碼，因此速度比傳統基於資料庫及快取自增發號方式快萬倍。
2、藍色通道：快取取號，依賴快取保證分散式發號無碰撞，批次發號，每1萬次記憶體綠色通道才走一次藍色快取通道取號，因此效能極高
3、紅色通道：保障機制，保障生成的號碼都在短網址對應長度的號碼總容量範圍內，僅在初始化及總容量用盡時執行，效能損耗可忽略不計。
長度&有效期規劃：
• 有訪問會自動延期N天（7位短碼總容量3萬億，過期時間30天，每天有1000億短碼可用，30天內有1次訪問就會重置30天有效期，也就是說保持“熱資料”始終在redis中）
• 連續N天無訪問自動回收（7位短碼，連續30天沒有訪問的情況下，才會過期回收，也就是說“冷資料”無訪問N天后會自動過期清理回收）
以下統計了最近6天的各短碼長度的使用分佈佔比情況，目前使用最多的是7位與8位短碼，佔比總和近90%。其中43%的使用者選擇了30天有效期，46%的使用者選擇來了100天有效期。
提效成果：
Ø 介面效能極大提升：tp999：從150+ms ->7ms，解決了業務呼叫緩慢及超時的痛點
Ø 單機承載量極大提升：單機QPS：從497->10184，提升了20倍+，無擴容支撐了日生成量：從1千萬->2億+
Ø 按百度短網址費用核算，1年可節約2700萬元（證明短網址產生價值很大
Ø redis快取30天熱資料，快取量 1.2TB
Ø Hbase儲存全量資料，儲存量 4TB
Ø 6月18日生成量4.7億、6月日均1億、峰值QPS 7.2萬
Ø 6月1日跳轉量1600萬、6月日均800萬
Ø 線上僅8臺4核docker（最佳化後日常節約了760核機器，618節約3572核）
Ø 有訪問自動延期，無訪問自動過期回收，避免了死碼長期佔用資源消耗費用，避免短碼越積越多導致的資料量太大及效能下降，系統可長期穩定執行
創新性：
Ø 產出技術發明 專利1篇，編號：JDZL2019N5022
Ø 技術關鍵點是分散式 無碰撞 高效 短碼生成演算法：
Ø 該演算法利用redis的incrby實現分散式號段發放（5位短碼每次發放1000個號，當然6、7位短碼可設定更大步長值10000個），利用本機原子id自增減少redis請求（每10000個id自增後請求1次redis），因為id始終自增所以短碼無碰撞機率（id可以直接轉化為62進位制短碼），避免了因短碼碰撞帶來的迴圈生成檢索的效能開銷。利用redis.set原子檢測key不存在時才能設定成功實現分散式加鎖，解決多執行緒併發重置問題，最終實現比傳統自增方案快萬倍的高效能無碰撞短碼自增演算法。
Ø 利用容量規劃及過期時間機制（5位短碼總容量9億，有效期10天，每天有9千萬可用），實現號段迴圈重複利用（10天后第1天的號段過期，可以再次使用）（當然如果是6位短碼、總容量有550億，有效期也可以更長。7位短碼總容量3萬億，基本可以不用過期了），保障了系統的長期穩定執行。
影響力：
Ø 宙斯平臺-京麥服務市場中上架，有**470+**京東商戶應用使用。3.cn/1-jMkHBf
Ø 3.cn作為京東唯一的短網址服務平臺，合作的應用50+（京東APP、京東金融、京東雲、京東保險、七鮮、京東健康、京東物流等等）、小程式20+、合作的二級部門80+
