作者：京東零售 郝彥軍
什么是短網址？
短網址，是在長度上比較短的網址，簡單來說就是幫您把冗長的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+
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/552310.html
標籤：其他
下一篇：返回列表