一線大廠的分佈式惟一ID生成方案是什麼樣的？

1、前言

分佈式系統中咱們會對一些數據量大的業務進行分拆，如：用戶表，訂單表。由於數據量巨大一張表沒法承接，就會對其進行分庫分表。

但一旦涉及到分庫分表，就會引伸出分佈式系統中惟一主鍵ID的生成問題，永不遷移數據和避免熱點的文章中要求須要惟一ID的特性：

• 整個系統ID惟一

• ID是數字類型，並且是趨勢遞增的

• ID簡短，查詢效率快

什麼是遞增？如：第一次生成的ID爲12，下一次生成的ID是13，再下一次生成的ID是14。這個就是生成ID遞增。

什麼是趨勢遞增？如：在一段時間內，生成的ID是遞增的趨勢。如：再一段時間內生成的ID在【0，1000】之間，過段時間生成的ID在【1000，2000】之間。但在【0-1000】區間內的時候，ID生成有可能第一次是12，第二次是10，第三次是14。

那有什麼方案呢？往下看！

2、分佈式ID的幾種生成方案

2.一、UUID

這個方案是小夥伴們第一個能過考慮到的方案

優勢：

• 代碼實現簡單。

• 本機生成，沒有性能問題

• 由於是全球惟一的ID，因此遷移數據容易

缺點：

• 每次生成的ID是無序的，沒法保證趨勢遞增

• UUID的字符串存儲，查詢效率慢

• 存儲空間大

• ID本事無業務含義，不可讀

應用場景：

• 相似生成token令牌的場景

• 不適用一些要求有趨勢遞增的ID場景

此UUID方案是不適用老顧的需求。

2.二、MySQL主鍵自增

這個方案就是利用了MySQL的主鍵自增auto_increment，默認每次ID加1。

優勢：

• 數字化，id遞增

• 查詢效率高

• 具備必定的業務可讀

缺點：

• 存在單點問題，若是mysql掛了，就無法生成iD了

• 數據庫壓力大，高併發抗不住

2.三、MySQL多實例主鍵自增

這個方案就是解決mysql的單點問題，在auto_increment基本上面，設置step步長

每臺的初始值分別爲1,2,3...N，步長爲N（這個案例步長爲4）

優勢：

• 解決了單點問題

缺點：

• 一旦把步長定好後，就沒法擴容；並且單個數據庫的壓力大，數據庫自身性能沒法知足高併發

應用場景：

• 數據不須要擴容的場景

此方案也不知足老顧的需求，由於不方便擴容（記住這個方案，嘿嘿）

2.四、雪花snowflake算法

這個算法網上介紹了不少，老顧這裏就不詳細介紹。雪花算法生成64位的二進制正整數，而後轉換成10進制的數。64位二進制數由以下部分組成：

• 1位標識符：始終是0

• 41位時間戳：41位時間截不是存儲當前時間的時間截，而是存儲時間截的差值（當前時間截 - 開始時間截 )獲得的值，這裏的的開始時間截，通常是咱們的id生成器開始使用的時間，由咱們程序來指定的

• 10位機器標識碼：能夠部署在1024個節點，若是機器分機房（IDC）部署，這10位能夠由 5位機房ID + 5位機器ID 組成

• 12位序列：毫秒內的計數，12位的計數順序號支持每一個節點每毫秒(同一機器，同一時間截)產生4096個ID序號

優勢：

• 此方案每秒可以產生409.6萬個ID，性能快

• 時間戳在高位，自增序列在低位，整個ID是趨勢遞增的，按照時間有序遞增

• 靈活度高，能夠根據業務需求，調整bit位的劃分，知足不一樣的需求

缺點：

• 依賴機器的時鐘，若是服務器時鐘回撥，會致使重複ID生成

在分佈式場景中，服務器時鐘回撥會常常遇到，通常存在10ms之間的回撥；小夥伴們就說這點10ms，很短能夠不考慮吧。但此算法就是創建在毫秒級別的生成方案，一旦回撥，就頗有可能存在重複ID。

此方案暫不符合老顧的需求（嘿嘿，看看怎麼優化這個方案，小夥伴們先記住）

2.五、Redis生成方案

利用redis的incr原子性操做自增，通常算法爲：

年份 + 當天距當年第多少天 + 天數 + 小時 + redis自增

優勢：

• 有序遞增，可讀性強

缺點：

• 佔用帶寬，每次要向redis進行請求

總體測試了這個性能以下：

需求：同時10萬個請求獲取ID一、併發執行完耗時：9s左右
二、單任務平均耗時：74ms
三、單線程最小耗時：不到1ms
四、單線程最大耗時：4.1s
複製代碼

性能還能夠，若是對性能要求不是過高的話，這個方案基本符合老顧的要求。

但不徹底符合業務老顧但願id從 1 開始趨勢遞增。（固然算法能夠調整爲 就一個 redis自增，不須要什麼年份，多少天等）。

2.六、小結

以上介紹了常見的幾種分佈式ID生成方案。一線大廠的分佈式ID方案絕沒有這個簡單，他們對高併發，高可用的要求很高。

如Redis方案中，每次都要去Redis去請求，有網絡請求耗時，併發強依賴了Redis。這個設計是有風險的，一旦Redis掛了，整個系統不可用。

並且一線大廠也會考慮到ID安全性的問題，如：Redis方案中，用戶是能夠預測下一個ID號是多少，由於算法是遞增的。

