[[409671]]

一 .什么是分布式ID

在分布式系統(tǒng)中，經(jīng)常需要一些全局唯一的ID對(duì)數(shù)據(jù)、消息、http請(qǐng)求等進(jìn)行唯一標(biāo)識(shí)。那么這個(gè)全局唯一ID就叫分布式ID

二 .為什么需要分布式ID

1.如果id我們使用的是數(shù)據(jù)庫(kù)的自增長(zhǎng)類型，在分布式系統(tǒng)中需要分庫(kù)和分表時(shí)，會(huì)有兩個(gè)相同的表，有可能產(chǎn)生主鍵沖突。

2.電商訂單號(hào)，采用自增方式，是最簡(jiǎn)單的生成規(guī)則。但是!這種與流水號(hào)相同的訂單號(hào)很容易就被競(jìng)爭(zhēng)對(duì)手看出你公司真實(shí)的運(yùn)營(yíng)信息。

三 .分布式ID需要滿足哪些條件

全局唯一：必須保證ID是全局性唯一的

高性能：高可用低延時(shí)，ID生成響應(yīng)要快，否則會(huì)成為業(yè)務(wù)瓶頸

高可用：100%的可用性是騙人的，但是也要無限接近于100%的可用性

好接入：要秉著拿來即用的設(shè)計(jì)原則，在系統(tǒng)設(shè)計(jì)和實(shí)現(xiàn)上要盡可能的簡(jiǎn)單

趨勢(shì)遞增：最好趨勢(shì)遞增，這個(gè)要求就得看具體業(yè)務(wù)場(chǎng)景了，一般不嚴(yán)格要求

安全性：如果ID連續(xù)生成，勢(shì)必會(huì)泄露業(yè)務(wù)信息，甚至可能被猜出，所以需要無規(guī)則不規(guī)則。

易讀性：不要太長(zhǎng)，想象一下用戶在售后的時(shí)候本身就處在一個(gè)焦躁的心情中，再讓他報(bào)/輸一個(gè)很長(zhǎng)的訂單號(hào)，很容易造成錯(cuò)誤率高，這個(gè)時(shí)候只能煩上加煩。如果訂單號(hào)實(shí)在太長(zhǎng)，還有一種辦法：斷句。

可擴(kuò)展性：淘寶的訂單號(hào)在最初的時(shí)候也還是12位、14位，現(xiàn)在已經(jīng)變成16位了，隨著一個(gè)網(wǎng)站的交易量逐年上升，訂單號(hào)不可避免的會(huì)變長(zhǎng)。

四 .分布式ID生成方式

• UUID
• 數(shù)據(jù)庫(kù)自增ID
• 數(shù)據(jù)庫(kù)多主模式
• 號(hào)段模式
• Redis
• 雪花算法(SnowFlake)
• 美團(tuán)(Leaf)

注：主流生成ID方案都是基于數(shù)據(jù)庫(kù)號(hào)段模式和雪花算法

五 .優(yōu)缺點(diǎn)

1. 基于UUID

優(yōu)點(diǎn)：

• 生成足夠簡(jiǎn)單，本地生成無網(wǎng)絡(luò)消耗，具有唯一性

缺點(diǎn)：

• 無序的字符串，不具備趨勢(shì)自增特性
• 沒有具體的業(yè)務(wù)含義
• 長(zhǎng)度過長(zhǎng)16字節(jié)128位，36位長(zhǎng)度的字符串，存儲(chǔ)以及查詢對(duì)MySQL的性能消耗較大，MySQL官方明確建議主鍵要盡量越短越好，作為數(shù)據(jù)庫(kù)主鍵UUID的無序性會(huì)導(dǎo)致數(shù)據(jù)位置頻繁變動(dòng)，嚴(yán)重影響性能。

2. 基于數(shù)據(jù)庫(kù)自增ID

當(dāng)我們需要一個(gè)ID的時(shí)候，向表中插入一條記錄返回主鍵ID，但這種方式有一個(gè)比較致命的缺點(diǎn)，訪問量激增時(shí)MySQL本身就是系統(tǒng)的瓶頸，用它來實(shí)現(xiàn)分布式服務(wù)風(fēng)險(xiǎn)比較大，不推薦!

優(yōu)點(diǎn)：

實(shí)現(xiàn)簡(jiǎn)單，ID單調(diào)自增，數(shù)值類型查詢速度快

缺點(diǎn)：

DB單點(diǎn)存在宕機(jī)風(fēng)險(xiǎn)，無法扛住高并發(fā)場(chǎng)景

3. 基于數(shù)據(jù)庫(kù)集群模式

前邊說了單點(diǎn)數(shù)據(jù)庫(kù)方式不可取，那對(duì)上邊的方式做一些高可用優(yōu)化，換成主從模式集群。害怕一個(gè)主節(jié)點(diǎn)掛掉沒法用，那就做雙主模式集群，也就是兩個(gè)Mysql實(shí)例都能單獨(dú)的生產(chǎn)自增ID。那這樣還會(huì)有個(gè)問題，兩個(gè)MySQL實(shí)例的自增ID都從1開始，會(huì)生成重復(fù)的ID怎么辦?

解決方案：設(shè)置起始值和自增步長(zhǎng)

MySQL_1 配置：

set @@auto_increment_offset = 1; -- 起始值 
set @@auto_increment_increment = 2; -- 步長(zhǎng) 

 MySQL_2 配置：

set @@auto_increment_offset = 2;     -- 起始值 
set @@auto_increment_increment = 2;  -- 步長(zhǎng) 

這樣兩個(gè)MySQL實(shí)例的自增ID分別就是：

