什麼是分佈式系統唯一ID
在複雜分佈式系統中,往往需要對大量的數據和消息進行唯一標識。
如在金融、電商、支付、等產品的系統中,數據日漸增長,對數據分庫分表後需要有一個唯一ID來標識一條數據或消息,數據庫的自增ID顯然不能滿足需求,此時一個能夠生成全局唯一ID的系統是非常必要的。
分佈式系統唯一ID的特點
同時除了對ID號碼自身的要求,業務還對ID號生成系統的可用性要求極高,想象一下,如果ID生成系統癱瘓,這就會帶來一場災難。
由此總結下一個ID生成系統應該做到如下幾點:
平均延遲和TP999延遲都要儘可能低; 可用性5個9; 高QPS。分佈式系統唯一ID的實現方案
1.UUID
UUID(Universally Unique Identifier)的標準型式包含32個16進制數字,以連字號分為五段,形式為8-4-4-4-12的36個字符,示例:550e8400-e29b-41d4-a716-446655440000,到目前為止業界一共有5種方式生成UUID,詳情見IETF發佈的UUID規範 A Universally Unique IDentifier (UUID) URN Namespace。
優點:
性能非常高:本地生成,沒有網絡消耗。缺點:
不易於存儲:UUID太長,16字節128位,通常以36長度的字符串表示,很多場景不適用。 信息不安全:基於MAC地址生成UUID的算法可能會造成MAC地址洩露,這個漏洞曾被用於尋找梅麗莎病毒的製作者位置。 ID作為主鍵時在特定的環境會存在一些問題,比如做DB主鍵的場景下,UUID就非常不適用:2.數據庫生成
以MySQL舉例,利用給字段設置auto_increment_increment和auto_increment_offset來保證ID自增,每次業務使用下列SQL讀寫MySQL得到ID號。
這種方案的優缺點如下:
優點:
非常簡單,利用現有數據庫系統的功能實現,成本小,有DBA專業維護。 ID號單調自增,可以實現一些對ID有特殊要求的業務。缺點:
強依賴DB,當DB異常時整個系統不可用,屬於致命問題。配置主從複製可以儘可能的增加可用性,但是數據一致性在特殊情況下難以保證。主從切換時的不一致可能會導致重複發號。 ID發號性能瓶頸限制在單臺MySQL的讀寫性能。3.Redis生成ID
當使用數據庫來生成ID性能不夠要求的時候,我們可以嘗試使用Redis來生成ID。
這主要依賴於Redis是單線程的,所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY來實現。
比較適合使用Redis來生成每天從0開始的流水號。比如訂單號=日期+當日自增長號。可以每天在Redis中生成一個Key,使用INCR進行累加。
優點:
1)不依賴於數據庫,靈活方便,且性能優於數據庫。
2)數字ID天然排序,對分頁或者需要排序的結果很有幫助。
1)如果系統中沒有Redis,還需要引入新的組件,增加系統複雜度。
2)需要編碼和配置的工作量比較大。
4.利用zookeeper生成唯一ID
zookeeper主要通過其znode數據版本來生成序列號,可以生成32位和64位的數據版本號,客戶端可以使用這個版本號來作為唯一的序列號。
很少會使用zookeeper來生成唯一ID。主要是由於需要依賴zookeeper,並且是多步調用API,如果在競爭較大的情況下,需要考慮使用分佈式鎖。因此,性能在高併發的分佈式環境下,也不甚理想。
5.snowflake(雪花算法)方案
這種方案大致來說是一種以劃分命名空間(UUID也算,由於比較常見,所以單獨分析)來生成ID的一種算法,這種方案把64-bit分別劃分成多段,分開來標示機器、時間等,比如在snowflake中的64-bit分別表示如下圖(圖片來自網絡)所示:
41-bit的時間可以表示(1L<<41)/(1000L*3600*24*365)=69年的時間,10-bit機器可以分別表示1024臺機器。如果我們對IDC劃分有需求,還可以將10-bit分5-bit給IDC,分5-bit給工作機器。這樣就可以表示32個IDC,每個IDC下可以有32臺機器,可以根據自身需求定義。12個自增序列號可以表示2^12個ID,理論上snowflake方案的QPS約為409.6w/s,這種分配方式可以保證在任何一個IDC的任何一臺機器在任意毫秒內生成的ID都是不同的。
這種方式的優缺點是:
優點:
缺點:
強依賴機器時鐘,如果機器上時鐘回撥,會導致發號重複或者服務會處於不可用狀態。應用舉例Mongdb objectID
MongoDB官方文檔 ObjectID可以算作是和snowflake類似方法,通過“時間+機器碼+pid+inc”共12個字節,通過4+3+2+3的方式最終標識成一個24長度的十六進制字符。