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

java那些事2019-01-11 21:02:37

點擊上方藍色文字關注↑↑↑↑↑

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

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

  • 唯一性:確保生成的ID是全網唯一的。

  • 有序遞增性:確保生成的ID是對於某個用戶或者業務是按一定的數字有序遞增的。

  • 高可用性:確保任何時候都能正確的生成ID。

  • 帶時間:ID裡面包含時間,一眼掃過去就知道哪天的交易。

系統時間毫秒數

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

UUID

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

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

數據庫自增ID

我們都知道為數據庫主鍵設置自增序號,以一定的趨勢自增,以保證主鍵ID的唯一性。

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

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

批量生成ID

一次按需批量生成多個ID,每次生成都需要訪問數據庫,將數據庫修改為最大的ID值,並在內存中記錄當前值及最大值。這樣就避免了每次生成ID都要訪問數據庫並帶來壓力。

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

中間件

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

這種方式不依賴關係數據庫,而且速度快。但系統要引入Redis這一中間件,增加維護成本,而且編碼和配置工作量比較大。即使已經有了Redis組件,但生成ID的高頻率訪問對單線程的Redis性能勢必也會造成影響。

還可以利用像Zookeeper中的znode數據版本來生成序列號,及MongoDB的ObjectId等,這種利用中間件的做法不是很推薦。

snowflake算法

如上圖的所示,Twitter的snowflake算法下面幾部分組成:

  • 41位的時間序列,精確到毫秒,可以使用69年

  • 10位的機器標識,最多支持部署1024個節點

  • 12位的序列號,支持每個節點每毫秒產生4096個ID序號,最高位是符號位始終為0。

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

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

UidGenerator

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

大家可以參考具體使用:

https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md

Leaf

Leaf是美團開源的分佈式ID生成器,能保證全局唯一性、趨勢遞增、單調遞增、信息安全,裡面也提到了幾種分佈式方案的對比,但也需要依賴關係數據庫、Zookeeper等中間件。

具體可以參考官網說明:

https://tech.meituan.com/MT_Leaf.html

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

如果對你有用,歡迎分享到朋友圈

近期精選


總結:2017年度Java技術棧精選乾貨總結

教程:Dubbo使用及源碼全套解析視頻

面試:史上最全Java多線程面試題及答案

建議:10年老兵給程序員的10條建議

進階:Java對象引用四個級別(強、軟、弱、虛)


Java技術棧

長按二維碼關注我們



架構|分佈式|技術教程|面經


閱讀原文