什么是分布式系統(tǒng)唯一ID

在復雜分布式系統(tǒng)中，往往需要對大量的數(shù)據(jù)和消息進行唯一標識。

如在金融、電商、支付、等產(chǎn)品的系統(tǒng)中，數(shù)據(jù)日漸增長，對數(shù)據(jù)分庫分表后需要有一個唯一ID來標識一條數(shù)據(jù)或消息，數(shù)據(jù)庫的自增ID顯然不能滿足需求，此時一個能夠生成全局唯一ID的系統(tǒng)是非常必要的。

分布式系統(tǒng)唯一ID的特點

全局唯一性：不能出現(xiàn)重復的ID號，既然是唯一標識，這是最基本的要求。

趨勢遞增：在MySQL InnoDB引擎中使用的是聚集索引，由于多數(shù)RDBMS使用B-tree的數(shù)據(jù)結(jié)構(gòu)來存儲索引數(shù)據(jù)，在主鍵的選擇上面我們應該盡量使用有序的主鍵保證寫入性能。

單調(diào)遞增：保證下一個ID一定大于上一個ID，例如事務版本號、IM增量消息、排序等特殊需求。

信息安全：如果ID是連續(xù)的，惡意用戶的扒取工作就非常容易做了，直接按照順序下載指定URL即可；如果是訂單號就更危險了，競對可以直接知道我們一天的單量。所以在一些應用場景下，會需要ID無規(guī)則、不規(guī)則。

同時除了對ID號碼自身的要求，業(yè)務還對ID號生成系統(tǒng)的可用性要求極高，想象一下，如果ID生成系統(tǒng)癱瘓，這就會帶來一場災難。

由此總結(jié)下一個ID生成系統(tǒng)應該做到如下幾點：

平均延遲和TP999延遲都要盡可能低；

可用性5個9；

高QPS。

分布式系統(tǒng)唯一ID的實現(xiàn)方案

1.UUID

UUID（Universally Unique Identifier）的標準型式包含32個16進制數(shù)字，以連字號分為五段，形式為8-4-4-4-12的36個字符，示例：550e8400-e29b-41d4-a716-446655440000，到目前為止業(yè)界一共有5種方式生成UUID，詳情見IETF發(fā)布的UUID規(guī)范 A Universally Unique IDentifier （UUID） URN Namespace。

優(yōu)點：

• 性能非常高：本地生成，沒有網(wǎng)絡消耗。

缺點：

• 不易于存儲：UUID太長，16字節(jié)128位，通常以36長度的字符串表示，很多場景不適用。
• 信息不安全：基于MAC地址生成UUID的算法可能會造成MAC地址泄露，這個漏洞曾被用于尋找梅麗莎病毒的制作者位置。
• ID作為主鍵時在特定的環(huán)境會存在一些問題，比如做DB主鍵的場景下，UUID就非常不適用：

2.數(shù)據(jù)庫生成

以MySQL舉例，利用給字段設置auto_increment_increment和auto_increment_offset來保證ID自增，每次業(yè)務使用下列SQL讀寫MySQL得到ID號。

這種方案的優(yōu)缺點如下：

優(yōu)點：

• 非常簡單，利用現(xiàn)有數(shù)據(jù)庫系統(tǒng)的功能實現(xiàn)，成本小，有DBA專業(yè)維護。
• ID號單調(diào)自增，可以實現(xiàn)一些對ID有特殊要求的業(yè)務。

缺點：

• 強依賴DB，當DB異常時整個系統(tǒng)不可用，屬于致命問題。配置主從復制可以盡可能的增加可用性，但是數(shù)據(jù)一致性在特殊情況下難以保證。主從切換時的不一致可能會導致重復發(fā)號。
• ID發(fā)號性能瓶頸限制在單臺MySQL的讀寫性能。

3.Redis生成ID