這樣的話競爭對手第一天中午12點下個訂單，就能夠看到平臺的訂單ID是多少，次日中午12點再下一單，又平臺訂單ID到多少。這樣就能夠猜到平臺1天能產生多少訂單了，這個是絕對不容許的，公司絕密啊。

3、一線大廠是如何設計的呢?

一線大廠的設計思路其實和小夥伴們思路差很少，只是多想了1～2層，設計上面多了1～2個環節。

3.一、改造數據庫主鍵自增

上述咱們介紹了利用數據庫的自增主鍵的特性，能夠實現分佈式ID；這個ID比較簡短明瞭，適合作userId，正好符合如何永不遷移數據和避免熱點? 根據服務器指標分配數據量(揭祕篇)文章中的ID的需求。但這個方案有嚴重的問題：

• 一旦步長定下來，不容易擴容

• 數據庫壓力山大

小夥伴們看看怎麼優化這個方案。先看數據庫壓力大，爲何壓力大？是由於咱們每次獲取ID的時候，都要去數據庫請求一次。那咱們能夠不能夠不要每次去取？

思路咱們能夠請求數據庫獲得ID的時候，可設計成得到的ID是一個ID區間段。

咱們看上圖，有張ID規則表：

一、id表示爲主鍵，無業務含義。

二、biz_tag爲了表示業務，由於總體系統中會有不少業務須要生成ID，這樣能夠共用一張表維護

三、max_id表示如今總體系統中已經分配的最大ID

四、desc描述

五、update_time表示每次取的ID時間

咱們再來看看總體流程：

一、【用戶服務】在註冊一個用戶時，須要一個用戶ID；會請求【生成ID服務(是獨立的應用)】的接口

二、【生成ID服務】會去查詢數據庫，找到user_tag的id，如今的max_id爲0，step=1000

三、【生成ID服務】把max_id和step返回給【用戶服務】；而且把max_id更新爲max_id = max_id + step，即更新爲1000

四、【用戶服務】得到max_id=0，step=1000；

五、 這個用戶服務能夠用ID=【max_id + 1，max_id+step】區間的ID，即爲【1，1000】

六、【用戶服務】會把這個區間保存到jvm中

七、【用戶服務】須要用到ID的時候，在區間【1，1000】中依次獲取id，可採用AtomicLong中的getAndIncrement方法。

八、若是把區間的值用完了，再去請求【生產ID服務】接口，獲取到max_id爲1000，便可以用【max_id + 1，max_id+step】區間的ID，即爲【1001，2000】

這個方案就很是完美的解決了數據庫自增的問題，並且能夠自行定義max_id的起點，和step步長，很是方便擴容。

並且也解決了數據庫壓力的問題，由於在一段區間內，是在jvm內存中獲取的，而不須要每次請求數據庫。即便數據庫宕機了，系統也不受影響，ID還能維持一段時間。

3.二、競爭問題

以上方案中，若是是多個用戶服務，同時獲取ID，同時去請求【ID服務】，在獲取max_id的時候會存在併發問題。

如用戶服務A，取到的max_id=1000 ;用戶服務B取到的也是max_id=1000，那就出現了問題，Id重複了。那怎麼解決？

其實方案不少，加分佈式鎖，保證同一時刻只有一個用戶服務獲取max_id。固然也能夠用數據庫自身的鎖去解決。

利用事務方式加行鎖，上面的語句，在沒有執行完以前，是不容許第二個用戶服務請求過來的，第二個請求只能阻塞。

3.三、突發阻塞問題

上圖中，多個用戶服務獲取到了各自的ID區間，在高併發場景下，ID用的很快，若是3個用戶服務在某一時刻都用完了，同時去請求【ID服務】。由於上面提到的競爭問題，全部只有一個用戶服務去操做數據庫，其餘二個會被阻塞。

小夥伴就會問，有這麼巧嗎？同時ID用完。咱們這裏舉的是3個用戶服務，感受機率不大；若是是100個用戶服務呢？機率是否是一會兒大了。

出現的現象就是一下子忽然系統耗時變長，一下子好了，就是這個緣由致使的，怎麼去解決？

3.四、雙buffer方案

在通常的系統設計中，雙buffer會常常看到，怎麼去解決上面的問題也能夠採用雙buffer方案。

在設計的時候，採用雙buffer方案，上圖的流程：

一、當前獲取ID在buffer1中，每次獲取ID在buffer1中獲取

二、當buffer1中的Id已經使用到了100，也就是達到區間的10%

三、達到了10%，先判斷buffer2中有沒有去獲取過，若是沒有就當即發起請求獲取ID線程，此線程把獲取到的ID，設置到buffer2中。

四、若是buffer1用完了，會自動切換到buffer2

五、buffer2用到10%了，也會啓動線程再次獲取，設置到buffer1中

六、依次往返

雙buffer的方案，小夥伴們有沒有感受很酷，這樣就達到了業務場景用的ID，都是在jvm內存中得到的，今後不須要到數據庫中獲取了。容許數據庫宕機時間更長了。

由於會有一個線程，會觀察何時去自動獲取。兩個buffer之間自行切換使用。就解決了突發阻塞的問題。

4、總結

此方案是某團使用的分佈式ID算法，小夥伴們若是想了解更深，能夠去網上搜下，這裏應該介紹了比較詳細了。

固然此方案美團還作了一些別的優化，監控ID使用頻率，自動設置步長step，從而達到對ID節省使用。