id生成雪花演算法

⑴ 雪花演算法與Mysql自增的優缺點

雪花演算法與Mysql自增的優缺點分別是：

雪花演算法優點是：

1、不會重復。

2、有序，不會造成空間浪費和胡亂插入影響性能。

3、生成很快特別是比UUid快得多。

4、相比UUid更小。

缺點是：時間回撥造成錯亂。

Mysql自增的優點是：

1、存儲空間小。

2、插入和查詢性能高。

缺點是：

1、int的范圍可能不夠大。

2、當要做數據遷移的時候，會很麻煩，主鍵容易沖突。

3、id自增，自身的業務增長情況很容易被別人掌握。

4、自增在高並發的情況下性能不好。

生成id的代碼是：

自增和UUid差異的原因是：mysql資料庫一般我們會採用支持事務的Innodb，在Innodb中，採用的是B+數索引。Innodb的存儲結構，是聚簇索引。對於聚簇索引順序主鍵和隨機主鍵的對效率的影響很大。

自增是順序主鍵存儲，查找和插入都很方便（插入會按順序插到前一個的後面），但UUid是無序的，通過計算獲得的hashcode也會是無序的（是按照hashcode選擇存儲位置）。

所以對於他的查找效率很低，而且因為他是無序的，他的插入有可能會插到前面的數據中，會造成很多其他的操作，很影響性能或者很多存儲空間因為沒有順序的存儲而被空缺浪費。

⑵ 如何保證資料庫集群中id的唯一性，假設每秒鍾並發20萬次

用雪花演算法的工具類,1秒內可以生成26萬不重復的值,資料庫的主鍵不要自增,手動設置

java">packageentity;

importjava.lang.management.ManagementFactory;
importjava.net.InetAddress;
importjava.net.NetworkInterface;

