細聊分佈式ID的生成方法

需求緣起

  幾乎全部的業務系統，都有生成一個記錄標識的需求，例如：

1. 消息標識：message-id
2. 訂單標識：order-id
3. 帖子標識：tiezi-id

  這個記錄標識每每就是數據庫中的惟一主鍵，數據庫上會創建彙集索引（cluster index），即在物理存儲上以這個字段排序。這個記錄標識上的查詢，每每又有分頁或者排序的業務需求，例如：

1. 拉取最新的一頁消息： SELECT message-id ORDER BY time LIMIT 100
2. 拉取最新的一頁訂單： SELECT order-id   ORDER BY time LIMIT 100
3. 拉取最新的一頁帖子： SELECT tiezi-id   ORDER BY time LIMIT 100

  因此每每要有一個time字段，而且在time字段上創建普通索引（non-cluster index）.咱們都知道普通索引存儲的是實際記錄的指針，其訪問效率會比彙集索引慢，若是記錄標識在生成時可以基本按照時間有序，則能夠省去這個time字段的索引查詢：

SELECT message-id ORDER BY message-id LIMIT 100

  再次強調，能這麼作的前提是message-id的生成基本是趨勢時間遞增的.這就引出了記錄標識生成（也就是上文提到的三個XXX-id）的兩大核心需求：

• 全局惟一
• 趨勢有序

這也是本文要討論的核心問題：如何高效生成趨勢有序的全局惟一ID。

常見方法，不足與優化

常見方法一：使用數據庫的 auto_increment 來生成全局惟一遞增ID

優勢：

1. 簡單，使用數據庫已有的功能
2. 可以保證惟一性
3. 可以保證遞增性
4. 步長固定

缺點：

1. 可用性難以保證：數據庫常見架構是一主多從+讀寫分離，生成自增ID是寫請求，主庫掛了就玩不轉了
2. 擴展性差，性能有上限：由於寫入是單點，數據庫主庫的寫性能決定ID的生成性能上限，而且難以擴展

改進方法：

1. 增長主庫，避免寫入單點
2. 數據水平切分，保證各主庫生成的ID不重複

  如上圖所述，由1個寫庫變成3個寫庫，每一個寫庫設置不一樣的auto_increment初始值，以及相同的增加步長，以保證每一個數據庫生成的ID是不一樣的（上圖中庫0生成0,3,6,9…，庫1生成1,4,7,10，庫2生成2,5,8,11…）
改進後的架構保證了可用性，但缺點是：

1. 喪失了ID生成的「絕對遞增性」：先訪問庫0生成0,3，再訪問庫1生成1，可能致使在很是短的時間內，ID生成不是絕對遞增的（這個問題不大，咱們的目標是趨勢遞增，不是絕對遞增）
2. 數據庫的寫壓力依然很大，每次生成ID都要訪問數據庫

爲了解決上述兩個問題，引出了第二個常見的方案

常見方法二：單點批量ID生成服務

  分佈式系統之因此難，很重要的緣由之一是 沒有一個全局時鐘，難以保證絕對的時序 ，要想保證絕對的時序，仍是隻能使用單點服務，用本地時鐘保證「絕對時序」。數據庫寫壓力大，是由於每次生成ID都訪問了數據庫，可使用批量的方式下降數據庫寫壓力。

  如上圖所述，數據庫使用雙master保證可用性，數據庫中只存儲當前ID的最大值，例如0。ID生成服務假設每次批量拉取6個ID，服務訪問數據庫，將當前ID的最大值修改成5，這樣應用訪問ID生成服務索要ID，ID生成服務不須要每次訪問數據庫，就能依次派發0,1,2,3,4,5這些ID了，當ID發完後，再將ID的最大值修改成11，就能再次派發6,7,8,9,10,11這些ID了，因而數據庫的壓力就下降到原來的1/6了。 優勢：

1. 保證了ID生成的絕對遞增有序
2. 大大的下降了數據庫的壓力，ID生成能夠作到每秒生成幾萬幾十萬個

缺點：

1. 服務仍然是單點
2. 若是服務掛了，服務重啓起來以後，繼續生成ID可能會不連續，中間出現空洞（服務內存是保存着0,1,2,3,4,5，數據庫中max-id是5，分配到3時，服務重啓了，下次會從6開始分配，4和5就成了空洞，不過這個問題也不大）
3. 雖然每秒能夠生成幾萬幾十萬個ID，但畢竟仍是有性能上限，沒法進行水平擴展

改進方法：

