匠心零度 转载请注明原创出处,谢谢!

缘起

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

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

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

  • 同一业务场景要全局唯一。
  • 该id必须是在消息的发送方进行产生发送到MQ。
  • 消费端根据该id进行判断是否重复,确保幂等。

在那里产生,和消费端进行判断等和这个id没有关系,这个id的要求就是局部唯一或者全局唯一即可,由于这个id是唯一的,可以用来当数据库的主键,既然要做主键那么之前刚刚好发过一篇文章:从开发者角度谈Mysql(1):主键问题,文章重点提到为什么需要自增、或者趋势自增的好处。(和Mysql数据存储做法有关)。

那么该id需要有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。

该算法实现基本就是二进制操作,如果二进制不熟悉的可以看看我之前写的相关文章:java二进制相关基础二进制实战技巧

这个算法单机每秒内理论上最多可以生成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左右。
*/
public class SnowflakeIdWorker { // ==============================Fields===========================================
/** 开始时间截 (2015-01-01) */
private final long twepoch = 1420041600000L; /** 机器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=====================================
/**
* 构造函数
* @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生成的时间戳,说明系统时钟回退过这个时候应当抛出异常
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();
} //==============================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(Long.toBinaryString(id));
System.out.println(id);
}
}
}

优点:

  • 快(哈哈,天下武功唯快不破)。
  • 没有啥依赖,实现也特别简单。
  • 知道原理之后可以根据实际情况调整各各位段,方便灵活。

缺点:

  • 只能趋势递增。(有些也不叫缺点,网上有些如果绝对递增,竞争对手中午下单,第二天在下单即可大概判断该公司的订单量,危险!!!)
  • 依赖机器时间,如果发生回拨会导致可能生成id重复。

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

snowflake算法时间回拨问题思考

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

文章很不错,可惜并没有提到时间回拨如何具体解决。下面看看零度的一些思考:

分析时间回拨产生原因

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

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

解决方法

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

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

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

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

  1. 当回拨时间小于15ms,就等时间追上来之后继续生成。
  2. 当时间大于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挂了怎么办,怎么同步,的确值得商榷。可能会引入会引入很多新的小问题)。

总结

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


**如果读完觉得有收获的话,欢迎点赞、关注、加公众号 [匠心零度] ,查阅更多精彩历史!!! **

分布式唯一id:snowflake算法思考的更多相关文章

  1. 分布式唯一ID生成算法-雪花算法

    在我们的工作中,数据库某些表的字段会用到唯一的,趋势递增的订单编号,我们将介绍两种方法,一种是传统的采用随机数生成的方式,另外一种是采用当前比较流行的“分布式唯一ID生成算法-雪花算法”来实现. 一. ...

  2. 关于分布式唯一ID,snowflake的一些思考及改进(完美解决时钟回拨问题)

    1.写唯一ID生成器的原由 在阅读工程源码的时候,发现有一个工具职责生成一个消息ID,方便进行全链路的查询,实现方式特别简单,核心源码不过两行,根据时间戳以及随机数生成一个ID,这种算法ID在分布式系 ...

  3. 分布式唯一ID生成方案选型!详细解析雪花算法Snowflake

    分布式唯一ID 使用RocketMQ时,需要使用到分布式唯一ID 消息可能会发生重复,所以要在消费端做幂等性,为了达到业务的幂等性,生产者必须要有一个唯一ID, 需要满足以下条件: 同一业务场景要全局 ...

  4. 分布式唯一ID极简教程

    原创 2017-11-21 帝都羊 架构师小秘圈 一,题记 所有的业务系统,都有生成ID的需求,如订单id,商品id,文章ID等.这个ID会是数据库中的唯一主键,在它上面会建立聚集索引! ID生成的核 ...

  5. 百度开源的分布式唯一ID生成器UidGenerator,解决了时钟回拨问题

    UidGenerator是百度开源的Java语言实现,基于Snowflake算法的唯一ID生成器.而且,它非常适合虚拟环境,比如:Docker.另外,它通过消费未来时间克服了雪花算法的并发限制.Uid ...

  6. 分布式唯一ID生成常用方案

    1. 使用JAVA的UUID生成 算法的核心思想是结合机器的网卡.当地时间.一个随记数来生成UUID. 优点:本地生成,生成简单,性能好,没有高可用风险 缺点:长度过长,字母和数字组合,存储冗余,且无 ...

  7. 讲分布式唯一id,这篇文章很实在

    分布式唯一ID介绍 分布式系统全局唯一的 id 是所有系统都会遇到的场景,往往会被用在搜索,存储方面,用于作为唯一的标识或者排序,比如全局唯一的订单号,优惠券的券码等,如果出现两个相同的订单号,对于用 ...

  8. 分布式唯一id生成器的想法

    0x01 起因 前端时间遇到一个问题,怎么快速生成唯一的id,后来采用了hashid的方法.最近在网上读到了美团关于分布式唯一id生成器的解决方案, 其中提到了三种生成法:(建议看一下这篇文章,写得很 ...

  9. 开源项目|Go 开发的一款分布式唯一 ID 生成系统

    原文连接: 开源项目|Go 开发的一款分布式唯一 ID 生成系统 今天跟大家介绍一个开源项目:id-maker,主要功能是用来在分布式环境下生成唯一 ID.上周停更了一周,也是用来开发和测试这个项目的 ...

随机推荐

  1. java与C++变量初始化的对比

    java尽力保证:所有变量在使用前都能得到恰当的初始化 ①函数/方法局部变量的初始化 在C/C++中,变量的初始化还是得依赖于程序员的自觉性.对于函数局部变量,编译器不会为基本类型赋予默认初始值,新手 ...

  2. TCP为什么需要3次握手与4次挥手(转载)

    为什么需要“三次握手” 在谢希仁著<计算机网络>第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误”.在另一部经典的<计算机网络> ...

  3. 将TinyXml快速入门的接口面向对象化(转载)

    作者:朱金灿 来源:http://www.cnblogs.com/clever101 在TinyXml快速入门的系列文章中(详情见本博客),我只是将tinyxml类库解析xml文件的类封装为API接口 ...

  4. pycharm中一直跳出updating indices...indexing

    直接比较明显的就是cpu直冲天际. pycharm是一款用了就不愿意换的ide,因为他的功能十分强大,同时也有着让人诟病的问题,就是他功能太全了,以至于有的功能你这辈子可能都不会去触碰,带来的直接问题 ...

  5. Struts2与Ajax数据交互

    写在前面: ajax请求在项目中常常使用,今天就平时掌握的总结一下,关于使用ajax请求到Struts2中的action时,前台页面与后台action之间的数据传递交互问题. 这里我主要记录下自己所掌 ...

  6. nxlog4go 简介 - 基于log4go的下一代go语言日志系统

    nxlog4go的项目网址: https://github.com/ccpaging/nxlog4go 项目历史 ccpaging's log4go forked from https://githu ...

  7. block一点也不神秘————如何利用block进行回调

    我们在开发中常常会用到函数回调,你可以用通知来替代回调,但是大多数时候回调是比通知方便的,所以何乐而不为呢?如果你不知道回调使用的场景,我们来假设一下: 1.我现在玩手机 2.突然手机没有电了 3.我 ...

  8. linux 动态库的符号冲突问题

    最近,给同事定位了一个符号表的冲突问题,简单记录一下. A代码作为静态链接库,被包含进了B代码,然后编译成了动态链接库,B.so A代码同时作为静态链接库,被编译进入了main的主代码. main函数 ...

  9. JavaScript的三种类型检测typeof , instanceof , toString比较

    1.typeof typeof是js的一个操作符,在类型检测中,几乎没有任何用处. typeof 返回一个表达式的数据类型的字符串,返回结果为javascript中的基本数据类型,包括:number. ...

  10. scss 编译方法

    第一种: 手动创建 scss文件夹  用Node.js command promt  进入项目目录  在项目目录下面 输入  sass scss/main.scss css/main.css    s ...