七種分佈式全局 ID 生成策略，你更愛哪一種？#導入MD文檔圖片#
[TOC]java
上了微服務以後，不少本來很簡單的問題如今都變複雜了，例如全局 ID 這事！算法
鬆哥最近工做中恰好用到這塊內容，因而調研了市面上幾種常見的全局 ID 生成策略，稍微作了一下對比，供小夥伴們參考。sql
當數據庫分庫分表以後，本來的主鍵自增就不方便繼續使用了，須要找到一個新的合適的方案，鬆哥的需求就是在這樣的狀況下提出的。數據庫
接下來咱們一塊兒來捋一捋。api
1. 兩種思路
總體上來講，這個問題有兩種不一樣的思路：緩存
- 讓數據庫本身搞定
- Java 代碼來處理主鍵，而後直接插入數據庫中便可。
這兩種思路又對應了不一樣的方案，咱們一個一個來看。安全
2. 數據庫本身搞定
數據庫本身搞定，就是說我在數據插入的時候，依然不考慮主鍵的問題，但願繼續使用數據庫的主鍵自增，可是很明顯，本來默認的主鍵自增如今無法用了，咱們必須有新的方案。服務器
2.1 修改數據庫配置
數據庫分庫分表以後的結構以下圖（假設數據庫中間件用的 MyCat）：markdown
此時若是本來的 db一、db二、db3 繼續各自主鍵自增，那麼對於 MyCat 而言，主鍵就不是自增了，主鍵就會重複，用戶從 MyCat 中查詢到的數據主鍵就有問題。網絡
找到問題的緣由，那麼剩下的就好解決了。
咱們能夠直接修改 MySQL 數據庫主鍵自增的起始值和步長。
首先咱們能夠經過以下 SQL 查看與此相關的兩個變量的取值：
SHOW VARIABLES LIKE 'auto_increment%'
能夠看到，主鍵自增的起始值和步長都是 1。
起始值好改，在定義表的時候就能夠設置，步長咱們能夠經過修改這個配置實現：
set @@auto_increment_increment=9;
修改後，再去查看對應的變量值，發現已經變了：
此時咱們再去插入數據，主鍵自增就不是每次自增 1，而是每次自增 9 了。
至於自增起始值其實很好設置，建立表的時候就能夠設置了。
create table test01(id integer PRIMARY KEY auto_increment,username varchar(255)) auto_increment=8;
既然 MySQL 能夠修改自增的起始值和每次增加的步長，如今假設我有 db一、db2 和 db3，我就能夠分別設置這三個庫中表的自增起始值爲 一、二、3，而後自增步長都是 3，這樣就能夠實現自增了。
可是很明顯這種方式不夠優雅，並且處理起來很麻煩，未來擴展也不方便，所以不推薦。
2.2 MySQL+MyCat+ZooKeeper
若是你們分庫分表工具剛好使用的是 MyCat，那麼結合 Zookeeper 也能很好的實現主鍵全局自增。
MyCat 做爲一個分佈式數據庫中間，屏蔽了數據庫集羣的操做，讓咱們操做數據庫集羣就像操做單機版數據庫同樣，對於主鍵自增，它有本身的方案：
- 經過本地文件實現
- 經過數據庫實現
- 經過本地時間戳實現
- 經過分佈式 ZK ID 生成器實現
- 經過 ZK 遞增方式實現
這裏咱們主要來看方案 4。
配置步驟以下：
- 首先修改主鍵自增方式爲 4 ，4 表示使用 zookeeper 實現主鍵自增。
server.xml
- 配置表自增，而且設置主鍵
schema.xml
設置主鍵自增，而且設置主鍵爲 id 。
- 配置 zookeeper 的信息
在 myid.properties 中配置 zookeeper 信息：
- 配置要自增的表
sequence_conf.properties
注意，這裏表名字要大寫。
- TABLE.MINID 某線程當前區間內最小值
- TABLE.MAXID 某線程當前區間內最大值
- TABLE.CURID 某線程當前區間內當前值
- 文件配置的MAXID以及MINID決定每次取得區間，這個對於每一個線程或者進程都有效
- 文件中的這三個屬性配置只對第一個進程的第一個線程有效，其餘線程和進程會動態讀取 ZK
- 重啓 MyCat 測試
最後重啓 MyCat ，刪掉以前建立的表，而後建立新表進行測試便可。
這種方式就比較省事一些，並且可擴展性也比較強，若是選擇了 MyCat 做爲分庫分表工具，那麼這種不失爲一種最佳方案。
前面介紹這兩種都是在數據庫或者數據庫中間件層面來處理主鍵自增，咱們 Java 代碼並不須要額外工做。
接下來咱們再來看幾種須要在 Java 代碼中進行處理的方案。
3. Java 代碼處理
3.1 UUID
最容易想到的就是 UUID (Universally Unique Identifier) 了，
UUID 的標準型式包含 32 個 16 進制數字，以連字號分爲五段，形式爲 8-4-4-4-12 的 36 個字符，這個是 Java 自帶的，用着也簡單，最大的優點就是本地生成，沒有網絡消耗，可是但凡在公司作開發的小夥伴都知道這個東西在公司項目中使用並很少。緣由以下：
- 字符串太長，對於 MySQL 而言，不利於索引。
- UUID 的隨機性對於 I/O 密集型的應用很是不友好！它會使得聚簇索引的插入變得徹底隨機，使得數據沒有任何彙集特性。
- 信息不安全：基於 MAC 地址生成 UUID 的算法可能會形成 MAC 地址泄露，這個漏洞曾被用於尋找梅麗莎病毒的製做者位置。
所以，UUID 並不是最佳方案。
3.2 SNOWFLAKE
雪花算法是由 Twitter 公佈的分佈式主鍵生成算法，它可以保證不一樣進程主鍵的不重複性，以及相同進程主鍵的有序性。在同一個進程中，它首先是經過時間位保證不重複，若是時間相同則是經過序列位保證。
同時因爲時間位是單調遞增的，且各個服務器若是大致作了時間同步，那麼生成的主鍵在分佈式環境能夠認爲是整體有序的，這就保證了對索引字段的插入的高效性。
例如 MySQL 的 Innodb 存儲引擎的主鍵。使用雪花算法生成的主鍵，二進制表示形式包含 4 部分，從高位到低位分表爲：1bit 符號位、41bit 時間戳位、10bit 工做進程位以及 12bit 序列號位。
- 符號位 (1bit)
預留的符號位，恆爲零。
- 時間戳位 (41bit)
41 位的時間戳能夠容納的毫秒數是 2 的 41 次冪，一年所使用的毫秒數是：365 24 60 60 1000。經過計算可知：Math.pow(2, 41) / (365 * 24 * 60 * 60 * 1000L);結果約等於 69.73 年。
ShardingSphere 的雪花算法的時間紀元從 2016 年 11 月 1 日零點開始，可使用到 2086 年，相信能知足絕大部分系統的要求。
- 工做進程位 (10bit)
該標誌在 Java 進程內是惟一的，若是是分佈式應用部署應保證每一個工做進程的 id 是不一樣的。該值默認爲 0，可經過屬性設置。
- 序列號位 (12bit)
該序列是用來在同一個毫秒內生成不一樣的 ID。若是在這個毫秒內生成的數量超過 4096 (2 的 12 次冪)，那麼生成器會等待到下個毫秒繼續生成。
注意： 該算法存在 時鐘回撥 問題，服務器時鐘回撥會致使產生重複序列，所以默認分佈式主鍵生成器提供了一個最大容忍的時鐘回撥毫秒數。 若是時鐘回撥的時間超過最大容忍的毫秒數閾值，則程序報錯；若是在可容忍的範圍內，默認分佈式主鍵生成器會等待時鐘同步到最後一次主鍵生成的時間後再繼續工做。 最大容忍的時鐘回撥毫秒數的默認值爲 0，可經過屬性設置。
下面鬆哥給出一個雪花算法的工具類，你們能夠參考：
public class IdWorker {
// 時間起始標記點，做爲基準，通常取系統的最近時間（一旦肯定不能變更）
private final static long twepoch = 1288834974657L;
// 機器標識位數
private final static long workerIdBits = 5L;
// 數據中心標識位數
private final static long datacenterIdBits = 5L;
// 機器ID最大值
private final static long maxWorkerId = -1L ^ (-1L << workerIdBits);
// 數據中心ID最大值
private final static long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
// 毫秒內自增位
private final static long sequenceBits = 12L;
// 機器ID偏左移12位
private final static long workerIdShift = sequenceBits;
// 數據中心ID左移17位
private final static long datacenterIdShift = sequenceBits + workerIdBits;
// 時間毫秒左移22位
private final static long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
private final static long sequenceMask = -1L ^ (-1L << sequenceBits);
/* 上次生產id時間戳 */
private static long lastTimestamp = -1L;
// 0，併發控制
private long sequence = 0L;
private final long workerId;
// 數據標識id部分
private final long datacenterId;
public IdWorker(){
this.datacenterId = getDatacenterId(maxDatacenterId);
this.workerId = getMaxWorkerId(datacenterId, maxWorkerId);
}
/**
* @param workerId
* 工做機器ID
* @param datacenterId
* 序列號
*/
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;
}
/**
* 獲取下一個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) {
// 當前毫秒內，則+1
sequence = (sequence + 1) & sequenceMask;
if (sequence == 0) {
// 當前毫秒內計數滿了，則等待下一秒
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個低位
*/
return (mpid.toString().hashCode() & 0xffff) % (maxWorkerId + 1);
}
/**
* <p>
* 數據標識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 是美團開源的分佈式 ID 生成系統，最先期需求是各個業務線的訂單 ID 生成需求。在美團早期，有的業務直接經過 DB 自增的方式生成 ID，有的業務經過 Redis 緩存來生成 ID，也有的業務直接用 UUID 這種方式來生成 ID。以上的方式各自有各自的問題，所以美團決定實現一套分佈式 ID 生成服務來知足需求目前 Leaf 覆蓋了美團點評公司內部金融、餐飲、外賣、酒店旅遊、貓眼電影等衆多業務線。在4C8G VM 基礎上，經過公司 RPC 方式調用，QPS 壓測結果近 5w/s，TP999 1ms（TP=Top Percentile，Top 百分數，是一個統計學裏的術語，與平均數、中位數都是一類。TP50、TP90 和 TP99 等指標經常使用於系統性能監控場景，指高於 50%、90%、99% 等百分線的狀況）。
目前 LEAF 的使用有兩種不一樣的思路，號段模式和 SNOWFLAKE 模式，你能夠同時開啓兩種方式，也能夠指定開啓某種方式（默認兩種方式爲關閉狀態）。
咱們從 GitHub 上 Clone LEAF 以後，它的配置文件在 leaf-server/src/main/resources/leaf.properties 中，各項配置的含義以下：
。
能夠看到，若是使用號段模式，須要數據庫支持；若是使用 SNOWFLAKE 模式，須要 Zookeeper 支持。
3.3.1 號段模式
號段模式仍是基於數據庫，可是思路有些變化，以下：
- 利用 proxy server 從數據庫中批量獲取 id，每次獲取一個 segment (step 決定其大小) 號段的值，用完以後再去數據庫獲取新的號段，能夠大大的減輕數據庫的壓力。
- 各個業務不一樣的發號需求用 biz_tag 字段來區分，每一個 biz-tag 的 ID 獲取相互隔離，互不影響。
- 若是有新的業務須要擴區 ID，只須要增長表記錄便可。
若是使用號段模式，咱們首先須要建立一張數據表，腳本以下：
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')
這張表中各項字段的含義以下：
- biz_tag：業務標記（不一樣業務能夠有不一樣的號段序列）
- max_id：當前號段下的最大 id
- step：每次取號段的步長
- description：描述信息
- update_time：更新時間
配置完成後，啓動項目，訪問 http://localhost:8080/api/segment/get/leaf-segment-test 路徑（路徑最後面的 leaf-segment-test 是業務標記），便可拿到 ID。
能夠經過以下地址訪問到號段模式的監控頁面 http://localhost:8080/cache。
號段模式優缺點：
優勢
- Leaf 服務能夠很方便的線性擴展，性能徹底可以支撐大多數業務場景。
- ID 號碼是趨勢遞增的 8byte 的 64 位數字，知足上述數據庫存儲的主鍵要求。
- 容災性高：Leaf 服務內部有號段緩存，即便 DB 宕機，短期內 Leaf 仍能正常對外提供服務。
- 能夠自定義 max_id 的大小，很是方便業務從原有的 ID 方式上遷移過來。
缺點
- ID 號碼不夠隨機，可以泄露發號數量的信息，不太安全。
- DB 宕機會形成整個系統不可用。
3.3.2 SNOWFLAKE 模式
SNOWFLAKE 模式須要配合 Zookeeper 一塊兒，不過 SNOWFLAKE 對 Zookeeper 的依賴是弱依賴，把 Zookeeper 啓動以後，咱們能夠在 SNOWFLAKE 中配置 Zookeeper 信息，以下：
leaf.snowflake.enable=true leaf.snowflake.zk.address=192.168.91.130 leaf.snowflake.port=2183
而後從新啓動項目，啓動成功後，經過以下地址能夠訪問到 ID：
http://localhost:8080/api/snowflake/get/test
3.4 Redis 生成
這個主要是利用 Redis 的 incrby 來實現，這個我以爲沒啥好說的。
3.5 Zookeeper 處理
zookeeper 也能作，可是比較麻煩，不推薦。
4. 小結
綜上，若是項目中剛好使用了 MyCat，那麼可使用 MyCat+Zookeeper，不然建議使用 LEAF，兩種模式皆可。
- 1. 七種分佈式全局 ID 生成策略，你更愛哪一種？
- 2. 七種企業級分佈式全局惟一ID生成策略
- 3. 【分佈式】分佈式全局唯一ID生成策略
- 4. 分佈式全局惟一ID生成策略
- 5. 分佈式系統全局惟一id生成策略
- 6. 分佈式惟一id生成策略
- 7. 分佈式系統全局id生成策略
- 8. 一種短ID生成策略
- 9. 一種分佈式id生成規則
- 10. 分佈式ID生成策略
- 更多相關文章...
- • ASP.NET MVC - 樣式和佈局 - ASP.NET 教程
- • XSL-FO 文檔 - XSL-FO 教程
- • 再有人問你分佈式事務，把這篇扔給他
- • 常用的分佈式事務解決方案
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 七種分佈式全局 ID 生成策略，你更愛哪一種？
- 2. 七種企業級分佈式全局惟一ID生成策略
- 3. 【分佈式】分佈式全局唯一ID生成策略
- 4. 分佈式全局惟一ID生成策略
- 5. 分佈式系統全局惟一id生成策略
- 6. 分佈式惟一id生成策略
- 7. 分佈式系統全局id生成策略
- 8. 一種短ID生成策略
- 9. 一種分佈式id生成規則
- 10. 分佈式ID生成策略