概要
分布式 or 微服务架构中，需要产生唯一的编号的服务叫做发号器
需求：
- 全局唯一（悲观策略使用分布式锁，但是会降低性能）
- 粗略有序（完全有序更好，但是用锁会导致性能太差）
- 可反解，便于获取信息差错
- 可制造，便于数据清洗
- 高性能
- 高可用
- 可伸缩
注意：id不要和token之类的乱序编码混淆，虽然很多场景下他们是一一对应关系，但是id需要可以制造，可以反解，不需要保密性很好，和token的设计初衷是完全相悖
已有方案对比
方案一：UUID
弊端：
没有时间粗略有序
不可反解
不可制造
性能差/长/占用空间
UUID无序，所以数据库存储，导致B+树索引在写的时候过多随机操作
方案二：利用数据库的自增ID
弊端：
数据库移植，扩容，清洗，分库分表都有诸多困难
方案三： twitter开源snowflake
scala语言实现，但是支持和维护较少。
开源项目vesta设计
鉴于前面三个方案都有各自缺陷。本文介绍java的开源项目vesta
- 设计ID为64位，通过分配不同“位”来组合成一个全局编号
例如（0-63位）：
| 位数 | 63 | 62 | 60-61 | 30-59 | 10-29 | 0-9 |
|---|---|---|---|---|---|---|
| 含义 | 版本 | 类型 | 生成方式 | 秒级时间 | 序列号 | 机器ID |
其中：
- 版本，类型，生成方式都是配置字段，预留给配置，升级。
- 秒级时间|序列号|机器ID是 生成的核心逻辑字段。
- 时间字段预留30位，2^30／(60 * 60 * 24 * 356) = 34，也就是说时间序位34年后消耗完。
- 机器ID十位，也就是2^10 = 1024，机器最大支持1024台，完全够用的。
架构设计：
-
image.png
-
注意事项
1 ID的生成在内存中（不依赖数据库的方案），所以网络IO是系统性能瓶颈，相对于网络io而言，CPU的计算是性能瓶颈，但是CPU计算采用多线程的方式。
2 时间同步
- 运行发号器的服务，要保证时间的正确性。
ntpdate -u 210.72.145.44
-u：从man ntpdate中可以看出-u参数可以越过防火墙与主机同步；
210.72.145.44：中国国家授时中心的官方服务器。
其他可用中心服务器如下： https://www.cnblogs.com/luchuangao/p/7795293.html
- 每4年原子时钟和电子时钟会有1秒进行同步，使用ntpdate会调快一秒，1s时间内没有id产生，但是没有影响。
网友评论