高性能可定制化分布式发号器

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

玄靖

刘兵,花名玄靖,目前供职于阿里巴巴,开源技术爱好者,高性能Redis中间件NRedis-Proxy作者,目前研究方向为java中间件,微服务等技术。


(一) 什么是分布式发号器

    说起分布式发号器的前生今世,咱们应该感恩这个时代;随着互联网在中国越来越普及化,单机系统或者一个小系统已经无法满足需要,随着用户逐渐增多,数据量越来越大,单个应用或者单个数据库已经无法满足需求,在应用以至于微服务来临,在数据库存储方面分库分表来临,可以解决问题;但是新的问题产生,怎么样做到多个应用可以有唯一主键或者序号,防止数据重复呢?分布式发号器正好为解决这个问题,可以让大家无须为这个问题烦恼了,这是本人写这篇文章初衷

(二) 分布式发号器优势

1) 解决分库分表中唯一序号的问题

2) 解决分布式应用或者微服务框架中唯一序号的问题

3) 提供可定制化生成规则,根据业务需求可自定义扩展

4) 性能高效且系统简单稳定

5) 系统可任意扩展

(三) 分布式发号器架构图

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

(四) 分布式发号器流程图

1) 分布式发号器重要字段


640?wx_fmt=png&wxfrom=5&wx_lazy=1


2) concurrentValue不存在的流程图


640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

3) concurrentValue存在的流程图

640?wx_fmt=jpeg&wxfrom=5&wx_lazy=1

(五) 目前存在分布式发号器解决方案

1) UUID

 Universally Unique IDentifier(UUID),有着正儿八经的RFC规范,是一个128bit的数字,也可以表现为32个16进制的字符(每个字符0-F的字符代表4bit),中间用"-"分割。

 时间戳+UUID版本号: 分三段占16个字符(60bit+4bit)

 Clock Sequence号与保留字段:占4个字符(13bit+3bit)

 节点标识:占12个字符(48bit)

2) Hibernate

Hibernate的CustomVersionOneStrategy.java,解决了之前version 1的两个问题

 时间戳(6bytes, 48bit):毫秒级别的,从1970年算起,能撑8925年....

 顺序号(2bytes, 16bit, 最大值65535): 没有时间戳过了一毫秒要归零的事,各搞各的,short溢出到了负数就归0。

 机器标识(4bytes 32bit): 拿localHost的IP地址,IPV4呢正好4个byte,但如果是IPV6要16个bytes,就只拿前4个byte。

 进程标识(4bytes 32bit): 用当前时间戳右移8位再取整数应付,不信两条线程会同时启动。

3) MongoDB

  MongoDB的ObjectId.java

 时间戳(4 bytes 32bit):是秒级别的,从1970年算起,能撑136年。

 自增序列(3bytes 24bit, 最大值一千六百万): 是一个从随机数开始(机智)的Int不断加一,也没有时间戳过了一秒要归零的事,各搞各的。因为只有3bytes,所以一个4bytes的Int还要截一下后3bytes。

 机器标识(3bytes 24bit): 将所有网卡的Mac地址拼在一起做个HashCode,同样一个int还要截一下后3bytes。搞不到网卡就用随机数混过去。

 进程标识(2bytes 16bits):从JMX里搞回来到进程号,搞不到就用进程名的hash或者随机数混过去。

可见,MongoDB的每一个字段设计都比Hibernate的更合理一点,时间戳是秒级别的,自增序列变长了,进程标识变短了。总长度也降到了12 bytes 96bit。

4) Twitter的snowflake派号器

  snowflake也是一个派号器,基于Thrift的服务,不过不是用redis简单自增,而是类似UUID version1,

只有一个Long 64bit的长度,所以IdWorker紧巴巴的分配成:

 时间戳(42bit) :自从2012年以来(比那些从1970年算起的会过日子)的毫秒数,能撑139年。

 自增序列(12bit,最大值4096):毫秒之内的自增,过了一毫秒会重新置0。

 DataCenter ID (5 bit, 最大值32):配置值,支持多机房。

 Worker ID ( 5 bit, 最大值32),配置值,因为是派号器的id,一个机房里最多32个派号器就够了,还会在ZK里做下注册。

        可见,因为是中央派号器,把至少40bit的节点标识都省出来了,换成10bit的派号器标识。所以整个UID能够只用一个Long表达。

  另外,这种派号器,client每次只能一个ID,不能批量取,所以额外增加的延时是问题,而且只能1024台机器范围之内。

  以上几种方案同一个问题,不可自定义,位数过长


来源:中生代技术

原文链接


  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值