一、缘起

为什么会突然谈到分布式唯一id呢？原因是最近在准备使用RocketMQ，看看官网介绍：

一句话，消息可能会重复，所以消费端需要做幂等。为什么消息会重复后续RocketMQ章节进行详细介绍，本节重点不在这里。

为了达到业务的幂等，必须要有这样一个id存在，需要满足下面几个条件：

同一业务场景要全局唯一。

该id必须是在消息的发送方进行产生发送到MQ。

消费端根据该id进行判断是否重复，确保幂等。

在那里产生，和消费端进行判断等和这个id没有关系，这个id的要求就是局部唯一或者全局唯一即可，由于这个id是唯一的，可以用来当数据库的主键。

那么该id需要有2个特性：

（1）局部、全局唯一

（2）趋势递增

如果有方法可以生成全局唯一（那么在局部也一定唯一了），生成分布式唯一id的方法有很多。大家可以看看分布式系统唯一ID生成方案汇总：http://www.cnblogs.com/haoxinyue/p/5208136.html（由于微信不是他的地址都显示不出来，所以把地址贴出来下），这个文章里面提到了很多以及各各的优缺点。本文关注重点是snowflake算法，该算法实现得到的id就满足上面提到的2点。

二、snowflake算法

snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是0。

该算法实现基本就是二进制操作，这个算法单机每秒内理论上最多可以生成1000*(2^12)，也就是409.6万个ID，（吼吼，这个得了的快啊）。

java实现代码基本上就是类似这样的（都差不多，基本就是二进制位操作）：

参考：https://www.cnblogs.com/relucent/p/4955340.html

