高性能可定制化分布式发号器
高性能可定制化分布式发号器
liubingsmile 发表于10个月前
高性能可定制化分布式发号器
  • 发表于 10个月前
  • 阅读 3734
  • 收藏 162
  • 点赞 1
  • 评论 19

新睿云服务器60天免费使用,快来体验!>>>   

摘要: 分布式发号器

一 什么是分布式发号器

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

二  分布式发号器优势

  1. 解决分库分表中唯一序号的问题
  2. 解决分布式应用或者微服务框架中唯一序号的问题
  3. 提供可定制化生成规则,根据业务需求可自定义扩展
  4. 性能高效且系统简单稳定
  5. 系统可任意扩展

三 分布式发号器架构图

    

四 分布式发号器流程图

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

序号 字段名称 字段类型 描述
concurrentValue 当前值 Integer 当前最新值
step 步长 Integer 每个应用步长不一样, 防止生成重复
maxValue 最大值 Integer 每个应用的最大值
defExpession 自定义表达式 String 自定义生成规则表达式

    2) concurrentValue不存在的流程图

     

    3) concurrentValue存在的流程图

      

 

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

1) UUID

        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台机器范围之内。

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

 

六) 推荐大神开涛书籍(京东有卖,绝对干货满满,买书送知识)

  • 打赏
  • 点赞
  • 收藏
  • 分享
共有 人打赏支持
liubingsmile
粉丝 112
博文 3
码字总数 6238
作品 7
评论 (19)
刘大神
这个分布式发号器就只是解决分布式数据库键值重复的问题么?
liubingsmile

引用来自“刘大神”的评论

这个分布式发号器就只是解决分布式数据库键值重复的问题么?

回复@刘大神 : 不只是,比如券码,提货码等
刘大神

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

这个分布式发号器就只是解决分布式数据库键值重复的问题么?

回复@刘大神 : 不只是,比如券码,提货码等

回复@liubingsmile : 哦哦,那你的键值生成是一种什么样子的策略呢?
liubingsmile

引用来自“刘大神”的评论

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

这个分布式发号器就只是解决分布式数据库键值重复的问题么?

回复@刘大神 : 不只是,比如券码,提货码等

回复@liubingsmile : 哦哦,那你的键值生成是一种什么样子的策略呢?

回复@刘大神 : 可以自定义配置
刘大神

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

这个分布式发号器就只是解决分布式数据库键值重复的问题么?

回复@刘大神 : 不只是,比如券码,提货码等

回复@liubingsmile : 哦哦,那你的键值生成是一种什么样子的策略呢?

回复@刘大神 : 可以自定义配置

回复@liubingsmile : 举个栗子
liubingsmile

引用来自“刘大神”的评论

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

这个分布式发号器就只是解决分布式数据库键值重复的问题么?

回复@刘大神 : 不只是,比如券码,提货码等

回复@liubingsmile : 哦哦,那你的键值生成是一种什么样子的策略呢?

回复@刘大神 : 可以自定义配置

回复@liubingsmile : 举个栗子
比如生成规则,需要根据不同的系统生成不一样的规则
刘大神

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

这个分布式发号器就只是解决分布式数据库键值重复的问题么?

回复@刘大神 : 不只是,比如券码,提货码等

回复@liubingsmile : 哦哦,那你的键值生成是一种什么样子的策略呢?

回复@刘大神 : 可以自定义配置

回复@liubingsmile : 举个栗子
比如生成规则,需要根据不同的系统生成不一样的规则

回复@liubingsmile : 那如果这个系统同时用到N个系统的时候,生成规则不会出现一丢丢的冲突的可能么?其实,我想知道你具体生成规则是怎么样子的,比如说我现在用的,对本地时间做一些简单的位移运算,这样时间是唯一的,就不会出现重复的情况
名字不好取啊啊
刘利民
不开源吗,让大家也学习一下
liubingsmile

引用来自“刘大神”的评论

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

引用来自“liubingsmile”的评论

引用来自“刘大神”的评论

这个分布式发号器就只是解决分布式数据库键值重复的问题么?

回复@刘大神 : 不只是,比如券码,提货码等

回复@liubingsmile : 哦哦,那你的键值生成是一种什么样子的策略呢?

回复@刘大神 : 可以自定义配置

回复@liubingsmile : 举个栗子
比如生成规则,需要根据不同的系统生成不一样的规则

回复@liubingsmile : 那如果这个系统同时用到N个系统的时候,生成规则不会出现一丢丢的冲突的可能么?其实,我想知道你具体生成规则是怎么样子的,比如说我现在用的,对本地时间做一些简单的位移运算,这样时间是唯一的,就不会出现重复的情况
你要考虑分布式应用
liubingsmile

引用来自“刘利民”的评论

不开源吗,让大家也学习一下
源码不开源,不好意思
天豪-Jason
有点深奥,对于我这个小白来说
loki_lan
服务本身生成UUID跟分布式发号器生成UUID不是一样吗,前者可以保证不重复,是不是就不需要发号器了呢?
liubingsmile

引用来自“loki_lan”的评论

服务本身生成UUID跟分布式发号器生成UUID不是一样吗,前者可以保证不重复,是不是就不需要发号器了呢?
先看懂规则,不一样的
吴建南
concurrentValue....并发值?
liubingsmile

引用来自“吴建南”的评论

concurrentValue....并发值?
最新值,最近值
liubingsmile

引用来自“loki_lan”的评论

服务本身生成UUID跟分布式发号器生成UUID不是一样吗,前者可以保证不重复,是不是就不需要发号器了呢?
两者方式不一样
繁华似水
不同机器生产的id可以比较大小么??
oreak
还得依赖redis,不好
×
liubingsmile
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: