在復雜的分布式系統(tǒng)中，往往需要對大量的數據進行唯一標識，比如在對一個訂單表進行了分庫分表操作，這時候數據庫的自增ID顯然不能作為某個訂單的唯一標識。除此之外還有其他分布式場景對分布式ID的一些要求：
趨勢遞增：?由于多數RDBMS使用B-tree的數據結構來存儲索引數據，在主鍵的選擇上面我們應該盡量使用有序的主鍵保證寫入性能。
單調遞增：?保證下一個ID一定大于上一個ID，例如排序需求。
信息安全：?如果ID是連續(xù)的，惡意用戶的扒取工作就非常容易做了；如果是訂單號就更危險了，可以直接知道我們的單量。所以在一些應用場景下，會需要ID無規(guī)則、不規(guī)則。
就不同的場景及要求，市面誕生了很多分布式ID解決方案。本文針對多個分布式ID解決方案進行介紹，包括其優(yōu)缺點、使用場景及代碼示例。
一、UUID?
UUID(Universally Unique Identifier)是基于當前時間、計數器（counter）和硬件標識（通常為無線網卡的MAC地址）等數據計算生成的。包含32個16進制數字，以連字號分為五段，形式為8-4-4-4-12的36個字符，可以生成全球唯一的編碼并且性能高效。
JDK提供了UUID生成工具，代碼如下：
import java.util.UUID;
public class Test {
public static void main(String[] args) {
System.out.println(UUID.randomUUID());
// 輸出：b0378f6a-eeb7-4779-bffe-2a9f3bc76380
}
}UUID完全可以滿足分布式唯一標識，但是在實際應用過程中一般不采用，有如下幾個原因：
-
存儲成本高：?UUID太長，16字節(jié)128位，通常以36長度的字符串表示，很多場景不適用。
-
信息不安全：?基于MAC地址生成的UUID算法會暴露MAC地址，曾經梅麗莎病毒的制造者就是根據UUID尋找的。
-
不符合MySQL主鍵要求：?MySQL官方有明確的建議主鍵要盡量越短越好，因為太長對MySQL索引不利：如果作為數據庫主鍵，在InnoDB引擎下，UUID的無序性可能會引起數據位置頻繁變動，嚴重影響性能。
二、數據庫自增ID
利用Mysql的特性ID自增，可以達到數據唯一標識，但是分庫分表后只能保證一個表中的ID的唯一，而不能保證整體的ID唯一。為了避免這種情況，我們有以下兩種方式解決該問題。
2.1 主鍵表
通過單獨創(chuàng)建主鍵表維護唯一標識，作為ID的輸出源可以保證整體ID的唯一。舉個例子：
創(chuàng)建一個主鍵表
CREATE TABLE `unique_id` (
`id` bigint NOT NULL AUTO_INCREMENT,
`biz` char(1) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `biz` (`biz`)
) ENGINE = InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET =utf8;業(yè)務通過更新操作來獲取ID信息，然后添加到某個分表中。
BEGIN;
REPLACE INTO unique_id (biz) values ('o') ;
SELECT LAST_INSERT_ID();
COMMIT;
?2.2 ID自增步長設置
我們可以設置Mysql主鍵自增步長，讓分布在不同實例的表數據ID做到不重復，保證整體的唯一。
如下，可以設置Mysql實例1步長為1，實例1步長為2。
查看主鍵自增的屬性
show variables like '%increment%'
?
?顯然，這種方式在并發(fā)量比較高的情況下，如何保證擴展性其實會是一個問題。
三、號段模式
號段模式是當下分布式ID生成器的主流實現方式之一。其原理如下：
-
號段模式每次從數據庫取出一個號段范圍，加載到服務內存中。業(yè)務獲取時ID直接在這個范圍遞增取值即可。
-
等這批號段ID用完，再次向數據庫申請新號段，對max_id字段做一次update操作，新的號段范圍是(
max_id?,max_id +step]。 -
由于多業(yè)務端可能同時操作，所以采用版本號version樂觀鎖方式更新。
?例如 (1,1000] 代表1000個ID，具體的業(yè)務服務將本號段生成1~1000的自增ID。表結構如下：
CREATE TABLE id_generator (
id int(10) NOT NULL,
max_id bigint(20) NOT NULL COMMENT '當前最大id',
step int(20) NOT NULL COMMENT '號段的長度',
biz_type int(20) NOT NULL COMMENT '業(yè)務類型',
version int(20) NOT NULL COMMENT '版本號,是一個樂觀鎖，每次都更新version，保證并發(fā)時數據的正確性',
PRIMARY KEY (`id`)
) 這種分布式ID生成方式不強依賴于數據庫，不會頻繁的訪問數據庫，對數據庫的壓力小很多。但同樣也會存在一些缺點比如：服務器重啟，單點故障會造成ID不連續(xù)。
四、Redis INCR
基于全局唯一ID的特性，我們可以通過Redis的INCR命令來生成全局唯一ID。
?Redis分布式ID的簡單案例：
/**
* Redis 分布式ID生成器
*/
@Component
public class RedisDistributedId {
@Autowired
private StringRedisTemplate redisTemplate;
private static final long BEGIN_TIMESTAMP = 1659312000l;
/**
* 生成分布式ID
* 符號位 時間戳[31位] 自增序號【32位】
* @param item
* @return
*/
public long nextId(String item){
// 1.生成時間戳
LocalDateTime now = LocalDateTime.now();
// 格林威治時間差
long nowSecond = now.toEpochSecond(ZoneOffset.UTC);
// 我們需要獲取的 時間戳 信息
long timestamp = nowSecond - BEGIN_TIMESTAMP;
// 2.生成序號 --》 從Redis中獲取
// 當前當前的日期
String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
// 獲取對應的自增的序號
Long increment = redisTemplate.opsForValue().increment("id:" + item + ":" + date);
return timestamp << 32 | increment;
}
}同樣使用Redis也有對應的缺點：ID 生成的持久化問題，如果Redis宕機了怎么進行恢復?
五、雪花算法
Snowflake，雪花算法是有Twitter開源的分布式ID生成算法，以劃分命名空間的方式將64bit位分割成了多個部分，每個部分都有具體的不同含義，在Java中64Bit位的整數是Long類型，所以在Java中Snowflake算法生成的ID就是long來存儲的。具體如下：
-
第一部分：?占用1bit，第一位為符號位，不適用
-
第二部分：?41位的時間戳，41bit位可以表示241個數，每個數代表的是毫秒，那么雪花算法的時間年限是
(241)/(1000×60×60×24×365)=69年 -
第三部分：?10bit表示是機器數，即?
2^ 10 = 1024臺機器，通常不會部署這么多機器 -
第四部分：?12bit位是自增序列，可以表示
2^12=4096個數，一秒內可以生成4096個ID，理論上snowflake方案的QPS約為409.6w/s
雪花算法案例代碼：
public class SnowflakeIdWorker {
// ==============================Fields===========================================
/**
* 開始時間截 (2020-11-03，一旦確定不可更改，否則時間被回調，或者改變，可能會造成id重復或沖突)
*/
private final long twepoch = 1604374294980L;
/**
* 機器id所占的位數
*/
private final long workerIdBits = 5L;
/**
* 數據標識id所占的位數
*/
private final long datacenterIdBits = 5L;
/**
* 支持的最大機器id，結果是31 (這個移位算法可以很快的計算出幾位二進制數所能表示的最大十進制數)
*/
private final long maxWorkerId = -1L ^ (-1L << workerIdBits);
/**
* 支持的最大數據標識id，結果是31
*/
private final long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
/**
* 序列在id中占的位數
*/
private final long sequenceBits = 12L;
/**
* 機器ID向左移12位
*/
private final long workerIdShift = sequenceBits;
/**
* 數據標識id向左移17位(12+5)
*/
private final long datacenterIdShift = sequenceBits + workerIdBits;
/**
* 時間截向左移22位(5+5+12)
*/
private final long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
/**
* 生成序列的掩碼，這里為4095 (0b111111111111=0xfff=4095)
*/
private final long sequenceMask = -1L ^ (-1L << sequenceBits);
/**
* 工作機器ID(0~31)
*/
private long workerId;
/**
* 數據中心ID(0~31)
*/
private long datacenterId;
/**
* 毫秒內序列(0~4095)
*/
private long sequence = 0L;
/**
* 上次生成ID的時間截
*/
private long lastTimestamp = -1L;
//==============================Constructors=====================================
/**
* 構造函數
*
*/
public SnowflakeIdWorker() {
this.workerId = 0L;
this.datacenterId = 0L;
}
/**
* 構造函數
*
* @param workerId 工作ID (0~31)
* @param datacenterId 數據中心ID (0~31)
*/
public SnowflakeIdWorker(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;
}
// ==============================Methods==========================================
/**
* 獲得下一個ID (該方法是線程安全的)
*
* @return SnowflakeId
*/
public synchronized long nextId() {
long timestamp = timeGen();
//如果當前時間小于上一次ID生成的時間戳，說明系統(tǒng)時鐘回退過這個時候應當拋出異常
if (timestamp < lastTimestamp) {
throw new RuntimeException(
String.format("Clock moved backwards. Refusing to generate id for %d milliseconds", lastTimestamp - timestamp));
}
//如果是同一時間生成的，則進行毫秒內序列
if (lastTimestamp == timestamp) {
sequence = (sequence + 1) & sequenceMask;
//毫秒內序列溢出
if (sequence == 0) {
//阻塞到下一個毫秒,獲得新的時間戳
timestamp = tilNextMillis(lastTimestamp);
}
}
//時間戳改變，毫秒內序列重置
else {
sequence = 0L;
}
//上次生成ID的時間截
lastTimestamp = timestamp;
//移位并通過或運算拼到一起組成64位的ID
return ((timestamp - twepoch) << timestampLeftShift) //
| (datacenterId << datacenterIdShift) //
| (workerId << workerIdShift) //
| sequence;
}
/**
* 阻塞到下一個毫秒，直到獲得新的時間戳
*
* @param lastTimestamp 上次生成ID的時間截
* @return 當前時間戳
*/
protected long tilNextMillis(long lastTimestamp) {
long timestamp = timeGen();
while (timestamp <= lastTimestamp) {
timestamp = timeGen();
}
return timestamp;
}
/**
* 返回以毫秒為單位的當前時間
*
* @return 當前時間(毫秒)
*/
protected long timeGen() {
return System.currentTimeMillis();
}
/**
* 隨機id生成，使用雪花算法
*
* @return
*/
public static String getSnowId() {
SnowflakeIdWorker sf = new SnowflakeIdWorker();
String id = String.valueOf(sf.nextId());
return id;
}
//=========================================Test=========================================
/**
* 測試
*/
public static void main(String[] args) {
SnowflakeIdWorker idWorker = new SnowflakeIdWorker(0, 0);
for (int i = 0; i < 1000; i++) {
long id = idWorker.nextId();
System.out.println(id);
}
}
}雪花算法強依賴機器時鐘，如果機器上時鐘回撥，會導致發(fā)號重復。通常通過記錄最后使用時間處理該問題。
六、美團-Leaf
開源項目鏈接：https://github.com/Meituan-Dianping/Leaf
Leaf同時支持號段模式和snowflake算法模式，可以切換使用。
snowflake模式依賴于ZooKeeper，不同于原始snowflake算法也主要是在workId的生成上，Leaf中workId是基于ZooKeeper的順序Id來生成的，每個應用在使用Leaf-snowflake時，啟動時都會都在Zookeeper中生成一個順序Id，相當于一臺機器對應一個順序節(jié)點，也就是一個workId。
號段模式是對直接用數據庫自增ID充當分布式ID的一種優(yōu)化，減少對數據庫的頻率操作。相當于從數據庫批量的獲取自增ID，每次從數據庫取出一個號段范圍，例如 (1,1000] 代表1000個ID，業(yè)務服務將號段在本地生成1~1000的自增ID并加載到內存。
七、百度-Uidgenerator
- 開源項目鏈接：https://github.com/baidu/uid-generator
- 中文文檔地址：https://github.com/baidu/uid-generator/blob/master/README.zh_cn.md
?UidGenerator是百度開源的Java語言實現，基于Snowflake算法的唯一ID生成器。它是分布式的，并克服了雪花算法的并發(fā)限制。單個實例的QPS能超過6000000。需要的環(huán)境：JDK8+，MySQL（用于分配WorkerId）。
百度的Uidgenerator對結構做了部分的調整，具體如下：
?時間部分只有28位，這就意味著UidGenerator默認只能承受8.5年（2^28-1/86400/365），不過UidGenerator可以適當調整delta seconds、worker node id和sequence占用位數。
八、滴滴-TinyID
開源項目鏈接：https://github.com/didi/tinyid
Tinyid是在美團（Leaf）的leaf-segment算法基礎上升級而來，不僅支持了數據庫多主節(jié)點模式，還提供了tinyid-client客戶端的接入方式，使用起來更加方便。
但和美團（Leaf）不同的是，Tinyid只支持號段一種模式不支持雪花模式。Tinyid提供了兩種調用方式，一種基于Tinyid-server提供的http方式，另一種Tinyid-client客戶端方式。文章來源：http://www.zghlxwxcb.cn/news/detail-444592.html
九、對比總結
文章來源地址http://www.zghlxwxcb.cn/news/detail-444592.html
到了這里，關于分布式ID解決方案對比的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！
