野谈系列之高性能可定制化分布式发号器

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

一、什么是分布式发号器

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

二、分布式发号器优势

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

三、分布式发号器架构图

Paste_Image.png

四、分布式发号器流程图

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

Paste_Image.png

2、concurrentValue不存在的流程图

图片 1.png

3、concurrentValue存在的流程图

图片 2.png

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

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 条评论
登录 后参与评论

相关文章

来自专栏开发 & 算法杂谈

基于Lockset的数据竞争检测方法汇总(二)

前一篇文章提到的是使用Lockset最经典的方法,但是存在很多误报,针对这些误报产生的原因,有很多分析并改进了原始的Lockset方法,今天主要和大家谈的就是有...

18770
来自专栏杨建荣的学习笔记

同样的sql执行结果不同的原因分析 (r4笔记第27天)

今天开发的同事问我一个问题,说有一个sql语句,在weblogic的日志中执行没有结果,但是手动拷贝数据到客户端执行,却能够查到。这种奇怪的问题一下子就能引起我...

30780
来自专栏xingoo, 一个梦想做发明家的程序员

JSP简要

  本篇知识导图 ?   说起JSP,当年做课程设计什么的都用的这个,虽然技术比较古老,但是还是挺广泛使用的。   JSP是一种前台的展现语言,在mvc里面属于...

22960
来自专栏UDNZ

【译】Go 语言实践:编写可维护的程序的建议

本文为 QCon 2018 上海站主题演讲嘉宾、Heptio 资深工程师、著名 Go 语言专家 David Cheney 关于 Go 语言实践的英文分享。为方便...

54380
来自专栏博客园迁移

日常理解

{ 空 } 1. 什么叫线程安全?servlet是线程安全吗? { 答:如果你的代码所在的进程中有多个线程在同时运行,而这些线程可能会同时运行这段代码。如果每次...

9720
来自专栏游戏杂谈

Ant+JSDocTookit生成Javascript文档

需要备上下面三样东西 JSDocTookit http://code.google.com/p/jsdoc-toolkit/

23930
来自专栏Python自动化测试

工厂设计模式在自动化中的引用(一)

在自动化测试的范围中,目前依据webdriver的,web应用测试框架有selenium2,对于移动app自动化的测试,有appium,selen...

18930
来自专栏Golang语言社区

网游内存数据库的设计(1)

网络游戏的数据变动比较频繁,如果每次数据变动都刷往后端数据库,会导致数据库不负重荷。在游戏逻辑和数据库间提供一层缓冲服务,有利于减轻这重压力. 首先,网络游戏的...

39160
来自专栏Golang语言社区

网游内存数据库的设计(1)

网络游戏的数据变动比较频繁,如果每次数据变动都刷往后端数据库,会导致数据库不负重荷。在游戏逻辑和数据库间提供一层缓冲服务,有利于减轻这重压力. 首先,网络游戏的...

39870
来自专栏SDNLAB

Ryu的一些设计方法解读

作为一个业余研究Ryu的软件工程师,一直惊叹于Ryu设计的优雅与简洁。一年多坚持下来,也有自己的一些收获,写出来和大家分享一下。 我们的故事从@set_ev_c...

34060

扫码关注云+社区

领取腾讯云代金券