一、為什麼選擇分布式ID?
1.什麼是分布式ID?
拿MySQL資料庫舉例：
在我們業務資料量不大的時候，單庫單表完全可以支撐現有業務，資料再大一點搞個MySQL主從同步讀寫分離也能對付。
但随着資料日漸增長，主從同步也扛不住了，就需要對資料庫進行分庫分表，但分庫分表後需要有一個唯一ID來辨別一條資料，資料庫的自增ID顯然不能滿足需求；特别一點的如訂單、優惠券也都需要有唯一ID做辨別。此時一個能夠生成全局唯一ID的系統是非常必要的。那麼這個全局唯一ID就叫分布式ID。
2.分布式ID需要滿足哪些條件？
全局唯一：必須保證ID是全局性唯一的，基本要求
高性能：高可用低延時，ID生成響應要塊，否則反倒會成為業務瓶頸
高可用：100%的可用性是騙人的，但是也要無限接近于100%的可用性
好接入：要秉着拿來即用的設計原則，在系統設計和實作上要盡可能的簡單
趨勢遞增：最好趨勢遞增，這個要求就得看具體業務場景了，一般不嚴格要求
二.分布式ID生成方式？
UUID
資料庫自增ID
資料庫多主模式
号段模式
Redis
雪花算法（SnowFlake）
滴滴出品（TinyID）
百度 （Uidgenerator）
美團（Leaf）
1.UUID
首先想到的是UUID，那麼UUID可以做分布式ID嗎？可以，但是并不推薦
UUID的生成簡單到隻有一行代碼，輸出結果 6e9b11da414245e084ef9e7ec345044e，但UUID卻并不适用于實際的業務需求。像用作訂單号UUID這樣的字元串沒有絲毫的意義，看不出和訂單相關的有用資訊；而對于資料庫來說用作業務主鍵ID，它不僅是太長還是字元串，存儲性能差查詢也很耗時，是以不推薦用作分布式ID。
優點：
生成足夠簡單，本地生成無網絡消耗，具有唯一性。
缺點：
無序的字元串，不具備趨勢自增特性。
沒有具體的業務含義。
長度過長16 位元組128位，36位長度的字元串，存儲以及查詢對MySQL的性能消耗較大，MySQL官方明确建議主鍵要盡量越短越好，作為資料庫主鍵 UUID 的無序性會導緻資料位置頻繁變動，嚴重影響性能。
2.基于資料庫自增ID
基于資料庫的auto_increment自增ID完全可以充當分布式ID，具體實作：需要一個單獨的MySQL執行個體用來生成ID，建表結構如下：
當我們需要一個ID的時候，向表中插入一條記錄傳回主鍵ID，但這種方式有一個比較緻命的缺點，通路量激增時MySQL本身就是系統的瓶頸，用它來實作分布式服務風險比較大，不推薦！
實作簡單，ID單調自增，數值類型查詢速度快。
DB單點存在當機風險，無法扛住高并發場景。
3.基于資料庫叢集模式
前邊說了單點資料庫方式不可取，那對上邊的方式做一些高可用優化，換成主從模式叢集。害怕一個主節點挂掉沒法用，那就做雙主模式叢集，也就是兩個Mysql執行個體都能單獨的生産自增ID。
如此，就産生一個新的問題：兩個MySQL執行個體的自增ID都從1開始，會生成重複的ID怎麼辦？
解決方案：設定起始值和自增步長。
MySql_1配置：
MySql_2配置：
以上兩個MySql執行個體的自增ID是：1、3、5、7、9 2、4、6、8、10
那如果叢集後的性能還是扛不住高并發咋辦？就要進行MySQL擴容增加節點，這是一個比較麻煩的事。
從上圖可以看出，水準擴充的資料庫叢集，有利于解決資料庫單點壓力的問題，同時為了ID生成特性，将自增步長按照機器數量來設定。
增加第三台MySQL執行個體需要人工修改一、二兩台MySQL執行個體的起始值和步長，把第三台機器的ID起始生成位置設定在比現有最大自增ID的位置遠一些，但必須在一、二兩台MySQL執行個體ID還沒有增長到第三台MySQL執行個體的起始ID值的時候，否則自增ID就要出現重複了，必要時可能還需要停機修改。
解決DB單點問題。
不利于後續擴容，而且實際上單個資料庫自身壓力還是大，依舊無法滿足高并發場景。
4.基于資料庫的号段模式
号段模式是當下分布式ID生成器的主流實作方式之一，号段模式可以了解為從資料庫批量的擷取自增ID，每次從資料庫取出一個号段範圍，例如 (1,1000] 代表1000個ID，具體的業務服務将本号段，生成1~1000的自增ID并加載到記憶體。表結構如下：
biz_type ：代表不同業務類型
max_id ：目前最大的可用id
step ：代表号段的長度
version ：是一個樂觀鎖，每次都更新version，保證并發時資料的正确性
等這批号段ID用完，再次向資料庫申請新号段，對max_id字段做一次update操作，update max_id= max_id + step，update成功則說明新号段擷取成功，新的号段範圍是(max_id ,max_id +step]。
由于多業務端可能同時操作，是以采用版本号version樂觀鎖方式更新，這種分布式ID生成方式不強依賴于資料庫，不會頻繁的通路資料庫，對資料庫的壓力小很多。
5.基于Redis模式
Redis也同樣可以實作，原理就是利用redis的 incr指令實作ID的原子性自增。
用redis實作需要注意一點，要考慮到redis持久化的問題。redis有兩種持久化方式RDB和AOF：
(1)RDB會定時打一個快照進行持久化，假如連續自增但redis沒及時持久化，而這會Redis挂掉了，重新開機Redis後會出現ID重複的情況。
(2)AOF會對每條寫指令進行持久化，即使Redis挂掉了也不會出現ID重複的情況，但由于incr指令的特殊性，會導緻Redis重新開機恢複的資料時間過長。
6.基于雪花算法（Snowflake）模式
雪花算法（Snowflake）是twitter公司内部分布式項目采用的ID生成算法，開源後廣受國内大廠的好評，在該算法影響下各大公司相繼開發出各具特色的分布式生成器。
Snowflake生成的是Long類型的ID，一個Long類型占8個位元組，每個位元組占8比特，也就是說一個Long類型占64個比特。
Snowflake ID組成結構：正數位（占1比特）+ 時間戳（占41比特）+ 機器ID（占5比特）+ 資料中心（占5比特）+ 自增值（占12比特），總共64比特組成的一個Long類型。
(1)第一個bit位（1bit）：Java中long的最高位是符号位代表正負，正數是0，負數是1，一般生成ID都為正數，是以預設為0。
(2)時間戳部分（41bit）：毫秒級的時間，不建議存目前時間戳，而是用（目前時間戳 - 固定開始時間戳）的內插補點，可以使産生的ID從更小的值開始；41位的時間戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
(3)工作機器id（10bit）：也被叫做workId，這個可以靈活配置，機房或者機器号組合都可以。
(4)序列号部分（12bit），自增值支援同一毫秒内同一個節點可以生成4096個ID
根據這個算法的邏輯，隻需要将這個算法用Java語言實作出來，封裝為一個工具方法，那麼各個業務應用可以直接使用該工具方法來擷取分布式ID，隻需保證每個業務應用有自己的工作機器id即可，而不需要單獨去搭建一個擷取分布式ID的應用。
Java版本的Snowflake算法實作：
7.百度（uid-generator）
uid-generator是由百度技術部開發， 項目GitHub位址。
uid-generator是基于Snowflake算法實作的，與原始的snowflake算法不同在于，uid-generator支援自定義時間戳、工作機器ID和 序列号 等各部分的位數，而且uid-generator中采用使用者自定義workId的生成政策。
uid-generator需要與資料庫配合使用，需要新增一個WORKER_NODE表。當應用啟動時會向資料庫表中去插入一條資料，插入成功後傳回的自增ID就是該機器的workId資料由host，port組成。
對于uid-generator ID組成結構：
workId，占用了22個bit位，時間占用了28個bit位，序列化占用了13個bit位，需要注意的是，和原始的snowflake不太一樣，時間的機關是秒，而不是毫秒，workId也不一樣，而且同一應用每次重新開機就會消費一個workId。
8、美團（Leaf）
Leaf由美團開發，項目GitHub位址。
Leaf同時支援号段模式和snowflake算法模式，可以切換使用。
(1)号段模式
先導入源碼，位址。在建一張表leaf_table：
然後在項目中開啟号段模式，配置對應的資料庫資訊，并關閉snowflake模式。
啟動leaf-server 子產品的 LeafServerApplication項目就跑起來了。
号段模式擷取分布式自增ID的測試url ：http：//localhost：8080/api/segment/get/leaf-segment-test
監控号段模式：http://localhost:8080/cache
(2)snowflake模式
Leaf的snowflake模式依賴于ZooKeeper，不同于原始snowflake算法也主要是在workId的生成上，Leaf中workId是基于ZooKeeper的順序Id來生成的，每個應用在使用Leaf-snowflake時，啟動時都會都在Zookeeper中生成一個順序Id，相當于一台機器對應一個順序節點，也就是一個workId。
snowflake模式擷取分布式自增ID的測試url：http://localhost:8080/api/snowflake/get/test
9、滴滴（Tinyid）
Tinyid由滴滴開發，GitHub位址。
Tinyid是基于号段模式原理實作的與Leaf如出一轍，每個服務擷取一個号段（1000,2000]、（2000,3000]、（3000,4000]
Tinyid提供http和tinyid-client兩種方式接入：
(1)Http方式接入
a.導入Tinyid源碼：git clone 項目clone位址
b.建立資料表：
c.配置資料庫：
d.啟動tinyid-server後測試：
(2)Java用戶端方式接入
a.重複Http方式的（b）（c）操作。
b.引入依賴
c.配置檔案
test 、tinyid.token是在資料庫表中預先插入的資料，test 是具體業務類型，tinyid.token表示可通路的業務類型。