认识达内从这里开始

今天昆明达内培训老师给大家分享：关于定制化分布式发号器的知识！

一什么是分布式发号器

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

二 分布式发号器优势

解决分库分表中序号的问题

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

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

性能高效且系统简单稳定

系统可任意扩展

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

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的长度。

昆明达内培训老师就给大家分享到这里了，后期还会有更多内容分享给大家，不要错过噢！