在網際網路的業務系統中，涉及到各種各樣的ID，如在支付系統中就會有支付ID、退款ID等。那一般生成ID都有哪些解決方案呢？特別是在複雜的分散式系統業務場景中，我們應該採用哪種適合自己的解決方案是十分重要的。下面我們一一來列舉一下，不一定全部適合，這些解決方案僅供你參考，或許對你有用。

一個ID一般來說有下面幾種要素：

我們可以使用當前系統時間精確到毫秒數+業務屬性+使用者屬性+隨機數+...等引數組合形式來確保ID的唯一性，缺點是ID的有序性難以保證，要保證有序性就要依賴資料庫或者其他中間儲存媒介。

Java自帶的生成UUID的方式就能生成一串唯一隨機32位長度資料，而且夠我們用N億年，保證唯一性肯定是不用說的了，但缺點是它不包含時間、業務資料可讀性太差了，而且也不能ID的有序遞增。

這是一種簡單的生成方式，簡單，高效，但在一般業務系統中我還沒見過有這種生成方式。

我們都知道為資料庫主鍵設定自增序號，以一定的趨勢自增，以保證主鍵ID的唯一性。

這個方案很簡單，但最主要的問題在於依賴資料庫本身，這就無形增加了對資料庫的訪問壓力和依賴，一旦對單庫進行分庫分表或者資料遷移就尷尬了。

所以，這也不是合適的ID生成方法。

一次按需批次生成多個ID，每次生成都需要訪問資料庫，將資料庫修改為最大的ID值，並在記憶體中記錄當前值及最大值。這樣就避免了每次生成ID都要訪問資料庫並帶來壓力。

這種方案服務就是單點了，如果服務重啟勢必會造成ID丟失不連續的情況，而且這種方式也不利於水平擴充套件。

Redis的所有命令操作都是單執行緒的，本身提供像incr這樣的自增命令，所以能保證生成的ID肯定是唯一有序的。

這種方式不依賴關聯式資料庫，而且速度快。但系統要引入Redis這一中介軟體，增加維護成本，而且編碼和配置工作量比較大。即使已經有了Redis元件，但生成ID的高頻率訪問對單執行緒的Redis效能勢必也會造成影響。

還可以利用像Zookeeper中的znode資料版本來生成序列號，及MongoDB的ObjectId等，這種利用中介軟體的做法不是很推薦。

image

如上圖的所示，Twitter的snowflake演算法下面幾部分組成：

這種方案效能好，在單機上是遞增的，但是由於涉及到分散式環境，每臺機器上的時鐘不可能完全同步，也許有時候也會出現不是全域性遞增的情況。

而且這個專案在2010就停止維護了，但這個設計思路還是應用於其他各個ID生成器及變種。

UidGenerator是百度開源的分散式ID生成器，基於於snowflake演算法的實現，看起來感覺還行。不過，國內開源的專案維護性真是擔憂。

大家可以參考具體使用：

Leaf是美團開源的分散式ID生成器，能保證全域性唯一性、趨勢遞增、單調遞增、資訊保安，裡面也提到了幾種分散式方案的對比，但也需要依賴關聯式資料庫、Zookeeper等中介軟體。

具體可以參考官網說明：

好了，就這麼多了，不同的方案應用的場景和系統也是不同的。大家有更好的方案也可以在下面留言，一起討論下大家都是怎麼做的。

作者：Java技術棧
連結：

分散式ID生成器的解決方案總結

相關文章