我們一般對(duì)分布式id會(huì)有什么訴求，一個(gè)好的分布式id生成策略君纫，應(yīng)該具備哪些要素？其實(shí)還是由業(yè)務(wù)決定的（廢話芹彬，啥不是由業(yè)務(wù)決定- -Ｐ钏琛），但一些通用的訴求大致可以總結(jié)為以下幾點(diǎn)吧:

1. 全局唯一性：這是最基本的要求舒帮。
2. 信息安全：說到id,我們總會(huì)不自覺地想到mysql自增id 会喝，這其實(shí)很不安全，一看id就能大致猜測(cè)出來我們系統(tǒng)每天的業(yè)務(wù)量玩郊，也容易被暴力窮舉肢执。
3. 高 QPS : 如果因?yàn)?id 生成而成為業(yè)務(wù)的瓶頸，是不是有點(diǎn)尷尬译红？
4. 趨勢(shì)遞增：在 MySQL InnoDB 引擎中使用的是聚集索引预茄，用 B-tree 的數(shù)據(jù)結(jié)構(gòu)來存儲(chǔ)索引數(shù)據(jù)，在主鍵的選擇上面我們應(yīng)該盡量使用有序的主鍵保證寫入性能侦厚。
5. 高可用 : 如今這年代耻陕，高可用是一個(gè)永遠(yuǎn)逃不開的命題，我們應(yīng)該能在任何時(shí)候刨沦，都能保證id能被生成出來诗宣，局部掛了，不能影響整體服務(wù)想诅。
6. id 生成要盡量少的依賴其他組件：依賴的組件越多召庞，理論上越?jīng)]法保證高可用（如果依賴組建掛了），也可能意味著你的業(yè)務(wù)方接入代價(jià)會(huì)比較高来破，出錯(cuò)了篮灼，排錯(cuò)代價(jià)也會(huì)比較高

目前市場(chǎng)上流行的方案

UUID

• 優(yōu)點(diǎn)：本地生成，沒有高可用風(fēng)險(xiǎn)徘禁，性能好
• 缺點(diǎn)：長(zhǎng)度過長(zhǎng)诅诱，存儲(chǔ)冗余，且無序不可讀晌坤，查詢效率低

使用MySQL 的 auto_increment

• 優(yōu)點(diǎn)：數(shù)據(jù)庫(kù)生成的 ID 絕對(duì)有序逢艘，高可用實(shí)現(xiàn)方式簡(jiǎn)單（使用兩臺(tái)數(shù)據(jù)庫(kù)分別設(shè)置不同步長(zhǎng)，生成不重復(fù) ID 的策略來實(shí)現(xiàn)高可用）
• 缺點(diǎn)：需要獨(dú)立部署數(shù)據(jù)庫(kù)實(shí)例骤菠，成本高它改，有性能瓶頸，上面也說過商乎，絕對(duì)有序會(huì)造成信息安全問題央拖，我們的業(yè)務(wù)量可猜測(cè)，窮舉

利用數(shù)據(jù)庫(kù)分段批量生成 ID

在上一個(gè)方案的基礎(chǔ)上鹉戚，改為利用 proxy server 批量獲取鲜戒，每次獲取一個(gè) segment(step 決定大小) 號(hào)段的值。用完之后再去數(shù)據(jù)庫(kù)獲取新的號(hào)段抹凳，可以大大的減輕數(shù)據(jù)庫(kù)的壓力

• 優(yōu)點(diǎn)：基本同上一個(gè)方案遏餐，在上一個(gè)方案基礎(chǔ)上有巨大的性能提升
• 缺點(diǎn)：也基本上同上一個(gè)方案，DB 宕機(jī)仍然會(huì)造成整個(gè)系統(tǒng)不可用赢底。

Redis 生成 ID

Redis 的所有命令操作都是單線程的失都，本身提供像 incr 和 increby 這樣的自增原子命令，所以能保證生成的 ID 肯定是唯一有序的幸冻。

• 優(yōu)點(diǎn)：數(shù)字 ID 天然排序粹庞，redis性能也比較好。
• 缺點(diǎn)：ID 號(hào)碼不夠隨機(jī)洽损，仍然有安全問題庞溜，類似DB方案，仍然強(qiáng)依賴了三方組件 碑定，如果redis不可用流码，會(huì)影響服務(wù)

