【SQLServer】整理10種分布式id生成方案
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
在復雜分布式系統中，如金融、支付、訂單等業務數據日漸增長而必須要采用對數據分庫分表操作，此時就需要有一個唯一ID來標識一條數據或消息。下面介紹幾種常見的分布式id生成方案。 1、UUID 代碼實現如下所示：
2、數據自增主鍵
當需要唯一的id的時候，向數據庫中添加一條數據并返回主鍵id，可以保證在當前的系統的中id的唯一性。
數據自增主鍵方案適用于小規模的、無高并發場景業務場景。 3、數據庫集群模式 基于數據自增id主鍵方案存在單點問題，那么對其做高可用的優化，即就是使用數據庫的集群模式來生成唯一id。
通過增加多臺數據庫服務并且給每個數據庫都設置起始值，然后通過設置步長來讓數據生成的ID趨勢遞增且不重復。
此方案適用于數據量不大，數據庫不需要擴容的場景。 4、數據庫號段模式 此方案實質就是批量從數據庫獲取自增的id，即就是每次從數據庫取出一個號段范圍，如（1-3000]表示從數據庫中生成3000個自增id。數據表的設計如下：
業務申請號段的流程如下：
當一批號段用完之后，再次向數據庫申請新的號段，此方案的的優缺點如下表所示：
5、Redis實現分布式id
Redis提供的incr自增命令是單線程的操作，可以保證生成的id的唯一并有序的，我們聯合如時間戳值、機器標識組成一個具有特殊含義的唯一id，如下圖所示：
Redis生成唯一id的優缺點如下所示：
6、Zookeeper實現分布式id Zookeeper客戶端創建順序節點時會根據創建的時間順序，在節點名稱后添加 10 位的順序編號，利用Zookeeper的這個特性實現id的唯一性。
由于依賴Zookeeper并且存在多步的異步調用，如果競爭較大的的情況下還需要考慮使用分布式鎖，因為很少會使用Zookeeper來生成唯一id。 7、雪花算法 雪花算法是使用一個64bit的long類型數字作為全局唯一id，下圖是展示了雪花算法生成唯一id時候各個bit位的作用：
假設當前時間是2024-06-10 10:00:00，生成id的機器編號是7，序列號為1，據此雪花算法生成的id如下所示：
轉為十進制如下：
雖然這樣就可以生成一個唯一的id，但是雪花算法有如下的問題： （1）雪花算法嚴重的依賴時鐘，如果出現時鐘回撥就會導致重復生成id；解決時鐘回撥的一種方式就是將代表機器碼的十位拆出三位出來表示時鐘序列，如下圖：
當發生時鐘回撥的時候，此時時間已經發生了變化，那么這時將時鐘序列新增1位，重新定義整個雪花Id；為了避免實例重啟引起時間序列丟失，時鐘序列最好通過數據庫或者緩存等方式存儲起來。 （2）41bit最大的時間跨度是69年，后面會發生41比特位不夠使用；解決方案是生成時間戳之后減去系統上線時候的時間。 8、百度uid-generator uid-generator是基于雪花算法實現的，uid-generator不同點在于它支持自定義時間戳、機器id和序列號等個部分的信息，其組成部分如下所示：
uid-generator的項目地址：
uid-generator具有高性能、去中心化、強一致性和易用性等特點而廣泛的應用與生成數據庫主鍵、訂單編號和消息追蹤等場合下。 9、美團的Leaf 美團的Leaf同時兼具了數據庫號段模式和雪花算法，它可以試下可以根據不同業務場景靈活切換。 Leaf項目Github地址：
美團的Leaf詳細兩種模式介紹文檔：
我們根據實際的業務特性來選擇合適的ID生成方式。 10、滴滴的Tinyid Tinyid是在美團的ID生成算法Leaf的基礎上擴展而來，是基于數據庫的號段模式實現的，支持數據庫多主節點模式。如下圖如下所示：
項目的地址：
Tinyid提供了REST API和Java客戶端兩種獲取方式，相對來說使用更方便，目前在滴滴客服部門使用，且通過tinyid-client方式接入，每天生成的是億級別的id。性能上還是很高的。 總結： （1）分布式id生成方式有很多種方案，我們需要依據實際的業務場景來選擇合適的方案。 該文章在 2024/7/22 9:00:26 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
