多IDC環境下的分佈式id分配方案

id分配是社區類產品的提交環節中必不可少的一步。任何UGC類內容產生時每每須要分配一個對應的id。

id分配的幾種方式 

方式一：單點自增分配。全局由一個模塊來負責生成id，可保證id從0開始連續遞增，數據通常放在本地文件。簡潔，但致命的問題是單點故障會致使服務總體不可用。

方式一改進：爲該模塊提供主從複製的能力，或者乾脆將數據放在mysql裏，利用mysql的主從複製，都必定程度上加強了可用性，減輕了單點故障的影響。

方式二：隨機/散列分配。經過一些hash算法，好比以時間+隨機串爲key的md5生成一個惟一的id，關鍵點在於算法和key的選擇要避免衝突。

最典型的就是UUID，UUID的標準型式包含32個16進位數字，以連字號分爲五段，形式爲8-4-4-4-12的32個字符，如550e8400-e29b-41d4-a716-446655440000。libuuid提供了以時間或者隨機數爲基的UUID。UUID的最大缺點是位數太長，128位，在絕大多數應用和語言裏對128位整數的支持都很差。

方式二改進：有條件的進行壓縮。twitter的snowflake使用 time – 41 bits + configured machine id – 10 bits + sequence number – 12 bits的形式分配id，共63位，最高部分使用毫秒級的時間戳，保證了必定程度的有序性，機器標示使用10位，最多可容納1024個分配器，最後的12位序列號能夠支持在1ms內產生4096個不重複的id。從工程角度，這些都足夠用了。但對系統時間的依賴性很是強，須要關閉ntp的時間同步功能，或者當檢測到ntp時間調整後，拒絕分配id。

 

咱們的需求和多IDC的挑戰

咱們的實際狀況是：

· 一些老模塊依賴於從0開始自增的id，數據在內存或者文件中以id爲偏移來存儲的。

· 一些系統依賴於id的增加作數據分片，例如按取除後分表，所以要求id在總體上是比較均衡的增加。

· 在多IDC環境，高延遲加不穩定的網絡環境，要求各個分配器彼此之間無需協做，或者能夠容忍短時間內不可協做。

· 對於一些古董級的老系統來講，還在使用32位的id，63位id仍是太大了。

所以，咱們須要一種分佈式高可用、從0開始自增、基本均衡、可以兼容老系統的id分配方案。

取模或分段的分佈式分配

基於方案一再改進一步，將整個id空間按取模或分段等分爲若干個獨立的id子空間，每一個id子空間由一個獨立的分配器負責。

優勢：簡單，各個id分配器無需協做，即便發生網絡劃分時，也可保證可用性和id的不衝突。

若是在國際化環境的多IDC裏進行部署，須要預先將id空間劃分爲N份，每一個國家裏部署若干份。每一個IDC內應用只連本IDC的id分配服務。

在均衡性上的不足：在同一個IDC內，均衡性能夠在接入層均衡算法保證，可是在多個IDC裏，ID分配器個數的比例和id增加的服務每每是不吻合的，所以在多個IDC內，id是沒法保證均衡增加的。

均衡性上的改進

將id分配分爲兩層：

· 上層的「id分配器」對應用暴露，提供一次申請一個id的接口，通常本IDC的應用只連本IDC的id分配器。

·下層的「段分配器」對「id分配器」提供服務。id分配器「知曉」全部IDC的全部段分配器的存在，使用均衡策略向段分配器申請一個id段，當所持有的id段快耗盡時，再請求下一個段。

 

惟一性：全局中，根據分片規則，每一個段分配器會持有不一樣的id段。例以下表中，每一個段的大小是100，段分配器A持有分片0和分片1。對於每一個分片而言，是一個個跳躍的id段。特殊的，當段大小爲1時，段分配器就是改進前的id分配器。

 

均衡策略：均衡策略在id分配器來實現，簡單的講，是一個輪詢策略。每一個id分配器會輪詢下游段分配器的狀態，並選中id段的最小的那個，而後發起id段申請。因爲不會加鎖，當多個id分配器同時競爭時，可能會出現獲取的id段不是全局最小的，能夠附加一些策略來調優，好比再多獲取一次，並本地排序。從總體上而言，id仍是比較均衡的，可知足需求。

可用性：當發生網絡劃分時，本IDC的id分配器能夠只鏈接本IDC的段分配器，成功的申請到id段。整個系統可容忍必定時間內不可協做，長時間不可協做的惟一危害是id增加不均衡，此時，就退化爲改進前的方案。

多IDC環境的適應性：id分配器須要和全部IDC的段分配器交互，可是交互頻率很低，同時和提供id分配服務是兩個獨立的階段，不會受到多IDC網絡環境的干擾。

效果

改進後的id分配方案成功的知足了圖片系統重構過程當中的兼容需求，而且部署在全球多個IDC內爲圖片系統提供全局惟一的id分配服務。

by Lizhe