前言

在互聯(lián)網(wǎng)的業(yè)務(wù)系統(tǒng)中，涉及到各種各樣的ID，如在支付系統(tǒng)中就會(huì)有支付ID、退款I(lǐng)D等。那一般生成ID都有哪些解決方案呢？特別是在復(fù)雜的分布式系統(tǒng)業(yè)務(wù)場(chǎng)景中，我們應(yīng)該采用哪種適合自己的解決方案是十分重要的。下面我們一一來列舉一下，不一定全部適合，這些解決方案僅供你參考，或許對(duì)你有用。

正文

分布式ID的特性

• 唯一性：確保生成的ID是全網(wǎng)唯一的。

• 有序遞增性：確保生成的ID是對(duì)于某個(gè)用戶或者業(yè)務(wù)是按一定的數(shù)字有序遞增的。

• 高可用性：確保任何時(shí)候都能正確的生成ID。

• 帶時(shí)間：ID里面包含時(shí)間，一眼掃過去就知道哪天的交易。

分布式ID的生成方案

1. UUID

算法的核心思想是結(jié)合機(jī)器的網(wǎng)卡、當(dāng)?shù)貢r(shí)間、一個(gè)隨記數(shù)來生成UUID。

• 優(yōu)點(diǎn)：本地生成，生成簡(jiǎn)單，性能好，沒有高可用風(fēng)險(xiǎn)

• 缺點(diǎn)：長(zhǎng)度過長(zhǎng)，存儲(chǔ)冗余，且無序不可讀，查詢效率低

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

使用數(shù)據(jù)庫(kù)的id自增策略，如 MySQL 的 auto_increment。并且可以使用兩臺(tái)數(shù)據(jù)庫(kù)分別設(shè)置不同步長(zhǎng)，生成不重復(fù)ID的策略來實(shí)現(xiàn)高可用。

• 優(yōu)點(diǎn)：數(shù)據(jù)庫(kù)生成的ID絕對(duì)有序，高可用實(shí)現(xiàn)方式簡(jiǎn)單

• 缺點(diǎn)：需要獨(dú)立部署數(shù)據(jù)庫(kù)實(shí)例，成本高，有性能瓶頸

3. 批量生成ID

一次按需批量生成多個(gè)ID，每次生成都需要訪問數(shù)據(jù)庫(kù)，將數(shù)據(jù)庫(kù)修改為最大的ID值，并在內(nèi)存中記錄當(dāng)前值及最大值。

• 優(yōu)點(diǎn)：避免了每次生成ID都要訪問數(shù)據(jù)庫(kù)并帶來壓力，提高性能

• 缺點(diǎn)：屬于本地生成策略，存在單點(diǎn)故障，服務(wù)重啟造成ID不連續(xù)

4. Redis生成ID

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

• 優(yōu)點(diǎn)：不依賴于數(shù)據(jù)庫(kù)，靈活方便，且性能優(yōu)于數(shù)據(jù)庫(kù)；數(shù)字ID天然排序，對(duì)分頁(yè)或者需要排序的結(jié)果很有幫助。

• 缺點(diǎn)：如果系統(tǒng)中沒有Redis，還需要引入新的組件，增加系統(tǒng)復(fù)雜度；需要編碼和配置的工作量比較大。
  

考慮到單節(jié)點(diǎn)的性能瓶頸，可以使用 Redis 集群來獲取更高的吞吐量。假如一個(gè)集群中有5臺(tái) Redis?？梢猿跏蓟颗_(tái) Redis 的值分別是1, 2, 3, 4, 5，然后步長(zhǎng)都是 5。各個(gè) Redis 生成的 ID 為：

隨便負(fù)載到哪個(gè)機(jī)確定好，未來很難做修改。步長(zhǎng)和初始值一定需要事先確定。使用 Redis 集群也可以方式單點(diǎn)故障的問題。

另外，比較適合使用 Redis 來生成每天從0開始的流水號(hào)。比如訂單號(hào) = 日期 + 當(dāng)日自增長(zhǎng)號(hào)?？梢悦刻煸?Redis 中生成一個(gè) Key ，使用 INCR 進(jìn)行累加。

5. Twitter的snowflake算法

Twitter 利用 zookeeper 實(shí)現(xiàn)了一個(gè)全局ID生成的服務(wù) Snowflake：https://github.com/twitter/snowflake

如上圖的所示，Twitter 的 Snowflake 算法由下面幾部分組成：

• 1位符號(hào)位：

由于 long 類型在 java 中帶符號(hào)的，最高位為符號(hào)位，正數(shù)為 0，負(fù)數(shù)為 1，且實(shí)際系統(tǒng)中所使用的ID一般都是正數(shù)，所以最高位為 0。

• 41位時(shí)間戳（毫秒級(jí)）：

需要注意的是此處的 41 位時(shí)間戳并非存儲(chǔ)當(dāng)前時(shí)間的時(shí)間戳，而是存儲(chǔ)時(shí)間戳的差值（當(dāng)前時(shí)間戳 - 起始時(shí)間戳），這里的起始時(shí)間戳一般是ID生成器開始使用的時(shí)間戳，由程序來指定，所以41位毫秒時(shí)間戳最多可以使用 (1<<41)/(1000x60x60x24x365)=69年。

• 10位數(shù)據(jù)機(jī)器位：

包括5位數(shù)據(jù)標(biāo)識(shí)位和5位機(jī)器標(biāo)識(shí)位，這10位決定了分布式系統(tǒng)中最多可以部署 1<<10=1024 s個(gè)節(jié)點(diǎn)。超過這個(gè)數(shù)量，生成的ID就有可能會(huì)沖突。

• 12位毫秒內(nèi)的序列：

這 12 位計(jì)數(shù)支持每個(gè)節(jié)點(diǎn)每毫秒（同一臺(tái)機(jī)器，同一時(shí)刻）最多生成 1<<12=4096個(gè)ID

加起來剛好64位，為一個(gè)Long型。

• 優(yōu)點(diǎn)：高性能，低延遲，按時(shí)間有序，一般不會(huì)造成ID碰撞

• 缺點(diǎn)：需要獨(dú)立的開發(fā)和部署，依賴于機(jī)器的時(shí)鐘

簡(jiǎn)單實(shí)現(xiàn)

6. 百度UidGenerator

UidGenerator是百度開源的分布式ID生成器，基于于snowflake算法的實(shí)現(xiàn)，看起來感覺還行。不過，國(guó)內(nèi)開源的項(xiàng)目維護(hù)性真是擔(dān)憂。

具體可以參考官網(wǎng)說明：https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md

7. 美團(tuán)Leaf

Leaf 是美團(tuán)開源的分布式ID生成器，能保證全局唯一性、趨勢(shì)遞增、單調(diào)遞增、信息安全，里面也提到了幾種分布式方案的對(duì)比，但也需要依賴關(guān)系數(shù)據(jù)庫(kù)、Zookeeper等中間件。

具體可以參考官網(wǎng)說明：https://tech.meituan.com/MT_Leaf.html

小結(jié)

這篇文章和大家分享了全局id生成服務(wù)的幾種常用方案，同時(shí)對(duì)比了各自的優(yōu)缺點(diǎn)和適用場(chǎng)景。在實(shí)際工作中，大家可以結(jié)合自身業(yè)務(wù)和系統(tǒng)架構(gòu)體系進(jìn)行合理選型。