這篇文章主要為大家展示了“分布式業(yè)務(wù)系統(tǒng)中全局ID生成策略的示例分析”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“分布式業(yè)務(wù)系統(tǒng)中全局ID生成策略的示例分析”這篇文章吧。
創(chuàng)新互聯(lián)為您提適合企業(yè)的網(wǎng)站設(shè)計?讓您的網(wǎng)站在搜索引擎具有高度排名，讓您的網(wǎng)站具備超強的網(wǎng)絡(luò)競爭力！結(jié)合企業(yè)自身，進行網(wǎng)站設(shè)計及把握，最后結(jié)合企業(yè)文化和具體宗旨等，才能創(chuàng)作出一份性化解決方案。從網(wǎng)站策劃到成都做網(wǎng)站、成都網(wǎng)站設(shè)計， 我們的網(wǎng)頁設(shè)計師為您提供的解決方案。
在實際的開發(fā)中，幾乎所有的業(yè)務(wù)場景產(chǎn)生的數(shù)據(jù)，都需要一個唯一ID作為核心標識，用來流程化管理。比如常見的：
訂單：order-id,查訂單詳情，物流狀態(tài)等；
支付：pay-id,支付狀態(tài)，基于ID事務(wù)管理；
如何生成唯一標識，在普通場景下，一般的方法就可以解決，例如：
重慶分公司
重慶分公司
import java.util.UUID;
public class UuidUtil {
public static String getUUid() {
UUID uuid = UUID.randomUUID();
return String.valueOf(uuid).replace("-","");
}
}這個方法可以解決絕大部分唯一ID需求的場景業(yè)務(wù)，但是網(wǎng)上各種UUID重復(fù)場景的描述帖，說的好像該API不好用。
絮叨一句：說一個真實使用的業(yè)務(wù)場景，大概是半年近3000萬的數(shù)據(jù)流水，用的就是UUID的API，暫時未捕捉到ID重復(fù)的問題，僅供參考。
Twitter公司開源的分布式ID生成算法策略，生成的ID遵循時間的順序。
1為位標識，始終為0，不可用；
41位時間截，存儲時間截的差值（當前時間截-開始時間截)；
10位的機器標識，10位的長度最多支持部署1024個節(jié)點；
12位序列，毫秒內(nèi)的計數(shù)，12位的計數(shù)順序號支持每個節(jié)點每毫秒產(chǎn)生4096個ID序號；
SnowFlake的優(yōu)點是，整體上按照時間自增排序，并且整個分布式系統(tǒng)內(nèi)不會產(chǎn)生ID碰撞(由數(shù)據(jù)中心ID和機器ID作區(qū)分)，并且效率較高。
工具類中很多可以自定義的，比如起始時間，機器ID配置等。
/**
* 雪花算法ID生成
*/
public class SnowIdWorkerUtil {
// 開始時間截 (2020-01-02)
private final long timeToCut = 1577894400000L;
// 機器ID所占的位數(shù)
private final long workerIdBits = 2L;
// 數(shù)據(jù)標識ID所占的位數(shù)
private final long dataCenterIdBits = 8L;
// 支持的最大機器ID，結(jié)果是31 (這個移位算法可以很快的計算出幾位二進制數(shù)所能表示的最大十進制數(shù))
private final long maxWorkerId = -1L ^ (-1L << workerIdBits);
// 支持的最大數(shù)據(jù)標識ID，結(jié)果是31
private final long maxDataCenterId = -1L ^ (-1L << dataCenterIdBits);
// 序列在ID中占的位數(shù)
private final long sequenceBits = 12L;
// 機器ID向左移12位
private final long workerIdShift = sequenceBits;
// 數(shù)據(jù)標識ID向左移17位(12+5)
private final long dataCenterIdShift = sequenceBits + workerIdBits;
// 時間截向左移22位(5+5+12)
private final long timestampLeftShift = sequenceBits + workerIdBits + dataCenterIdBits;
// 生成序列的掩碼
private final long sequenceMask = -1L ^ (-1L << sequenceBits);
// 工作機器ID(0~31)
private long workerId;
// 數(shù)據(jù)中心ID(0~31)
private long dataCenterId;
// 毫秒內(nèi)序列(0~4095)
private long sequence = 0L;
// 上次生成ID的時間截
private long lastTimestamp = -1L;
/**
* 構(gòu)造函數(shù)
* @param workerId 工作ID (0~31)
* @param dataCenterId 數(shù)據(jù)中心ID (0~31)
*/
public SnowIdWorkerUtil (long workerId, long dataCenterId) {
if (workerId > maxWorkerId || workerId < 0) {
throw new IllegalArgumentException("workerId 不符合條件");
}
if (dataCenterId > maxDataCenterId || dataCenterId < 0) {
throw new IllegalArgumentException("dataCenterId 不符合條件");
}
this.workerId = workerId;
this.dataCenterId = dataCenterId;
}
public synchronized String nextIdVar(){
return String.valueOf(nextId());
}
/**
* 線程安全，獲得下一個ID
*/
private synchronized long nextId() {
long timestamp = timeGen();
// 如果當前時間小于上一次ID生成的時間戳，拋出異常
if (timestamp < lastTimestamp) {
throw new RuntimeException(String.format(
"時間順序異常,時間差(上次時間-現(xiàn)在)=%d",
lastTimestamp - timestamp));
}
// 如果是同一時間生成的，則進行毫秒內(nèi)序列
if (lastTimestamp == timestamp) {
sequence = (sequence + 1) & sequenceMask;
//毫秒內(nèi)序列溢出
if (sequence == 0) {
//阻塞到下一個毫秒,獲得新的時間戳
timestamp = tilNextMillis(lastTimestamp);
}
} else {
// 時間戳改變，毫秒內(nèi)序列重置
sequence = 0L;
}
// 上次生成ID的時間截
lastTimestamp = timestamp;
// 移位并通過或運算拼到一起組成64位的ID
return ((timestamp - timeToCut) << timestampLeftShift)
| (dataCenterId << dataCenterIdShift)
| (workerId << workerIdShift) | sequence;
}
/**
* 阻塞，獲得新的時間戳
*/
private long tilNextMillis(long lastTimestamp) {
long timestamp = timeGen();
while (timestamp <= lastTimestamp) {
timestamp = timeGen();
}
return timestamp;
}
/**
* 返回當前時間節(jié)點
*/
private long timeGen() {
return System.currentTimeMillis();
}
public static void main(String[] args) {
// 參數(shù)在實際業(yè)務(wù)下需要配置管理
SnowIdWorkerUtil idWorker = new SnowIdWorkerUtil(1, 1);
for (int i = 0; i < 100; i++) {
String id = idWorker.nextIdVar();
System.out.println(id+" "+id.length()+"位");
}
}
}還有一種常見的實現(xiàn)思路，基于數(shù)據(jù)庫的自增主鍵ID，不過基于這個原理，卻有各種不同的實現(xiàn)策略。
簡單表結(jié)構(gòu)：
CREATE TABLE `du_temp_id` ( `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵id', `create_time` datetime DEFAULT NULL COMMENT '創(chuàng)建時間', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='主鍵ID臨時表';
這種模式的原理比較單調(diào),向臨時表寫入一條記錄，借助MySQL生成的唯一主鍵ID，然后拿出來稍微處理一下，作為各種業(yè)務(wù)場景的唯一ID使用。
@Service
public class TempIdServiceImpl implements TempIdService {
@Resource
private TempIdMapper tempIdMapper ;
@Override
public List getIdList() {
List idList = new ArrayList<>() ;
TempIdEntity tempIdEntity = new TempIdEntity ();
tempIdEntity.setCreateTime(new Date());
for (int i = 0 ; i < 10 ; i++){
tempIdMapper.insert(tempIdEntity);
idList.add(UuidUtil.getNoId(8,Long.parseLong(tempIdEntity.getId().toString()))) ;
}
return idList ;
}
} 問題點：如果作為ID生成的臨時表所在的MySQL服務(wù)宕掉，那可能會影響整個業(yè)務(wù)流程，造成雪崩效應(yīng)。
單服務(wù)如果不能安穩(wěn)的支撐業(yè)務(wù)需求，很自然集群模式就該上場了。提供多臺MySQL服務(wù)[A,B,C],處理策略也不止一種：
庫設(shè)置主鍵自增策略
例如A庫[1,4,7]，B庫[2,5,8],C庫[3,6,9],基于不同自增規(guī)則，生成統(tǒng)一的自增唯一標識。
生成ID做分庫標識
這種先把ID生成，然后不同的數(shù)據(jù)庫生成的ID給一個不同的標識，例如UIDA，UIDB，UIDC。
@Service
public class TempIdServiceImpl implements TempIdService {
@Resource
private TempIdMapper tempIdMapper ;
@Override
public List getRouteIdList() {
List idList = new ArrayList<>() ;
TempIdEntity tempIdEntity = new TempIdEntity ();
tempIdEntity.setCreateTime(new Date());
for (int i = 0 ; i < 2 ; i++){
tempIdMapper.insertA(tempIdEntity);
idList.add(UuidUtil.getRouteId("UID-A",10,
Long.parseLong(tempIdEntity.getId().toString()))) ;
tempIdMapper.insertB(tempIdEntity);
idList.add(UuidUtil.getRouteId("UID-B",10,
Long.parseLong(tempIdEntity.getId().toString()))) ;
tempIdMapper.insertC(tempIdEntity);
idList.add(UuidUtil.getRouteId("UID-C",10,
Long.parseLong(tempIdEntity.getId().toString()))) ;
}
return idList ;
}
} 結(jié)果樣例：
UID-A00001,UID-B00001,UID-C00001
UID-A00002,UID-B00002,UID-C00002
從數(shù)據(jù)獲取的ID基本是一個自增的整數(shù)序列，可以提供一個格式美化工具方法。
public class UuidUtil {
private static final String ZERO = "00000000000";
private static final String PREFIX = "UID";
public static String getNoId(int length,Long id){
String idVar = String.valueOf(id) ;
if (idVar.length()>length){
return PREFIX+idVar ;
} else {
int gapLen = length-idVar.length()-PREFIX.length() ;
return PREFIX+ZERO.substring(0,gapLen)+idVar ;
}
}
public static String getRouteId(String route,Integer length,Long id){
String idVar = String.valueOf(id) ;
if (idVar.length()>length){
return route+idVar ;
} else {
int gapLen = length-idVar.length()-route.length() ;
return route+ZERO.substring(0,gapLen)+idVar ;
}
}
}基于不同的策略，把ID格式為統(tǒng)一的位數(shù)。
如果在高并發(fā)的業(yè)務(wù)場景下，實時基于MySQL去生成唯一ID容易產(chǎn)生性能瓶頸，當然其他方法也可能產(chǎn)生這個問題?？梢栽谙到y(tǒng)空閑時間批量生成一批，放入緩存中，在使用的時候直接從緩存層取出即可。
以上是“分布式業(yè)務(wù)系統(tǒng)中全局ID生成策略的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！
