image
ZERO
持续更新 请关注：https://zorkelvll.cn/blogs/zorkelvll/articles/2018/11/18/1542543790245
零、基本术语
**发号器**：用于生成唯一流水号（也即俗称的唯一ID）的服务系统，称之为发号器
一、技术选型
UUID
优点：能够保证唯一性
**缺点：**（1）完全的时间数据=>性能比较差、比较长、占用空间大、间接导致数据库性能下降;（2）**无序**=>导致**B+树索引**在写的时候会有过多的随机写操作，不会产生有顺序的append操作，而是需要进行insert操作，这将读取整个B+树节点到内存并在插入该条记录后会将整个节点写会磁盘=>在记录占用空间比较大的情况下，**写的性能会明显下降**
数据库
**单库**时（自增字段）：局限性在于**自增字段**完全依赖数据库，会导致**数据库移植、扩容、洗数据、分库分表**问题
**分库分表**时（水平伸缩=>**自增字段+数据库seq+步长step**）：缺陷在于服务节点固定（即**step固定**，继续增加服务节点难以进行扩展）、仍强依赖于数据库（对**数据库造成压力**）
开源项目-Snowflake
Twitter开源的发号器，缺点在于文档简单、发布模式单一、缺少支持和维护
=>自研：一款通用、高性能发号器产品，具有“全局唯一、粗略有序、可反解、可制造”特性，三种发布模式“嵌入发布模式(jar包)、中心服务器发布模式(服务化场景)、REST发布模式(rest api接口)”
二、基本需求
**全局唯一**：一般悲观策略是使用锁或分布式锁（性能大大降低），而这里将利用**时间的有序性**，在时间的某个单元下采用自增序列达到全局唯一
**粗略有序**：完全有序则涉及到数据的汇聚，需要用到锁或分布式锁，考虑到效率问题采用折中方案即粗略有序，将支持秒级有序和毫秒级有序两种方式
**可反解**：ID具有时间属性且可反解其他信息量，节省空间
**可制造**：即支持手工处理，可复制、可恢复、可制造
**高性能**：ID生成取决于网络I/O和CPU的性能，网络I/O一般不是瓶颈，根据经验单台机器TPS能达到10000/s
**高可用**：对等集群、重试机制、本地容错方案（即本地依赖）
**可伸缩**：水平伸缩，支持业务量增长
三、核心设计
发布模式
嵌入发布模式：仅限java客户端，通过嵌入jar包式的原生服务，需提前配置本地机器ID
中心服务器发布模式：仅限java客户端，提供一个服务的客户端jar包，java程序像调用本地api一样调用，但依赖于中心的ID产生服务器
REST发布模式：中心服务器通过Restful API导出服务，非java客户端可使用
ID类型
最大峰值型：秒级有序，秒级时间占用30位，序列号占用20位
| 字段 | 版本 | 类型 | 生成方式 | 秒级时间 | 序列号 | 机器ID |
|---|---|---|---|---|---|---|
| 位数 | 63 | 62 | 60-61 | 30-59 | 10-29 | 0-9 |
最小粒度型：秒级有序，秒级时间占用40位，序列号占用10位
| 字段 | 版本 | 类型 | 生成方式 | 秒级时间 | 序列号 | 机器ID |
|---|---|---|---|---|---|---|
| 位数 | 63 | 62 | 60-61 | 20-59 | 10-19 | 0-9 |
数据结构
版本：1位，用做扩展位或扩容时的临时方案，默认值0，1则表示扩展或扩容中
ID类型：1位，0-最大峰值型，1-最小粒度型
生成方式：2位，00-嵌入发布模式，01-中心发布模式，02（即二进制10）-REST发布模式，03（即二进制11）-保留未用
时间：最大峰值型-秒级时间30位，2^30/60/60/24/365=34年；最小粒度型-毫秒级时间40位，2^40/1000/60/60/24/365=34年
序列号：最大峰值型20位，理论上每秒可最多产生2^20=1048576个ID，即百万级别；最小粒度型10位，理论上每毫秒最多可产生2^10=1024个ID，=>最大1024000/秒
机器ID：10位，即最多支持1024个服务器，中心发布模式和REST发布模式一般不会有太多数量机器，按照设计每台TPS为1万/s，10台服务器则可达到10万/s，已经可以满足绝大部分需求；而考虑到内嵌发布模式，对机器需求量很大，因此最多支持1024个服务器
并发
中心服务器和REST发布模式，开销主要涉及网络I/O和CPU操作，ID生成基本上是内存到高速缓存操作，没有磁盘I/O操作，网络I/O是系统瓶颈；但相对于网络I/O，CPU计算速度更是瓶颈，因此ID产生的服务采用多线程方式
多种实现方式，实现ID生成过程中的竞争点time和sequence：
（1）使用concurrent包的ReentrantLock进行互斥，默认实现方式，追求性能和稳定的折中方案
（2）使用传统的synchronized进行互斥，性能较（1）稍逊色一些，通过传入JVM参数-Dvesta.sync.lock.impl.key=true开启
（3）使用concurrent包的原子变量进行互斥，性能非常高，但是高并发环境下CPU负载会很高，通过传入JVM参数-Dvesta.atomic.lock.impl.key=true开启
机器ID的分配
0-923：嵌入发布模式，预先配置机器ID，最多支持924台内嵌服务器
924-1023：中心服务器发布模式和REST发布模式，最多支持100台，最大支持100*1万/s即100万/s的TPS
=>可以动态调整两个区间的值来适应，当然各个垂直业务具有天生的隔离性，每个业务都可以适应最多1024台服务器的
=>3种机器ID的分配方式：共享数据库方式、IP方式、Spring配置文件方式(测试时使用)
时间同步
crontab，周期性地通过时间服务器虚拟集群核准服务器时间：ntpdate -u pool.ntp.orgpool.ntp.org
未重启机器调慢时间，Vesta抛出异常拒绝产生ID;重启机器调快时间，调整后正常产生ID；重启机器调慢时间，可能会产生重复的ID，系统管理员需要保证避免这种情况；每4年一次同步闰秒，由于是调快1秒，因此调整后不影响ID的产生
设计验证
（1）根据不同信息分段构建一个ID，且ID全局唯一、可反解、可制造等
（2）使用秒级时间或毫秒级时间及时间单元内序列递增的方法保证ID粗略有序
（3）多线程处理中心服务器发布模式和REST发布模式，三种实现方式解决竞争点的互斥
（4）保证发布模式的最大可用，即某种模式不可用，可以回退到使用本地预配的机器ID
（5）机器号分两个区段，一个从0开始向上，一个从1024开始向下，并且能够动态调整分界线，满足可伸缩性
四、代码实现
代理模式
【读书系列】
《可伸缩服务架构：框架与中间件》，李艳鹏、杨彪、李海亮、贾博岩、刘淏，电子工业出版社