如何設(shè)計(jì)一個(gè)全局唯一的訂單號(hào)？
上了微服務(wù)之后，很多原本很簡(jiǎn)單的問(wèn)題現(xiàn)在都變復(fù)雜了，例如全局 ID 這事！
松哥最近工作中剛好用到這塊內(nèi)容，于是調(diào)研了市面上幾種常見的全局 ID 生成策略，稍微做了一下對(duì)比，供小伙伴們參考。
當(dāng)數(shù)據(jù)庫(kù)分庫(kù)分表之后，原本的主鍵自增就不方便繼續(xù)使用了，需要找到一個(gè)新的合適的方案，松哥的需求就是在這樣的情況下提出的。
接下來(lái)我們一起來(lái)捋一捋。
一 兩種思路
整體上來(lái)說(shuō)，這個(gè)問(wèn)題有兩種不同的思路：
- 讓數(shù)據(jù)庫(kù)自己搞定
- Java 代碼來(lái)處理主鍵，然后直接插入數(shù)據(jù)庫(kù)中即可。
這兩種思路又對(duì)應(yīng)了不同的方案，我們一個(gè)一個(gè)來(lái)看。
二 數(shù)據(jù)庫(kù)自己搞定
數(shù)據(jù)庫(kù)自己搞定，就是說(shuō)我在數(shù)據(jù)插入的時(shí)候，依然不考慮主鍵的問(wèn)題，希望繼續(xù)使用數(shù)據(jù)庫(kù)的主鍵自增，但是很明顯，原本默認(rèn)的主鍵自增現(xiàn)在沒法用了，我們必須有新的方案。
2.1 修改數(shù)據(jù)庫(kù)配置
數(shù)據(jù)庫(kù)分庫(kù)分表之后的結(jié)構(gòu)如下圖（假設(shè)數(shù)據(jù)庫(kù)中間件用的 MyCat）：
圖片
此時(shí)如果原本的 db1、db2、db3 繼續(xù)各自主鍵自增，那么對(duì)于 MyCat 而言，主鍵就不是自增了，主鍵就會(huì)重復(fù)，用戶從 MyCat 中查詢到的數(shù)據(jù)主鍵就有問(wèn)題。
找到問(wèn)題的原因，那么剩下的就好解決了。
我們可以直接修改 MySQL 數(shù)據(jù)庫(kù)主鍵自增的起始值和步長(zhǎng)。
首先我們可以通過(guò)如下 SQL 查看與此相關(guān)的兩個(gè)變量的取值：
SHOW VARIABLES LIKE 'auto_increment%'
圖片
可以看到，主鍵自增的起始值和步長(zhǎng)都是 1。
起始值好改，在定義表的時(shí)候就可以設(shè)置，步長(zhǎng)我們可以通過(guò)修改這個(gè)配置實(shí)現(xiàn)：
set @@auto_increment_increment=9;修改后，再去查看對(duì)應(yīng)的變量值，發(fā)現(xiàn)已經(jīng)變了：
圖片
此時(shí)我們?cè)偃ゲ迦霐?shù)據(jù)，主鍵自增就不是每次自增 1，而是每次自增 9 了。
至于自增起始值其實(shí)很好設(shè)置，創(chuàng)建表的時(shí)候就可以設(shè)置了。
create table test01(id integer PRIMARY KEY auto_increment,username varchar(255)) auto_increment=8;既然 MySQL 可以修改自增的起始值和每次增長(zhǎng)的步長(zhǎng)，現(xiàn)在假設(shè)我有 db1、db2 和 db3，我就可以分別設(shè)置這三個(gè)庫(kù)中表的自增起始值為 1、2、3，然后自增步長(zhǎng)都是 3，這樣就可以實(shí)現(xiàn)自增了。
但是很明顯這種方式不夠優(yōu)雅，而且處理起來(lái)很麻煩，將來(lái)擴(kuò)展也不方便，因此不推薦。
2.2 MySQL+MyCat+ZooKeeper
如果大家分庫(kù)分表工具恰好使用的是 MyCat，那么結(jié)合 Zookeeper 也能很好的實(shí)現(xiàn)主鍵全局自增。
MyCat 作為一個(gè)分布式數(shù)據(jù)庫(kù)中間，屏蔽了數(shù)據(jù)庫(kù)集群的操作，讓我們操作數(shù)據(jù)庫(kù)集群就像操作單機(jī)版數(shù)據(jù)庫(kù)一樣，對(duì)于主鍵自增，它有自己的方案：
- 通過(guò)本地文件實(shí)現(xiàn)
- 通過(guò)數(shù)據(jù)庫(kù)實(shí)現(xiàn)
- 通過(guò)本地時(shí)間戳實(shí)現(xiàn)
- 通過(guò)分布式 ZK ID 生成器實(shí)現(xiàn)
- 通過(guò) ZK 遞增方式實(shí)現(xiàn)
這里我們主要來(lái)看方案 4。
配置步驟如下：
- 首先修改主鍵自增方式為 4 ，4 表示使用 zookeeper 實(shí)現(xiàn)主鍵自增。
server.xml
圖片
- 配置表自增，并且設(shè)置主鍵
schema.xml
圖片
設(shè)置主鍵自增，并且設(shè)置主鍵為 id 。
- 配置 zookeeper 的信息
在 myid.properties 中配置 zookeeper 信息：
圖片
- 配置要自增的表
sequence_conf.properties
圖片
注意，這里表名字要大寫。
- TABLE.MINID 某線程當(dāng)前區(qū)間內(nèi)最小值
- TABLE.MAXID 某線程當(dāng)前區(qū)間內(nèi)最大值
- TABLE.CURID 某線程當(dāng)前區(qū)間內(nèi)當(dāng)前值
- 文件配置的MAXID以及MINID決定每次取得區(qū)間，這個(gè)對(duì)于每個(gè)線程或者進(jìn)程都有效
- 文件中的這三個(gè)屬性配置只對(duì)第一個(gè)進(jìn)程的第一個(gè)線程有效，其他線程和進(jìn)程會(huì)動(dòng)態(tài)讀取 ZK
- 重啟 MyCat 測(cè)試
最后重啟 MyCat ，刪掉之前創(chuàng)建的表，然后創(chuàng)建新表進(jìn)行測(cè)試即可。
這種方式就比較省事一些，而且可擴(kuò)展性也比較強(qiáng)，如果選擇了 MyCat 作為分庫(kù)分表工具，那么這種不失為一種最佳方案。
前面介紹這兩種都是在數(shù)據(jù)庫(kù)或者數(shù)據(jù)庫(kù)中間件層面來(lái)處理主鍵自增，我們 Java 代碼并不需要額外工作。
接下來(lái)我們?cè)賮?lái)看幾種需要在 Java 代碼中進(jìn)行處理的方案。
三 Java 代碼處理
3.1 UUID
最容易想到的就是 UUID (Universally Unique Identifier) 了， UUID 的標(biāo)準(zhǔn)型式包含 32 個(gè) 16 進(jìn)制數(shù)字，以連字號(hào)分為五段，形式為 8-4-4-4-12 的 36 個(gè)字符，這個(gè)是 Java 自帶的，用著也簡(jiǎn)單，最大的優(yōu)勢(shì)就是本地生成，沒有網(wǎng)絡(luò)消耗，但是但凡在公司做開發(fā)的小伙伴都知道這個(gè)東西在公司項(xiàng)目中使用并不多。原因如下：
- 字符串太長(zhǎng)，對(duì)于 MySQL 而言，不利于索引。
- UUID 的隨機(jī)性對(duì)于 I/O 密集型的應(yīng)用非常不友好！它會(huì)使得聚簇索引的插入變得完全隨機(jī)，使得數(shù)據(jù)沒有任何聚集特性。
- 信息不安全：基于 MAC 地址生成 UUID 的算法可能會(huì)造成 MAC 地址泄露，這個(gè)漏洞曾被用于尋找梅麗莎病毒的制作者位置。
因此，UUID 并非最佳方案。
3.2 SNOWFLAKE
雪花算法是由 Twitter 公布的分布式主鍵生成算法，它能夠保證不同進(jìn)程主鍵的不重復(fù)性，以及相同進(jìn)程主鍵的有序性。在同一個(gè)進(jìn)程中，它首先是通過(guò)時(shí)間位保證不重復(fù)，如果時(shí)間相同則是通過(guò)序列位保證。
同時(shí)由于時(shí)間位是單調(diào)遞增的，且各個(gè)服務(wù)器如果大體做了時(shí)間同步，那么生成的主鍵在分布式環(huán)境可以認(rèn)為是總體有序的，這就保證了對(duì)索引字段的插入的高效性。
例如 MySQL 的 Innodb 存儲(chǔ)引擎的主鍵。使用雪花算法生成的主鍵，二進(jìn)制表示形式包含 4 部分，從高位到低位分表為：1bit 符號(hào)位、41bit 時(shí)間戳位、10bit 工作進(jìn)程位以及 12bit 序列號(hào)位。
圖片
- 符號(hào)位 (1bit)
預(yù)留的符號(hào)位，恒為零。
- 時(shí)間戳位 (41bit)
41 位的時(shí)間戳可以容納的毫秒數(shù)是 2 的 41 次冪，一年所使用的毫秒數(shù)是：365 * 24 * 60 * 60 * 1000。通過(guò)計(jì)算可知：Math.pow(2, 41) / (365 * 24 * 60 * 60 * 1000L);結(jié)果約等于 69.73 年。
ShardingSphere 的雪花算法的時(shí)間紀(jì)元從 2016 年 11 月 1 日零點(diǎn)開始，可以使用到 2086 年，相信能滿足絕大部分系統(tǒng)的要求。
- 工作進(jìn)程位 (10bit)
該標(biāo)志在 Java 進(jìn)程內(nèi)是唯一的，如果是分布式應(yīng)用部署應(yīng)保證每個(gè)工作進(jìn)程的 id 是不同的。該值默認(rèn)為 0，可通過(guò)屬性設(shè)置。
- 序列號(hào)位 (12bit)
該序列是用來(lái)在同一個(gè)毫秒內(nèi)生成不同的 ID。如果在這個(gè)毫秒內(nèi)生成的數(shù)量超過(guò) 4096 (2 的 12 次冪)，那么生成器會(huì)等待到下個(gè)毫秒繼續(xù)生成。
注意： 該算法存在 時(shí)鐘回?fù)?問(wèn)題，服務(wù)器時(shí)鐘回?fù)軙?huì)導(dǎo)致產(chǎn)生重復(fù)序列，因此默認(rèn)分布式主鍵生成器提供了一個(gè)最大容忍的時(shí)鐘回?fù)芎撩霐?shù)。 如果時(shí)鐘回?fù)艿臅r(shí)間超過(guò)最大容忍的毫秒數(shù)閾值，則程序報(bào)錯(cuò)；如果在可容忍的范圍內(nèi)，默認(rèn)分布式主鍵生成器會(huì)等待時(shí)鐘同步到最后一次主鍵生成的時(shí)間后再繼續(xù)工作。 最大容忍的時(shí)鐘回?fù)芎撩霐?shù)的默認(rèn)值為 0，可通過(guò)屬性設(shè)置。
下面松哥給出一個(gè)雪花算法的工具類，大家可以參考：
public class IdWorker {
// 時(shí)間起始標(biāo)記點(diǎn)，作為基準(zhǔn)，一般取系統(tǒng)的最近時(shí)間（一旦確定不能變動(dòng)）
private final static long twepoch = 1288834974657L;
// 機(jī)器標(biāo)識(shí)位數(shù)
private final static long workerIdBits = 5L;
// 數(shù)據(jù)中心標(biāo)識(shí)位數(shù)
private final static long datacenterIdBits = 5L;
// 機(jī)器ID最大值
private final static long maxWorkerId = -1L ^ (-1L << workerIdBits);
// 數(shù)據(jù)中心ID最大值
private final static long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
// 毫秒內(nèi)自增位
private final static long sequenceBits = 12L;
// 機(jī)器ID偏左移12位
private final static long workerIdShift = sequenceBits;
// 數(shù)據(jù)中心ID左移17位
private final static long datacenterIdShift = sequenceBits + workerIdBits;
// 時(shí)間毫秒左移22位
private final static long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
private final static long sequenceMask = -1L ^ (-1L << sequenceBits);
/* 上次生產(chǎn)id時(shí)間戳 */
private static long lastTimestamp = -1L;
// 0，并發(fā)控制
private long sequence = 0L;
private final long workerId;
// 數(shù)據(jù)標(biāo)識(shí)id部分
private final long datacenterId;
public IdWorker(){
this.datacenterId = getDatacenterId(maxDatacenterId);
this.workerId = getMaxWorkerId(datacenterId, maxWorkerId);
}
/**
* @param workerId
* 工作機(jī)器ID
* @param datacenterId
* 序列號(hào)
*/
public IdWorker(long workerId, long datacenterId) {
if (workerId > maxWorkerId || workerId < 0) {
throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));
}
if (datacenterId > maxDatacenterId || datacenterId < 0) {
throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));
}
this.workerId = workerId;
this.datacenterId = datacenterId;
}
/**
* 獲取下一個(gè)ID
*
* @return
*/
public synchronized long nextId() {
long timestamp = timeGen();
if (timestamp < lastTimestamp) {
throw new RuntimeException(String.format("Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
}
if (lastTimestamp == timestamp) {
// 當(dāng)前毫秒內(nèi)，則+1
sequence = (sequence + 1) & sequenceMask;
if (sequence == 0) {
// 當(dāng)前毫秒內(nèi)計(jì)數(shù)滿了，則等待下一秒
timestamp = tilNextMillis(lastTimestamp);
}
} else {
sequence = 0L;
}
lastTimestamp = timestamp;
// ID偏移組合生成最終的ID，并返回ID
long nextId = ((timestamp - twepoch) << timestampLeftShift)
| (datacenterId << datacenterIdShift)
| (workerId << workerIdShift) | sequence;
return nextId;
}
private long tilNextMillis(final long lastTimestamp) {
long timestamp = this.timeGen();
while (timestamp <= lastTimestamp) {
timestamp = this.timeGen();
}
return timestamp;
}
private long timeGen() {
return System.currentTimeMillis();
}
/**
* <p>
* 獲取 maxWorkerId
* </p>
*/
protected static long getMaxWorkerId(long datacenterId, long maxWorkerId) {
StringBuffer mpid = new StringBuffer();
mpid.append(datacenterId);
String name = ManagementFactory.getRuntimeMXBean().getName();
if (!name.isEmpty()) {
/*
* GET jvmPid
*/
mpid.append(name.split("@")[0]);
}
/*
* MAC + PID 的 hashcode 獲取16個(gè)低位
*/
return (mpid.toString().hashCode() & 0xffff) % (maxWorkerId + 1);
}
/**
* <p>
* 數(shù)據(jù)標(biāo)識(shí)id部分
* </p>
*/
protected static long getDatacenterId(long maxDatacenterId) {
long id = 0L;
try {
InetAddress ip = InetAddress.getLocalHost();
NetworkInterface network = NetworkInterface.getByInetAddress(ip);
if (network == null) {
id = 1L;
} else {
byte[] mac = network.getHardwareAddress();
id = ((0x000000FF & (long) mac[mac.length - 1])
| (0x0000FF00 & (((long) mac[mac.length - 2]) << 8))) >> 6;
id = id % (maxDatacenterId + 1);
}
} catch (Exception e) {
System.out.println(" getDatacenterId: " + e.getMessage());
}
return id;
}
}用法如下：
IdWorker idWorker = new IdWorker(0, 0);
for (int i = 0; i < 1000; i++) {
System.out.println(idWorker.nextId());
}3.3 LEAF
Leaf 是美團(tuán)開源的分布式 ID 生成系統(tǒng)，最早期需求是各個(gè)業(yè)務(wù)線的訂單 ID 生成需求。在美團(tuán)早期，有的業(yè)務(wù)直接通過(guò) DB 自增的方式生成 ID，有的業(yè)務(wù)通過(guò) Redis 緩存來(lái)生成 ID，也有的業(yè)務(wù)直接用 UUID 這種方式來(lái)生成 ID。以上的方式各自有各自的問(wèn)題，因此美團(tuán)決定實(shí)現(xiàn)一套分布式 ID 生成服務(wù)來(lái)滿足需求目前 Leaf 覆蓋了美團(tuán)點(diǎn)評(píng)公司內(nèi)部金融、餐飲、外賣、酒店旅游、貓眼電影等眾多業(yè)務(wù)線。在4C8G VM 基礎(chǔ)上，通過(guò)公司 RPC 方式調(diào)用，QPS 壓測(cè)結(jié)果近 5w/s，TP999 1ms（TP=Top Percentile，Top 百分?jǐn)?shù)，是一個(gè)統(tǒng)計(jì)學(xué)里的術(shù)語(yǔ)，與平均數(shù)、中位數(shù)都是一類。TP50、TP90 和 TP99 等指標(biāo)常用于系統(tǒng)性能監(jiān)控場(chǎng)景，指高于 50%、90%、99% 等百分線的情況）。
目前 LEAF 的使用有兩種不同的思路，號(hào)段模式和 SNOWFLAKE 模式，你可以同時(shí)開啟兩種方式，也可以指定開啟某種方式（默認(rèn)兩種方式為關(guān)閉狀態(tài)）。
我們從 GitHub 上 Clone LEAF 之后，它的配置文件在 leaf-server/src/main/resources/leaf.properties 中，各項(xiàng)配置的含義如下：
圖片
。
可以看到，如果使用號(hào)段模式，需要數(shù)據(jù)庫(kù)支持；如果使用 SNOWFLAKE 模式，需要 Zookeeper 支持。
3.3.1 號(hào)段模式
號(hào)段模式還是基于數(shù)據(jù)庫(kù)，但是思路有些變化，如下：
- 利用 proxy server 從數(shù)據(jù)庫(kù)中批量獲取 id，每次獲取一個(gè) segment (step 決定其大小) 號(hào)段的值，用完之后再去數(shù)據(jù)庫(kù)獲取新的號(hào)段，可以大大的減輕數(shù)據(jù)庫(kù)的壓力。
- 各個(gè)業(yè)務(wù)不同的發(fā)號(hào)需求用 biz_tag 字段來(lái)區(qū)分，每個(gè) biz-tag 的 ID 獲取相互隔離，互不影響。
- 如果有新的業(yè)務(wù)需要擴(kuò)區(qū) ID，只需要增加表記錄即可。
如果使用號(hào)段模式，我們首先需要?jiǎng)?chuàng)建一張數(shù)據(jù)表，腳本如下：
CREATE DATABASE leaf
CREATE TABLE `leaf_alloc` (
`biz_tag` varchar(128) NOT NULL DEFAULT '',
`max_id` bigint(20) NOT NULL DEFAULT '1',
`step` int(11) NOT NULL,
`description` varchar(256) DEFAULT NULL,
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`biz_tag`)
) ENGINE=InnoDB;
insert into leaf_alloc(biz_tag, max_id, step, description) values('leaf-segment-test', 1, 2000, 'Test leaf Segment Mode Get Id')這張表中各項(xiàng)字段的含義如下：
- biz_tag：業(yè)務(wù)標(biāo)記（不同業(yè)務(wù)可以有不同的號(hào)段序列）
- max_id：當(dāng)前號(hào)段下的最大 id
- step：每次取號(hào)段的步長(zhǎng)
- description：描述信息
- update_time：更新時(shí)間
配置完成后，啟動(dòng)項(xiàng)目，訪問(wèn) http://localhost:8080/api/segment/get/leaf-segment-test 路徑（路徑最后面的 leaf-segment-test 是業(yè)務(wù)標(biāo)記），即可拿到 ID。
可以通過(guò)如下地址訪問(wèn)到號(hào)段模式的監(jiān)控頁(yè)面 http://localhost:8080/cache。
號(hào)段模式優(yōu)缺點(diǎn)：
優(yōu)點(diǎn)
- Leaf 服務(wù)可以很方便的線性擴(kuò)展，性能完全能夠支撐大多數(shù)業(yè)務(wù)場(chǎng)景。
- ID 號(hào)碼是趨勢(shì)遞增的 8byte 的 64 位數(shù)字，滿足上述數(shù)據(jù)庫(kù)存儲(chǔ)的主鍵要求。
- 容災(zāi)性高：Leaf 服務(wù)內(nèi)部有號(hào)段緩存，即使 DB 宕機(jī)，短時(shí)間內(nèi) Leaf 仍能正常對(duì)外提供服務(wù)。
- 可以自定義 max_id 的大小，非常方便業(yè)務(wù)從原有的 ID 方式上遷移過(guò)來(lái)。
缺點(diǎn)
- ID 號(hào)碼不夠隨機(jī)，能夠泄露發(fā)號(hào)數(shù)量的信息，不太安全。
- DB 宕機(jī)會(huì)造成整個(gè)系統(tǒng)不可用。
3.3.2 SNOWFLAKE 模式
SNOWFLAKE 模式需要配合 Zookeeper 一起，不過(guò) SNOWFLAKE 對(duì) Zookeeper 的依賴是弱依賴，把 Zookeeper 啟動(dòng)之后，我們可以在 SNOWFLAKE 中配置 Zookeeper 信息，如下：
leaf.snowflake.enable=true
leaf.snowflake.zk.address=192.168.91.130
leaf.snowflake.port=2183然后重新啟動(dòng)項(xiàng)目，啟動(dòng)成功后，通過(guò)如下地址可以訪問(wèn)到 ID：
http://localhost:8080/api/snowflake/get/test3.4 Redis 生成
這個(gè)主要是利用 Redis 的 incrby 來(lái)實(shí)現(xiàn)，這個(gè)我覺得沒啥好說(shuō)的。大伙應(yīng)該比較熟悉。
3.5 Zookeeper 處理
使用 ZooKeeper 生成唯一 ID 的基本步驟:
- 所有客戶端都會(huì)根據(jù)自己的任務(wù)類型，在指定類型的任務(wù)下面通過(guò)調(diào)用 create() 接口來(lái)創(chuàng)建一個(gè)順序節(jié)點(diǎn)，例如創(chuàng)建“job-”節(jié)點(diǎn)。
- 節(jié)點(diǎn)創(chuàng)建完畢后，create() 接口會(huì)返回一個(gè)完整的節(jié)點(diǎn)名，例如 “job-0000000003”。
- 客戶端拿到這個(gè)返回值后，拼接上 type 類型，例如“type2-job-0000000003”，這就可以作為一個(gè)全局唯一的 ID 了。
對(duì)于熟悉 zk 的小伙伴來(lái)說(shuō)，這也是基操了。
使用 zk 的優(yōu)勢(shì)在于強(qiáng)一致性和高并發(fā)能力。