/**

* Twitter_Snowflake<br>

* SnowFlake的结构如下(每部分用-分开):<br>

* 0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000 <br>

* 1位标识，由于long基本类型在Java中是带符号的，最高位是符号位，正数是0，负数是1，所以id一般是正数，最高位是0<br>

* 41位时间截(毫秒级)，注意，41位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截)

* 得到的值），这里的的开始时间截，一般是我们的id生成器开始使用的时间，由我们程序来指定的（如下下面程序IdWorker类的startTime属性）。41位的时间截，可以使用69年，年T = (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69<br>

* 10位的数据机器位，可以部署在1024个节点，包括5位datacenterId和5位workerId<br>

* 12位序列，毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号<br>

* 加起来刚好64位，为一个Long型。<br>

* SnowFlake的优点是，整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞(由数据中心ID和机器ID作区分)，并且效率较高，经测试，SnowFlake每秒能够产生26万ID左右。

*/publicclassSnowflakeIdWorker{

// ==============================Fields===========================================

/** 开始时间截 (2015-01-01)

 */privatefinallongtwepoch =1420041600000L;

/** 机器id所占的位数

 */privatefinallongworkerIdBits =5L;

/** 数据标识id所占的位数

 */privatefinallongdatacenterIdBits =5L;

/** 支持的最大机器id，结果是31 (这个移位算法可以很快的计算出几位二进制数所能表示的最大十进制数)

*/privatefinallongmaxWorkerId = -1L^ (-1L<< workerIdBits);/** 支持的最大数据标识id，结果是31 

*/privatefinallongmaxDatacenterId = -1L^ (-1L<< datacenterIdBits);

/** 序列在id中占的位数 

*/privatefinallongsequenceBits =12L;

/** 机器ID向左移12位 

*/privatefinallongworkerIdShift = sequenceBits;

/** 数据标识id向左移17位(12+5) 

*/privatefinallongdatacenterIdShift = sequenceBits + workerIdBits;

/** 时间截向左移22位(5+5+12) */privatefinallongtimestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;

/** 生成序列的掩码，这里为4095 (0b111111111111=0xfff=4095) 

*/privatefinallongsequenceMask = -1L^ (-1L<< sequenceBits);

/** 工作机器ID(0~31) 

*/privatelongworkerId;

/** 数据中心ID(0~31) 

*/privatelongdatacenterId;

/** 毫秒内序列(0~4095) 

*/privatelongsequence =0L;

/** 上次生成ID的时间截 */privatelonglastTimestamp = -1L;

//==============================Constructors=====================================

/**    * 构造函数    

 *@paramworkerId 工作ID (0~31)    

 *@paramdatacenterId 数据中心ID (0~31)    

 */publicSnowflakeIdWorker(longworkerId,longdatacenterId){

if(workerId > maxWorkerId || workerId <0) {

thrownewIllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0", maxWorkerId));        

}if(datacenterId > maxDatacenterId || datacenterId <0) {

thrownewIllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0", maxDatacenterId));        

}

this.workerId = workerId;this.datacenterId = datacenterId;    

}

// ==============================Methods==========================================

/**    * 获得下一个ID (该方法是线程安全的)    

*@returnSnowflakeId     

*/publicsynchronizedlongnextId(){longtimestamp = timeGen();//如果当前时间小于上一次ID生成的时间戳，说明系统时钟回退过这个时候应当抛出异常if(timestamp < lastTimestamp) {

thrownewRuntimeException(                    

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位的IDreturn((timestamp - twepoch) << timestampLeftShift)

//| (datacenterId << datacenterIdShift)//| (workerId << workerIdShift)//| sequence;    }

/**    * 阻塞到下一个毫秒，直到获得新的时间戳    

 *@paramlastTimestamp 上次生成ID的时间截    

 *@return当前时间戳    

 */protectedlongtilNextMillis(longlastTimestamp){longtimestamp = timeGen();while(timestamp <= lastTimestamp) {            

timestamp = timeGen();        

}

returntimestamp;    

}

/**    * 返回以毫秒为单位的当前时间    

 *@return当前时间(毫秒)    

 */protectedlongtimeGen(){returnSystem.currentTimeMillis();    }

//==============================Test=============================================

/** 测试 

*/publicstaticvoidmain(String[] args){        

SnowflakeIdWorker idWorker =newSnowflakeIdWorker(0,0);for(inti =0; i <1000; i++) {

longid = idWorker.nextId();            

System.out.println(Long.toBinaryString(id));            

System.out.println(id);        

}   

 }

}

优点：

快（哈哈，天下武功唯快不破）。

没有啥依赖，实现也特别简单。

知道原理之后可以根据实际情况调整各各位段，方便灵活。

缺点：

只能趋势递增。（有些也不叫缺点，网上有些如果绝对递增，竞争对手中午下单，第二天在下单即可大概判断该公司的订单量，危险！！！）

依赖机器时间，如果发生回拨会导致可能生成id重复。

下面重点讨论时间回拨问题。

三、snowflake算法时间回拨问题思考

由于存在时间回拨问题，但是他又是那么快和简单，我们思考下是否可以解决呢？ 零度在网上找了一圈没有发现具体的解决方案，但是找到了一篇美团不错的文章：Leaf——美团点评分布式ID生成系统（https://tech.meituan.com/MT_Leaf.html）文章很不错，可惜并没有提到时间回拨如何具体解决。下面看看零度的一些思考：

分析时间回拨产生原因

第一：人物操作，在真实环境一般不会有那个傻逼干这种事情，所以基本可以排除。

第二：由于有些业务等需要，机器需要同步时间服务器（在这个过程中可能会存在时间回拨，查了下我们服务器一般在10ms以内（2小时同步一次））。

解决方法

由于是分布在各各机器自己上面，如果要几台集中的机器（并且不做时间同步），那么就基本上就不存在回拨可能性了（曲线救国也是救国，哈哈），但是也的确带来了新问题，各各结点需要访问集中机器，要保证性能，百度的uid-generator产生就是基于这种情况做的（每次取一批回来，很好的思想，性能也非常不错）https://github.com/baidu/uid-generator。

如果到这里你采纳了，基本就没有啥问题了，你就不需要看了，如果你还想看看零度自己的思考可以继续往下看看（零度的思考只是一种思考 可能也不一定好，期待你的交流。），uid-generator我还没有细看，但是看测试报告非常不错，后面有空的确要好好看看。

下面谈谈零度自己的思考，之前也大概和美团Leaf作者交流了下，的确零度的这个可以解决一部分问题，但是引入了一些其他问题和依赖。是零度的思考，期待更多的大佬给点建议。

时间问题回拨的解决方法：

当回拨时间小于15ms，就等时间追上来之后继续生成。

当时间大于15ms时间我们通过更换workid来产生之前都没有产生过的来解决回拨问题。

首先把workid的位数进行了调整（15位可以达到3万多了，一般够用了）

Snowflake算法稍微调整下位段：

sign(1bit)

固定1bit符号标识，即生成的畅途分布式唯一id为正数。

delta seconds (38 bits)

当前时间，相对于时间基点"2017-12-21"的增量值，单位：毫秒，最多可支持约8.716年

worker id (15 bits)

机器id，最多可支持约3.28万个节点。

sequence (10 bits)每秒下的并发序列，10 bits，这个算法单机每秒内理论上最多可以生成1000*(2^10)，也就是100W的ID，完全能满足业务的需求。

由于服务无状态化关系，所以一般workid也并不配置在具体配置文件里面，看看我这篇的思考，为什么需要无状态化。高可用的一些思考和理解，这里我们选择redis来进行中央存储（zk、db）都是一样的，只要是集中式的就可以。

下面到了关键了：

现在我把3万多个workid放到一个队列中（基于redis），由于需要一个集中的地方来管理workId，每当节点启动时候，（先在本地某个地方看看是否有 借鉴弱依赖zk 本地先保存），如果有那么值就作为workid，如果不存在，就在队列中取一个当workid来使用（队列取走了就没了 ），当发现时间回拨太多的时候，我们就再去队列取一个来当新的workid使用，把刚刚那个使用回拨的情况的workid存到队列里面（队列我们每次都是从头取，从尾部进行插入，这样避免刚刚a机器使用又被b机器获取的可能性）。

有几个问题值得思考：

如果引入了redis为啥不用redis下发id？（查看分布式系统唯一ID生成方案汇总会获得答案，我们这里仅仅是用来一致性队列的，能做一致性队列的基本都可以)。

引入redis就意味着引入其他第三方的架构，做基础框架最好是不要引用（越简单越好，目前还在学习提高）。

redis一致性怎么保证？（redis挂了怎么办，怎么同步，的确值得商榷。可能会引入会引入很多新的小问题）。

四、总结

所以选择类似百度的那种做法比较好，集中之后批取，零度的思考虽然思考了，但是从基础组件来看并不是特别合适，但是也算一种思路吧。期待与大佬们的交流。