搞懂分散式技術12：分散式ID生成方案

本文內容參考網路，侵刪

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視

https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章首發於我的個人部落格：

www.how2playlife.com

該系列博文會告訴你什麼是分散式系統，這對後端工程師來說是很重要的一門學問，我們會逐步瞭解常見的分散式技術、以及一些較為常見的分散式系統概念，同時也需要進一步瞭解zookeeper、分散式事務、分散式鎖、負載均衡等技術，以便讓你更完整地瞭解分散式技術的具體實戰方法，為真正應用分散式技術做好準備。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

分散式ID生成器 | 架構師之路

轉自： 58沈劍 架構師之路 2017-06-25

一、需求緣起

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

• 訊息標識：message-id

• 訂單標識：order-id

• 帖子標識：tiezi-id

這個記錄標識往往就是資料庫中的 主鍵，資料庫上會建立 聚集索引（cluster index），即在物理儲存上以這個欄位排序。

這個記錄標識上的查詢，往往又有分頁或者排序的業務需求，例如：

• 拉取最新的一頁訊息

  select message-id/ order by time/ limit 100

• 拉取最新的一頁訂單

  select order-id/ order by time/ limit 100

• 拉取最新的一頁帖子

  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

優點：

• 簡單，使用資料庫已有的功能

• 能夠保證唯一性

• 能夠保證遞增性

• 步長固定

缺點：

• 可用性難以保證：資料庫常見架構是一主多從+讀寫分離，生成自增ID是寫請求，主庫掛了就玩不轉了

• 擴充套件性差，效能有上限：因為寫入是單點，資料庫主庫的寫效能決定ID的生成效能上限，並且難以擴充套件

改進方法：

• 冗餘主庫，避免寫入單點

• 資料水平切分，保證各主庫生成的ID不重複

如上圖所述，由1個寫庫變成3個寫庫， 每個寫庫設定不同的auto_increment初始值，以及相同的增長步長，以保證每個資料庫生成的ID是不同的（上圖中庫0生成0,3,6,9…，庫1生成1,4,7,10，庫2生成2,5,8,11…）

改進後的架構保證了可用性，但 缺點是：

• 喪失了ID生成的“絕對遞增性”：先訪問庫0生成0,3，再訪問庫1生成1，可能導致在非常短的時間內，ID生成不是絕對遞增的（這個問題不大，目標是趨勢遞增，不是絕對遞增）

• 資料庫的寫壓力依然很大，每次生成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。

優點：

• 保證了ID生成的絕對遞增有序

• 大大的降低了資料庫的壓力，ID生成可以做到每秒生成幾萬幾十萬個

缺點：

• 服務仍然是單點

• 如果服務掛了，服務重啟起來之後，繼續生成ID可能會不連續，中間出現空洞（服務記憶體是儲存著0,1,2,3,4,5，資料庫中max-id是5，分配到3時，服務重啟了，下次會從6開始分配，4和5就成了空洞，不過這個問題也不大）

• 雖然每秒可以生成幾萬幾十萬個ID，但畢竟還是有效能上限，無法進行水平擴充套件

改進方法：

單點服務的常用高可用優化方案是“備用服務”，也叫“影子服務”，所以我們能用以下方法優化上述缺點（1）：

如上圖，對外提供的服務是主服務，有一個影子服務時刻處於備用狀態，當主服務掛了的時候影子服務頂上。

這個切換的過程對呼叫方是透明的，可以自動完成，常用的技術是vip+keepalived，具體就不在這裡展開。

另外，ID-gen-service也可以實施水平擴充套件，以解決上述缺點（3），但會引發一致性問題，具體解決方案詳見《》。

方法三：uuid/guid

不管是通過資料庫，還是通過服務來生成ID，業務方Application都需要進行一次遠端呼叫，比較耗時。

有沒有一種本地生成ID的方法，即高效能，又時延低呢？

uuid是一種常見的方案：

string ID =GenUUID();

優點：

• 本地生成ID，不需要進行遠端呼叫，時延低

• 擴充套件性好，基本可以認為沒有效能上限

缺點：

• 無法保證趨勢遞增

• uuid過長，往往用字串表示，作為主鍵建立索引查詢效率低，常見優化方案為“轉化為兩個uint64整數儲存”或者“折半儲存”（折半後不能保證唯一性）

方法四：取當前毫秒數

uuid是一個本地演算法，生成效能高，但無法保證趨勢遞增，且作為字串ID檢索效率低，有沒有一種能保證遞增的本地演算法呢？

取當前毫秒數是一種常見方案：

uint64 ID = GenTimeMS();

優點：

• 本地生成ID，不需要進行遠端呼叫，時延低

• 生成的ID趨勢遞增

• 生成的ID是整數，建立索引後查詢效率高

缺點：

• 如果併發量超過1000，會生成重複的ID

這個缺點要了命了，不能保證ID的唯一性。當然，使用微秒可以降低衝突概率，但每秒最多隻能生成1000000個ID，再多的話就一定會衝突了，所以使用微秒並不從根本上解決問題。

方法五：類snowflake演算法

snowflake是twitter開源的分散式ID生成演算法，其 核心思想為，一個long型的ID：

• 41bit作為毫秒數

• 10bit作為機器編號

• 12bit作為毫秒內序列號

演算法單機每秒內理論上最多可以生成1000*(2^12)，也就是400W的ID，完全能滿足業務的需求。

借鑑snowflake的思想，結合各公司的業務邏輯和併發量，可以實現 自己的分散式ID生成演算法。

舉例，假設某公司ID生成器服務的需求如下：

• 單機高峰併發量小於1W，預計未來5年單機高峰併發量小於10W

• 有2個機房，預計未來5年機房數量小於4個

• 每個機房機器數小於100臺

• 目前有5個業務線有ID生成需求，預計未來業務線數量小於10個

• …

分析過程如下：

• 高位取從2017年1月1日到現在的毫秒數（假設系統ID生成器服務在這個時間之後上線），假設系統至少執行10年，那至少需要10年 365天24小時 3600秒1000毫秒=320*10^9，差不多預留39bit給毫秒數

• 每秒的單機高峰併發量小於10W，即平均每毫秒的單機高峰併發量小於100，差不多預留7bit給每毫秒內序列號

• 5年內機房數小於4個，預留2bit給機房標識

• 每個機房小於100臺機器，預留7bit給每個機房內的伺服器標識

• 業務線小於10個，預留4bit給業務線標識

這樣設計的64bit標識，可以保證：

• 每個業務線、每個機房、每個機器生成的ID都是不同的

• 同一個機器，每個毫秒內生成的ID都是不同的

• 同一個機器，同一個毫秒內，以序列號區區分保證生成的ID是不同的

• 將毫秒數放在最高位，保證生成的ID是趨勢遞增的

缺點：

• 由於“沒有一個全域性時鐘”，每臺伺服器分配的ID是絕對遞增的，但從全域性看，生成的ID只是趨勢遞增的（有些伺服器的時間早，有些伺服器的時間晚）