1、3、5、7、9  
2、4、6、8、10 

那如果集群后的性能還是扛不住高并發(fā)咋辦?就要進(jìn)行MySQL擴(kuò)容增加節(jié)點(diǎn)，這是一個(gè)比較麻煩的事。

增加第三臺(tái)MySQL實(shí)例需要人工修改一、二兩臺(tái)MySQL實(shí)例的起始值和步長(zhǎng)，把第三臺(tái)機(jī)器的ID起始生成位置設(shè)定在比現(xiàn)有最大自增ID的位置遠(yuǎn)一些，但必須在一、二兩臺(tái)MySQL實(shí)例ID還沒有增長(zhǎng)到第三臺(tái)MySQL實(shí)例的起始ID值的時(shí)候，否則自增ID就要出現(xiàn)重復(fù)了，必要時(shí)可能還需要停機(jī)修改。

優(yōu)點(diǎn)：

• 解決DB單點(diǎn)問題

缺點(diǎn)：

• 不利于后續(xù)擴(kuò)容，而且實(shí)際上單個(gè)數(shù)據(jù)庫(kù)自身壓力還是大，依舊無法滿足高并發(fā)場(chǎng)景。

4. 基于數(shù)據(jù)庫(kù)的號(hào)段模式

號(hào)段模式是當(dāng)下分布式ID生成器的主流實(shí)現(xiàn)方式之一，號(hào)段模式可以理解為從數(shù)據(jù)庫(kù)批量的獲取自增ID，每次從數(shù)據(jù)庫(kù)取出一個(gè)號(hào)段范圍，例如 (1,1000] 代表1000個(gè)ID，具體的業(yè)務(wù)服務(wù)將本號(hào)段，生成1~1000的自增ID并加載到內(nèi)存。

由于多業(yè)務(wù)端可能同時(shí)操作，所以采用版本號(hào)version樂觀鎖方式更新，這種分布式ID生成方式不強(qiáng)依賴于數(shù)據(jù)庫(kù)，不會(huì)頻繁的訪問數(shù)據(jù)庫(kù)，對(duì)數(shù)據(jù)庫(kù)的壓力小很多。

5. 基于Redis模式

利用redis的incr命令實(shí)現(xiàn)ID的原子性自增。

127.0.0.1:6379> set seq_id 1     // 初始化自增ID為1 
OK 
127.0.0.1:6379> incr seq_id      // 增加1，并返回遞增后的數(shù)值 
(integer) 2 

用redis實(shí)現(xiàn)需要注意一點(diǎn)，要考慮到redis持久化的問題。redis有兩種持久化方式RDB和AOF

• RDB會(huì)定時(shí)打一個(gè)快照進(jìn)行持久化，假如連續(xù)自增但redis沒及時(shí)持久化，而這會(huì)Redis掛掉了，重啟Redis后會(huì)出現(xiàn)ID重復(fù)的情況。
• AOF會(huì)對(duì)每條寫命令進(jìn)行持久化，即使Redis掛掉了也不會(huì)出現(xiàn)ID重復(fù)的情況，但由于incr命令的特殊性，會(huì)導(dǎo)致Redis重啟恢復(fù)的數(shù)據(jù)時(shí)間過長(zhǎng)。

6. 基于雪花算法(Snowflake)模式

雪花算法(Snowflake)是twitter公司內(nèi)部分布式項(xiàng)目采用的ID生成算法

Snowflake生成的是Long類型的ID，一個(gè)Long類型占8個(gè)字節(jié)，每個(gè)字節(jié)占8比特，也就是說一個(gè)Long類型占64個(gè)比特。Snowflake ID組成結(jié)構(gòu)：正數(shù)位(占1比特)+ 時(shí)間戳(占41比特)+ 機(jī)器ID(占5比特)+ 數(shù)據(jù)中心(占5比特)+ 自增值(占12比特)，總共64比特組成的一個(gè)Long類型。

• 第一個(gè)bit位(1bit)：Java中l(wèi)ong的最高位是符號(hào)位代表正負(fù)，正數(shù)是0，負(fù)數(shù)是1，一般生成ID都為正數(shù)，所以默認(rèn)為0。
• 時(shí)間戳部分(41bit)：毫秒級(jí)的時(shí)間，不建議存當(dāng)前時(shí)間戳，而是用(當(dāng)前時(shí)間戳 - 固定開始時(shí)間戳)的差值，可以使產(chǎn)生的ID從更小的值開始;41位的時(shí)間戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
• 工作機(jī)器id(10bit)：也被叫做workId，這個(gè)可以靈活配置，機(jī)房或者機(jī)器號(hào)組合都可以。
• 序列號(hào)部分(12bit)，自增值支持同一毫秒內(nèi)同一個(gè)節(jié)點(diǎn)可以生成4096個(gè)ID

根據(jù)這個(gè)算法的邏輯，只需要將這個(gè)算法用Java語(yǔ)言實(shí)現(xiàn)出來，封裝為一個(gè)工具方法，那么各個(gè)業(yè)務(wù)應(yīng)用可以直接使用該工具方法來獲取分布式ID，只需保證每個(gè)業(yè)務(wù)應(yīng)用有自己的工作機(jī)器id即可，而不需要單獨(dú)去搭建一個(gè)獲取分布式ID的應(yīng)用。

雪花算法目前存在時(shí)間回?fù)軉栴}，而且不同的機(jī)器也無法完全保證時(shí)間一樣，所以可能會(huì)出現(xiàn)重復(fù)問題。

7. 美團(tuán)(Leaf)

Leaf由美團(tuán)開發(fā)，支持號(hào)段模式和snowflake算法模式，可以切換使用。