當使用數(shù)據(jù)庫來生成ID性能不夠要求的時候，我們可以嘗試使用Redis來生成ID。

這主要依賴于Redis是單線程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY來實現(xiàn)。

比較適合使用Redis來生成每天從0開始的流水號。比如訂單號=日期+當日自增長號。可以每天在Redis中生成一個Key，使用INCR進行累加。

優(yōu)點：

1）不依賴于數(shù)據(jù)庫，靈活方便，且性能優(yōu)于數(shù)據(jù)庫。

2）數(shù)字ID天然排序，對分頁或者需要排序的結(jié)果很有幫助。

缺點：

1）如果系統(tǒng)中沒有Redis，還需要引入新的組件，增加系統(tǒng)復雜度。

2）需要編碼和配置的工作量比較大。

4.利用zookeeper生成唯一ID

zookeeper主要通過其znode數(shù)據(jù)版本來生成序列號，可以生成32位和64位的數(shù)據(jù)版本號，客戶端可以使用這個版本號來作為唯一的序列號。

很少會使用zookeeper來生成唯一ID。主要是由于需要依賴zookeeper，并且是多步調(diào)用API，如果在競爭較大的情況下，需要考慮使用分布式鎖。因此，性能在高并發(fā)的分布式環(huán)境下，也不甚理想。

5.snowflake（雪花算法）方案

這種方案大致來說是一種以劃分命名空間（UUID也算，由于比較常見，所以單獨分析）來生成ID的一種算法，這種方案把64-bit分別劃分成多段，分開來標示機器、時間等，比如在snowflake中的64-bit分別表示如下圖（圖片來自網(wǎng)絡）所示：

41-bit的時間可以表示（1L<<41）/（1000L*3600*24*365）=69年的時間，10-bit機器可以分別表示1024臺機器。如果我們對IDC劃分有需求，還可以將10-bit分5-bit給IDC，分5-bit給工作機器。這樣就可以表示32個IDC，每個IDC下可以有32臺機器，可以根據(jù)自身需求定義。12個自增序列號可以表示2^12個ID，理論上snowflake方案的QPS約為409.6w/s，這種分配方式可以保證在任何一個IDC的任何一臺機器在任意毫秒內(nèi)生成的ID都是不同的。

這種方式的優(yōu)缺點是：

優(yōu)點：

• 毫秒數(shù)在高位，自增序列在低位，整個ID都是趨勢遞增的。
• 不依賴數(shù)據(jù)庫等第三方系統(tǒng)，以服務的方式部署，穩(wěn)定性更高，生成ID的性能也是非常高的。
• 可以根據(jù)自身業(yè)務特性分配bit位，非常靈活。

缺點：

• 強依賴機器時鐘，如果機器上時鐘回撥，會導致發(fā)號重復或者服務會處于不可用狀態(tài)。

應用舉例Mongdb objectID

MongoDB官方文檔 ObjectID可以算作是和snowflake類似方法，通過“時間+機器碼+pid+inc”共12個字節(jié)，通過4+3+2+3的方式最終標識成一個24長度的十六進制字符。

你可能也喜歡:

阿里P8架構(gòu)師談：分布式Session共享的4類技術(shù)方案，與優(yōu)劣勢比較

阿里P8架構(gòu)師談：分布式事務的解決方案，以及原理、總結(jié)

阿里P8架構(gòu)師談：分布式鎖的3種實現(xiàn)（數(shù)據(jù)庫、緩存、Zookeeper)

阿里P8架構(gòu)師談：架構(gòu)設計之數(shù)據(jù)庫垂直、水平拆分六大原則

阿里P8架構(gòu)師談：單點登錄的原理、來源、實現(xiàn)、以及技術(shù)方案比較

一篇文章徹底搞懂“分布式事務”

---

總結(jié)

以上是生活随笔為你收集整理的阿里P8架构师谈：分布式系统全局唯一ID简介、特点、5种生成方式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。