Twitter 的雪花算法（snowflake）【推薦】

如果大家百度下雪花算法，介紹一大堆延刘。這里仍然作下簡(jiǎn)要介紹旅掂。雪花算法大致來說是一種以劃分命名空間來生成 ID 的一種算法，這種方案把 64-bit 分別劃分成多段访娶，分開來標(biāo)示機(jī)器商虐、時(shí)間等。snowflake 中的 64-bit 分別表示如下圖所示：

image.png

41-bit 的時(shí)間可以表示（1L<<41）/(1000L360024*365)=69 年的時(shí)間崖疤，10-bit 機(jī)器可以分別表示 1024 臺(tái)機(jī)器秘车。如果我們對(duì) IDC 劃分有需求，還可以將 10-bit 分 5-bit 給 IDC劫哼，分 5-bit 給工作機(jī)器叮趴。這樣就可以表示 32 個(gè) IDC，每個(gè) IDC 下可以有 32 臺(tái)機(jī)器权烧，可以根據(jù)自身需求定義眯亦。12 個(gè)自增序列號(hào)可以表示 2^12 = 4096 個(gè) ID伤溉，理論上 snowflake 方案的 QPS 約為 409.6w/s，這種分配方式可以保證在任何一個(gè) IDC 的任何一臺(tái)機(jī)器在任意毫秒內(nèi)生成的 ID 都是不同的妻率。

• 優(yōu)點(diǎn)：基本符合了我們上面提出的各個(gè)要求

1. 毫秒數(shù)在高位乱顾，自增序列在低位，整個(gè) ID 都是趨勢(shì)遞增的宫静。
2. 不依賴數(shù)據(jù)庫(kù)等第三方系統(tǒng)走净，生成 ID 的性能也是非常高的。
3. 可以根據(jù)自身業(yè)務(wù)特性分配 bit 位孤里，非常靈活伏伯。

• 缺點(diǎn)：

1. 強(qiáng)依賴機(jī)器時(shí)鐘，如果機(jī)器上時(shí)鐘回?fù)埽瑫?huì)導(dǎo)致發(fā)號(hào)重復(fù)或者服務(wù)會(huì)處于不可用狀態(tài)。
2. 分布式情況下伍绳，我們需要確定機(jī)器的編號(hào)，機(jī)器量小的情況下蜓堕，完全可以手工編號(hào)，但是有新機(jī)器加入博其，就需要新編號(hào)套才，帶來額外工作量，機(jī)器多的情況下慕淡，手工和配置都是不小的維護(hù)量

總結(jié)

再回顧開頭對(duì)分布式id的需求分析背伴，雪花算法綜合來說是一個(gè)比較優(yōu)的方案。代碼實(shí)現(xiàn)也是百度一下一大把峰髓，這里貼一個(gè)美團(tuán)點(diǎn)評(píng)的實(shí)現(xiàn)傻寂。核心實(shí)現(xiàn)類https://github.com/Meituan-Dianping/Leaf/blob/master/leaf-core/src/main/java/com/sankuai/inf/leaf/snowflake/SnowflakeIDGenImpl.java
對(duì)于上面雪花算法的缺點(diǎn)，比如時(shí)鐘回?fù)苄瑱C(jī)器編號(hào)等疾掰，一些三方優(yōu)化過的實(shí)現(xiàn)版本，都有相應(yīng)優(yōu)化徐紧，美團(tuán)也是静檬。比如

1. 通過弱依賴 zookeeper 解決機(jī)器編號(hào)問題（啟動(dòng)依賴，得到自己的機(jī)器編號(hào)后并级，會(huì)緩存拂檩。后續(xù) zookeeper 可掛，不影響）

2. 時(shí)鐘回?fù)埽和ㄟ^RPC請(qǐng)求獲得集群中各節(jié)點(diǎn)的機(jī)器時(shí)間嘲碧，取平均值稻励，來判斷本節(jié)點(diǎn)時(shí)鐘是否正常，從而做時(shí)鐘回?fù)艿难a(bǔ)償方案愈涩。仔細(xì)閱讀美團(tuán) github 開源的代碼望抽，貌似并沒有發(fā)現(xiàn)類似實(shí)現(xiàn)加矛，開源的有閹割？應(yīng)該是吧煤篙。下圖大致描述了服務(wù)啟動(dòng)流程圖

   
   
   image.png