分布式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算法的實現，看起來感覺還行。不過，國內開源的項目維護性真是擔憂。

Leaf

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

關于分布式ID生成器的解決方案是怎么樣的問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注億速云行業資訊頻道了解更多相關知識。