[发号器]分布式发号器实现方案，UUID，数据库，snowfla

概要

分布式 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产生，但是没有影响。