單點服務的經常使用高可用優化方案是「備用服務」，也叫「影子服務」，因此咱們能用如下方法優化上述缺點1，對外提供的服務是主服務，有一個影子服務時刻處於備用狀態，當主服務掛了的時候影子服務頂上。這個切換的過程對調用方是透明的，能夠自動完成，經常使用的技術是vip+keepalived，具體就不在這裏展開。

常見方法三：uuid

  上述方案來生成ID，雖然性能大增，但因爲是單點系統，總仍是存在性能上限的。同時，上述兩種方案，不論是數據庫仍是服務來生成ID，業務方Application都須要進行一次遠程調用，比較耗時。有沒有一種本地生成ID的方法，即高性能，又時延低呢？
uuid是一種常見的方案：string ID = GenUUID();
優勢：

1. 本地生成ID，不須要進行遠程調用，時延低
2. 擴展性好，基本能夠認爲沒有性能上限

缺點：

1. 沒法保證趨勢遞增
2. uuid過長，每每用字符串表示，做爲主鍵創建索引查詢效率低，常見優化方案爲「轉化爲兩個uint64整數存儲」或者「折半存儲」（折半後不能保證惟一性）

常見方法四：取當前毫秒數

  uuid是一個本地算法，生成性能高，但沒法保證趨勢遞增，且做爲字符串ID檢索效率低，有沒有一種能保證遞增的本地算法呢？
取當前毫秒數是一種常見方案：uint64 ID = GenTimeMS();
優勢：

1. 本地生成ID，不須要進行遠程調用，時延低
2. 生成的ID趨勢遞增
3. 生成的ID是整數，創建索引後查詢效率高

缺點：

1. 若是併發量超過1000，會生成重複的ID
   我去，這個缺點要了命了，不能保證ID的惟一性。固然，使用微秒能夠下降衝突機率，但每秒最多隻能生成1000000個ID，再多的話就必定會衝突了，因此使用微秒並不從根本上解決問題。

常見方法五：類snowflake算法

  snowflake是twitter開源的分佈式ID生成算法，其核心思想是：一個long型的ID，使用其中41bit做爲毫秒數，10bit做爲機器編號，12bit做爲毫秒內序列號。這個算法單機每秒內理論上最多能夠生成1000*(2^12)，也就是400W的ID，徹底能知足業務的需求。借鑑snowflake的思想，結合各公司的業務邏輯和併發量，能夠實現本身的分佈式ID生成算法。
舉例，假設某公司ID生成器服務的需求以下：

1. 單機高峯併發量小於1W，預計將來5年單機高峯併發量小於10W
2. 有2個機房，預計將來5年機房數量小於4個
3. 每一個機房機器數小於100臺
4. 目前有5個業務線有ID生成需求，預計將來業務線數量小於10個
5. …

分析過程以下：

1. 高位取從2016年1月1日到如今的毫秒數（假設系統ID生成器服務在這個時間以後上線），假設系統至少運行10年，那至少須要10年*365天*24小時*3600秒*1000毫秒=320*10^9，差很少預留39bit給毫秒數
2. 每秒的單機高峯併發量小於10W，即平均每毫秒的單機高峯併發量小於100，差很少預留7bit給每毫秒內序列號
3. 5年內機房數小於4個，預留2bit給機房標識
4. 每一個機房小於100臺機器，預留7bit給每一個機房內的服務器標識
5. 業務線小於10個，預留4bit給業務線標識

這樣設計的64bit標識，能夠保證：

1. 每一個業務線、每一個機房、每一個機器生成的ID都是不一樣的
2. 同一個機器，每一個毫秒內生成的ID都是不一樣的
3. 同一個機器，同一個毫秒內，以序列號區區分保證生成的ID是不一樣的
4. 將毫秒數放在最高位，保證生成的ID是趨勢遞增的

缺點：

1. 因爲「沒有一個全局時鐘」，每臺服務器分配的ID是絕對遞增的，但從全局看，生成的ID只是趨勢遞增的（有些服務器的時間早，有些服務器的時間晚）
2. 一個容易忽略的問題：
生成的ID，例如message-id，order-id，tiezi-id，在數據量大時每每須要分庫分表，這些ID常常做爲取模分庫分表的依據，爲了分庫分表後數據均勻，ID生成每每有「取模隨機性」的需求，因此咱們一般把每秒內的序列號放在ID的最末位，保證生成的ID是隨機的。又若是，咱們在跨毫秒時，序列號老是歸0，會使得序列號爲0的ID比較多，致使生成的ID取模後不均勻。解決方法是，序列號不是每次都歸0，而是歸一個0到9的隨機數，這個地方。