/**
*<p>名稱：IdWorker.java</p>
*<p>描述：分布式自增長ID</p>
*<pre>
*Twitter的SnowflakeJAVA實現方案
*</pre>
*核心代碼為其IdWorker這個類實現，其原理結構如下，我分別用一個0表示一位，用—分割開部分的作用：
*1||0------00000---00000---000000000000
*在上面的字元串中，第一位為未使用（實際上也可作為long的符號位），接下來的41位為毫秒級時間，
*然後5位datacenter標識位，5位機器ID（並不算標識符，實際是為線程標識），
*然後12位該毫秒內的當前毫秒內的計數，加起來剛好64位，為一個Long型。
*這樣的好處是，整體上按照時間自增排序，並且整個分布式系統內不會產生ID碰撞（由datacenter和機器ID作區分），
*並且效率較高，經測試，snowflake每秒能夠產生26萬ID左右，完全滿足需要。
*<p>
*64位ID(42(毫秒)+5(機器ID)+5(業務編碼)+12(重復累加))
*
*@authorPolim
*/
publicclassIdWorker{
//時間起始標記點，作為基準，一般取系統的最近時間（一旦確定不能變動）
privatefinalstaticlongtwepoch=1288834974657L;
//機器標識位數
=5L;
//數據中心標識位數
=5L;
//機器ID最大值
=-1L^(-1L<<workerIdBits);
//數據中心ID最大值
=-1L^(-1L<<datacenterIdBits);
//毫秒內自增位
=12L;
//機器ID偏左移12位
=sequenceBits;
//數據中心ID左移17位
=sequenceBits+workerIdBits;
//時間毫秒左移22位
=sequenceBits+workerIdBits+datacenterIdBits;

=-1L^(-1L<<sequenceBits);
/*上次生產id時間戳*/
=-1L;
//0，並發控制
privatelongsequence=0L;

privatefinallongworkerId;
//數據標識id部分
privatefinallongdatacenterId;

publicIdWorker(){
this.datacenterId=getDatacenterId(maxDatacenterId);
this.workerId=getMaxWorkerId(datacenterId,maxWorkerId);
}
/**
*@paramworkerId
*工作機器ID
*@paramdatacenterId
*序列號
*/
publicIdWorker(longworkerId,longdatacenterId){
if(workerId>maxWorkerId||workerId<0){
(String.format("workerIdcan'tbegreaterthan%dorlessthan0",maxWorkerId));
}
if(datacenterId>maxDatacenterId||datacenterId<0){
(String.format("datacenterIdcan'tbegreaterthan%dorlessthan0",maxDatacenterId));
}
this.workerId=workerId;
this.datacenterId=datacenterId;
}
/**
*獲取下一個ID
*
*@return
*/
publicsynchronizedlongnextId(){
longtimestamp=timeGen();
if(timestamp<lastTimestamp){
thrownewRuntimeException(String.format("Clockmovedbackwards.Refusingtogenerateidfor%dmilliseconds",lastTimestamp-timestamp));
}

if(lastTimestamp==timestamp){
//當前毫秒內，則+1
sequence=(sequence+1)&sequenceMask;
if(sequence==0){
//當前毫秒內計數滿了，則等待下一秒
timestamp=tilNextMillis(lastTimestamp);
}
}else{
sequence=0L;
}
lastTimestamp=timestamp;
//ID偏移組合生成最終的ID，並返回ID
longnextId=((timestamp-twepoch)<<timestampLeftShift)
|(datacenterId<<datacenterIdShift)
|(workerId<<workerIdShift)|sequence;

returnnextId;
}

privatelongtilNextMillis(finallonglastTimestamp){
longtimestamp=this.timeGen();
while(timestamp<=lastTimestamp){
timestamp=this.timeGen();
}
returntimestamp;
}

privatelongtimeGen(){
returnSystem.currentTimeMillis();
}

/**
*<p>
*獲取maxWorkerId
*</p>
*/
(longdatacenterId,longmaxWorkerId){
StringBuffermpid=newStringBuffer();
mpid.append(datacenterId);
Stringname=ManagementFactory.getRuntimeMXBean().getName();
if(!name.isEmpty()){
/*
*GETjvmPid
*/
mpid.append(name.split("@")[0]);
}
/*
*MAC+PID的hashcode獲取16個低位
*/
return(mpid.toString().hashCode()&0xffff)%(maxWorkerId+1);
}

/**
*<p>
*數據標識id部分
*</p>
*/
(longmaxDatacenterId){
longid=0L;
try{
InetAddressip=InetAddress.getLocalHost();
NetworkInterfacenetwork=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(Exceptione){
System.out.println("getDatacenterId:"+e.getMessage());
}
returnid;
}


publicstaticvoidmain(String[]args){
//推特26萬個不重復的ID
IdWorkeridWorker=newIdWorker(0,0);
for(inti=0;i<2600;i++){
System.out.println(idWorker.nextId());
}
}

}

⑶ 為什麼有的URL長,有的短

一、前言
前幾天整理面試題的時候，有一道試題是《如何將一個很長的URL轉換為一個短的URL，並實現他們之間的相互轉換？》，現在想起來這是一個絕對不簡單的問題，需要考慮很多方面，今天和大家一起學習研究一下！

短網址：顧名思義，就是將長網址縮短到一個很短的網址，用戶訪問這個短網址可以重定向到原本的長網址（也就是還原的過程）。這樣可以達到易於記憶、轉換的目的，常用於有字數限制的微博、二維碼等等場景。

關於短URL的使用場景，舉個簡單的例子來說明一下，看一下業務中使用短URL的重要性！

二、短地址使用場景
1、新浪微博

我們在新浪微博上發布網址的時候，微博會自動判別網址，並將其轉換，例如：https://t.cn/RuPKzRW。為什麼要這樣做的？

這是因為微博限制字數為140字一條，那麼如果我們需要發一些鏈接上去，但是這個鏈接非常的長，以至於將近要佔用跡簡我們內容的一半篇幅，這肯定是不能被允許的或者說用戶體驗很差的，所以短網址應運而生了，短網址這種服務可以說是在微博出現之後才流行開來的！往下看：

（1）首先，我先發一條微博帶有一個URL地址：

（2）然後，看他轉換之後顯示的效果是什麼樣子的哪？

（3）查看對應頁面元素的HTML源碼如下：

（4）可以看出：https://blog.csdn.net/xlgen157387/article/details/79863301 被轉換為：http://t.cn/RuPKzRW，此時你訪問http://t.cn/RuPKzRW是可以定位到https://blog.csdn.net/xlgen157387/article/details/79863301，也就是實現了轉換。

2、短網址二維碼

網址在轉換成短網址時，也可以生成相應的短網址二維碼，短網址二維碼的應用，二維碼核心解決的是跨平台、跨現實的數據傳輸問題；而且二維碼跟應用場景結合之後，所能解決的問題會越來越多。

（1）短網址二維碼相比短鏈接更方便，能少輸入，盡量少輸入，哪怕只是少點一下鍵盤，都是有意義的。

（2）二維碼只是掃描一個簡單的鏈接，打開的卻是一個世界。想像一下，用手機購買售貨機里商品，二維碼掃描是略快於從用手機找到該售貨機並找到該商品的，而且這種操作相對於搜索/查找而言不是更優雅嗎?

（3）所有商超裡面的商品，都是使用條碼來確定商品的唯一性的，去買單的時候都是掃描條碼。試想，如果裡面加入了更多產品的生產日期、廠家、流轉途徑、原材料等等信息，是不是厲害了呢?特別是針對食品信息的可追溯上，二維碼應用場景更廣泛。

三、短地址的好處
除了上述場景中，我們將長地址轉換為短地址的使用場景的優點（壓縮URL長度）之外，短地址還具有很多實際場景中的優點，例如：

（1）節省網址長度，便於社交化傳播，一個是讓URL更短小，傳播更方便，尤其是URL中有中文和特殊字元，短網址解決很長的URL難以記憶不利於傳播的問題；

（2）短網址在我們項目里啟岩可以很好的對開放以及對URL進行管理。有一部分網址可以會涵蓋性、暴力、廣告等信息，這樣我們可以通過用戶的舉報，完全管理這個連接將不出現在我們的應用中，對同樣的URL通過加密演算法之後，得到的地址是一樣的；

（3）悄州御方便後台跟蹤點擊量、地域分布等用戶統計。我們可以對一系列的網址進行流量，點擊等統計，挖掘出大多數用戶的關注點，這樣有利於我們對項目的後續工作更好的作出決策；

（4）規避關鍵詞、域名屏蔽手段、隱藏真實地址，適合做付費推廣鏈接；

（5）當你看到一個淘寶的寶貝連接後面是200個「e7x8bv7c8bisdj」這樣的字元的時候，你還會覺得舒服嗎。更何況微博字數只有140字，微博或簡訊里，字數不夠，你用條短網址就能幫你騰出很多空間來；

四、短網址服務提供平台
目前，國內網又很多提供短地址服務的平台，例如：

新浪：http://sina.lt/
網路：http://dwz.cn/
0x3：http://0x3.me/
MRW：http://mrw.so/
等等還有很多，這個可以搜索一下就會有很多！但是一個注意的是，如果使用某一個平台的短地址服務，一定要保證長期可靠的服務，不然一段時間失效了，我們以前已經轉換的URL就完了！

這里以網路例，將我們上述博客的地址轉換為短地址如下所示：

當然，對於我們的業務來說，如果自己可以提供自己的短URL服務那才是更好的，不需要受制於人！（中國晶元需要崛起！！！）

五、關於如何生成短地址URL的討論
關於短地址URL如何生成方式的，網上有很多方式，有基於映射的，有基於Hash的，有基於簽名的，但是總的來說並不能滿足絕大部分場景的使用，或者說是一種錯誤的設計方式。這里不再重復造輪子！以下是知乎用戶iammutex關於該問題的探討，截圖過來和大家一起學習一下：

作者：iammutex
鏈接：https://www.hu.com/question/29270034/answer/46446911
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請註明出處。
六、生成短地址URL需要注意的
看到上述知乎用戶iammutex關於如何正確生成短地址URL的探討，我們知道了，可以通過發號器的方式正確的生成短地址，生成演算法設計要點如下：

（1）利用放號器，初始值為0，對於每一個短鏈接生成請求，都遞增放號器的值，再將此值轉換為62進制（a-zA-Z0-9），比如第一次請求時放號器的值為0，對應62進制為a，第二次請求時放號器的值為1，對應62進制為b，第10001次請求時放號器的值為10000，對應62進制為sBc。

（2）將短鏈接伺服器域名與放號器的62進制值進行字元串連接，即為短鏈接的URL，比如：http://t.cn/sBc。

（3）重定向過程：生成短鏈接之後，需要存儲短鏈接到長鏈接的映射關系，即sBc -> URL，瀏覽器訪問短鏈接伺服器時，根據URL Path取到原始的鏈接，然後進行302重定向。映射關系可使用K-V存儲，比如Redis或Memcache。

七、生成短地址之後如何跳轉哪？
對於該部分的討論，我們可以認為他是整個交互的流程，具體的流程細節如下：

（1）用戶訪問短鏈接：http://t.cn/RuPKzRW；

（2）短鏈接伺服器http://t.cn收到請求，根據URL路徑RuPKzRW獲取到原始的長鏈接（KV緩存資料庫中去查找）：https://blog.csdn.net/xlgen157387/article/details/79863301；

（3）伺服器返回302狀態碼，將響應頭中的Location設置為：https://blog.csdn.net/xlgen157387/article/details/79863301；

（4）瀏覽器重新向https://blog.csdn.net/xlgen157387/article/details/79863301發送請求；

（5）返回響應；

八、短地址發號器優化方案
1、演算法優化

採用以上演算法，如果不加判斷，那麼即使對於同一個原始URL，每次生成的短鏈接也是不同的，這樣就會浪費存儲空間（因為需要存儲多個短鏈接到同一個URL的映射），如果能將相同的URL映射成同一個短鏈接，這樣就可以節省存儲空間了。主要的思路有如下兩個：

方案1：查表

每次生成短鏈接時，先在映射表中查找是否已有原始URL的映射關系，如果有，則直接返回結果。很明顯，這種方式效率很低。

方案2：使用LRU本地緩存，空間換時間

使用固定大小的LRU緩存，存儲最近N次的映射結果，這樣，如果某一個鏈接生成的非常頻繁，則可以在LRU緩存中找到結果直接返回，這是存儲空間和性能方面的折中。

2、可伸縮和高可用

如果將短鏈接生成服務單機部署，缺點一是性能不足，不足以承受海量的並發訪問，二是成為系統單點，如果這台機器宕機則整套服務不可 用，為了解決這個問題，可以將系統集群化，進行「分片」。

在以上描述的系統架構中，如果發號器用Redis實現，則Redis是系統的瓶頸與單點，因此，利用資料庫分片的設計思想，可部署多個發號器實例，每個實例負責特定號段的發號，比如部署10台Redis，每台分別負責號段尾號為0-9的發號，注意此時發號器的步長則應該設置為10（實例個數）。

另外，也可將長鏈接與短鏈接映射關系的存儲進行分片，由於沒有一個中心化的存儲位置，因此需要開發額外的服務，用於查找短鏈接對應的原始鏈接的存儲節點，這樣才能去正確的節點上找到映射關系。

九、如何用代碼實現短地址
1、使用隨機序列生成短地址

說到這里終於說到重點了，很多小夥伴已經按捺不住了，不好意思讓大家失望了，這只是一片簡單的文章，並不能把這么繁雜的一個系統演示清楚！秉著不要重復造輪子的原則，這里給出一個為數不多還算可以的實現短地址的開源項目：urlshorter

注意：urlshorter本身還是基於隨機的方式生成短地址的，並不算是一個短地址發號器，因此會有性能問題和沖突的出現，和知乎用戶iammutex 描述的實現方式還是有區別的！而關於短地址發號器的方式目前還沒有找到更好的開源項目可供參考！

項目地址：https://gitee.com/tinyframework/urlshorter

2、使用SnowFlake發號器生成短地址

實現參考： https://github.com/beyondfengyu/SnowFlake http://www.wolfbe.com/detail/201611/381.html

Twitter的雪花演算法SnowFlake，使用Java語言實現。

SnowFlake演算法用來生成64位的ID，剛好可以用long整型存儲，能夠用於分布式系統中生產唯一的ID， 並且生成的ID有大致的順序。 在這次實現中，生成的64位ID可以分成5個部分：

0 - 41位時間戳 - 5位數據中心標識 - 5位機器標識 - 12位序列號
5位數據中心標識、5位機器標識這樣的分配僅僅是當前實現中分配的，如果業務有其實的需要，可以按其它的分配比例分配，如10位機器標識，不需要數據中心標識。

Java代碼實現如下：

/**
* 進制轉換工具，最大支持十進制和62進制的轉換
* 1、將十進制的數字轉換為指定進制的字元串；
* 2、將其它進制的數字（字元串形式）轉換為十進制的數字
* @author xuliugen
* @date 2018/04/23
*/
public class NumericConvertUtils {

/**
* 在進製表示中的字元集合，0-Z分別用於表示最大為62進制的符號表示
*/
private static final char[] digits = {'0', '1', '2', '3', '4', '5', '6', '7', '8', '9',
'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm',
'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z',
'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M',
'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z'};

/**
* 將十進制的數字轉換為指定進制的字元串
* @param number 十進制的數字
* @param seed 指定的進制
* @return 指定進制的字元串
*/
public static String toOtherNumberSystem(long number, int seed) {
if (number < 0) {
number = ((long) 2 * 0x7fffffff) + number + 2;
}
char[] buf = new char[32];
int charPos = 32;
while ((number / seed) > 0) {
buf[--charPos] = digits[(int) (number % seed)];
number /= seed;
}
buf[--charPos] = digits[(int) (number % seed)];
return new String(buf, charPos, (32 - charPos));
}

/**
* 將其它進制的數字（字元串形式）轉換為十進制的數字
* @param number 其它進制的數字（字元串形式）
* @param seed 指定的進制，也就是參數str的原始進制
* @return 十進制的數字
*/
public static long toDecimalNumber(String number, int seed) {
char[] charBuf = number.toCharArray();
if (seed == 10) {
return Long.parseLong(number);
}

long result = 0, base = 1;

for (int i = charBuf.length - 1; i >= 0; i--) {
int index = 0;
for (int j = 0, length = digits.length; j < length; j++) {
//找到對應字元的下標，對應的下標才是具體的數值
if (digits[j] == charBuf[i]) {
index = j;
}
}
result += index * base;
base *= seed;
}
return result;
}
}
/**
* Twitter的SnowFlake演算法,使用SnowFlake演算法生成一個整數，然後轉化為62進制變成一個短地址URL
* @author beyond
* @author xuliugen
* @date 2018/04/23
*/
public class SnowFlakeShortUrl {

/**
* 起始的時間戳
*/
private final static long START_TIMESTAMP = 1480166465631L;

/**
* 每一部分佔用的位數
*/
private final static long SEQUENCE_BIT = 12; //序列號佔用的位數
private final static long MACHINE_BIT = 5; //機器標識佔用的位數
private final static long DATA_CENTER_BIT = 5; //數據中心佔用的位數

/**
* 每一部分的最大值
*/
private final static long MAX_SEQUENCE = -1L ^ (-1L << SEQUENCE_BIT);
private final static long MAX_MACHINE_NUM = -1L ^ (-1L << MACHINE_BIT);
private final static long MAX_DATA_CENTER_NUM = -1L ^ (-1L << DATA_CENTER_BIT);

/**
* 每一部分向左的位移
*/
private final static long MACHINE_LEFT = SEQUENCE_BIT;
private final static long DATA_CENTER_LEFT = SEQUENCE_BIT + MACHINE_BIT;
private final static long TIMESTAMP_LEFT = DATA_CENTER_LEFT + DATA_CENTER_BIT;

private long dataCenterId; //數據中心
private long machineId; //機器標識
private long sequence = 0L; //序列號
private long lastTimeStamp = -1L; //上一次時間戳

/**
* 根據指定的數據中心ID和機器標志ID生成指定的序列號
* @param dataCenterId 數據中心ID
* @param machineId 機器標志ID
*/
public SnowFlake(long dataCenterId, long machineId) {
if (dataCenterId > MAX_DATA_CENTER_NUM || dataCenterId < 0) {
throw new IllegalArgumentException("DtaCenterId can't be greater than MAX_DATA_CENTER_NUM or less than 0！");
}
if (machineId > MAX_MACHINE_NUM || machineId < 0) {
throw new IllegalArgumentException("MachineId can't be greater than MAX_MACHINE_NUM or less than 0！");
}
this.dataCenterId = dataCenterId;
this.machineId = machineId;
}

/**
* 產生下一個ID
* @return
*/
public synchronized long nextId() {
long currTimeStamp = getNewTimeStamp();
if (currTimeStamp < lastTimeStamp) {
throw new RuntimeException("Clock moved backwards. Refusing to generate id");
}

if (currTimeStamp == lastTimeStamp) {
//相同毫秒內，序列號自增
sequence = (sequence + 1) & MAX_SEQUENCE;
//同一毫秒的序列數已經達到最大
if (sequence == 0L) {
currTimeStamp = getNextMill();
}
} else {
//不同毫秒內，序列號置為0
sequence = 0L;
}

lastTimeStamp = currTimeStamp;

return (currTimeStamp - START_TIMESTAMP) << TIMESTAMP_LEFT //時間戳部分
| dataCenterId << DATA_CENTER_LEFT //數據中心部分
| machineId << MACHINE_LEFT //機器標識部分
| sequence; //序列號部分
}

private long getNextMill() {
long mill = getNewTimeStamp();
while (mill <= lastTimeStamp) {
mill = getNewTimeStamp();
}
return mill;
}

private long getNewTimeStamp() {
return System.currentTimeMillis();
}

public static void main(String[] args) {
SnowFlake snowFlake = new SnowFlake(2, 3);

for (int i = 0; i < (1 << 4); i++) {
//10進制
Long id = snowFlake.nextId();
//62進制
String convertedNumStr = NumericConvertUtils.toOtherNumberSystem(id, 62);

//10進制轉化為62進制
System.out.println("10進制：" + id + " 62進制:" + convertedNumStr);

//TODO 執行具體的存儲操作，可以存放在Redis等中

//62進制轉化為10進制
System.out.println("62進制：" + convertedNumStr + " 10進制:" + NumericConvertUtils.toDecimalNumber(convertedNumStr, 62));
System.out.println();
}
}
}
//生成結果：
10進制：185784275776581632 62進制:dITqmhW2

⑷ 雪花演算法之【線上訂單號重復了一招搞定它！】

公司老的系統原先採用的時間戳生成訂單號，導致了如下情形

打斷一下：大家知道怎麼查系統某項重復的數據吧

不得了，這樣重復豈不是一單成功三方回調導致另一單也成功了。

多個服務差桐怎麼保證生成的戚正訂單號唯一呢？

先上code

以上是採用snowflake演算法生成分布式唯一ID

41-bit的時間可以表示 （1L<<41）/(1000L360024*365)=69 年的時間，10-bit機器可以分別表示1024台機器。如果我們對IDC劃分有需求，還可以將10-bit分5-bit給IDC，分5-bit給工作機器。

這樣就可以表示32個IDC，每個IDC下可以有32台機器，可以根據自身需求定義。12個自增序列號可以表示 2^12 個ID，理論上snowflake方案的QPS約為 409.6w/s ，這種分配方式虛仔坦可以保證在任何一個IDC的任何一台機器在任意毫秒內生成的ID都是不同的。

這種方式的優缺點是：

優點：

缺點：

一般來說，採用這種方案就解決了。

還有諸如，mysql的 auto_increment策略，redis的INCR，zookeeper的單一節點修改版本號遞增，以及zookeeper的持久順序節點。

⑸ 雪花演算法（SnowFlake）

解決方法：

首先，SnowFlake的末尾12位是序列號，用來記錄同一毫秒內產生的不同id，同一毫秒總共可以產生4096個id，每一毫秒的序列號都是從0這個基礎序列號開始遞增。假設我們的業務系統在單機上的QPS為3w/s，那麼其實平均每毫秒只需要產生30個id即可，遠沒有達到設計的4096，也就是說通常情況下序列號的使用都是處在一個低水位，當發生時鍾回撥的時候，這些尚未被使用的序號就可以派上用場了。
因此，可以對給定的基礎序列號稍加修改，後面每發生一次時鍾回撥就將基礎序列號加上指定的步長，例如開始時是從0遞增，發生一次時鍾世叢判回撥後從1024開始遞增，再發生一次時鍾回撥則從2048遞增，這樣還能夠滿足3次的時鍾回撥到同一時間點。

改變原來的末尾sequence生成方法：

snowflake演算法給workerId預留了10位，即workId的取值范圍為[0, 1023]，事實上實際生搜改產環境不大可能需要部署1024個分布式ID服務，所以：將workerId取值范圍縮小為鄭備[0, 511]，[512, 1023]這個范圍的workerId當做備用workerId。workId為0的備用workerId是512，workId為1的備用workerId是513，以此類推……