在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。

业务系统对ID号的要求：

  1. 全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。
  2. 趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
  3. 单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。
  4. 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可
UUID

UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000

优点：性能非常高：本地生成，没有网络消耗。

缺点：

  • 不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。
  • 信息不安全
  • ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用：ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用：
类snowflake方案

这种方案把64-bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64-bit分别表示如下图（图片来自网络）所示：

id 策略生成类_数据库


41-bit的时间可以表示（1L<<41）/(1000L360024*365)=69年的时间，10-bit机器可以分别表示1024台机器。如果我们对IDC划分有需求，还可以将10-bit分5-bit给IDC，分5-bit给工作机器。这样就可以表示32个IDC，每个IDC下可以有32台机器，可以根据自身需求定义。12个自增序列号可以表示2^12个ID，理论上snowflake方案的QPS约为409.6w/s，这种分配方式可以保证在任何一个IDC的任何一台机器在任意毫秒内生成的ID都是不同的。

优点：

  • 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
  • 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
  • 可以根据自身业务特性分配bit位，非常灵活。

缺点：

  • 强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。
数据库生成

Leaf-segment数据库方案

利用proxy server（缓存服务或者代理服务）批量获取，每次获取一个segment(step决定大小)号段的值。

用完之后再去数据库获取新的号段，可以大大的减轻数据库的压力。

各个业务不同的发号需求用biz_tag字段来区分，每个biz-tag的ID获取相互隔离，互不影响。如果以后有性能需求需要对数据库扩容，不需要上述描述的复杂的扩容操作，只需要对biz_tag分库分表就行。

数据库表设计如下：

id 策略生成类_回拨_02


重要字段说明：

  • biz_tag用来区分业务，max_id表示该biz_tag目前所被分配的ID号段的最大值，step表示每次分配的号段长度。
  • 原来获取ID每次都需要写数据库，现在只需要把step设置得足够大，比如1000。那么只有当1000个号被消耗完了之后才会去重新读写一次数据库。读写数据库的频率从1减小到了1/step

id 策略生成类_id 策略生成类_03


test_tag在第一台Leaf机器上是1-1000的号段，当这个号段用完时，会去加载另一个长度为step=1000的号段，假设另外两台号段都没有更新，这个时候第一台机器新加载的号段就应该是3001~4000。同时数据库对应的biz_tag这条数据的max_id会从3000被更新成4000，更新号段的SQL语句如下：

Begin
UPDATE table SET max_id=max_id+step WHERE biz_tag=xxx
SELECT tag, max_id, step FROM table WHERE biz_tag=xxx
Commit

这种模式有以下优缺点：

优点：

  • Leaf服务可以很方便的线性扩展，性能完全能够支撑大多数业务场景。
  • 容灾性高：Leaf服务内部有号段缓存，即使DB宕机，短时间内Leaf仍能正常对外提供服务。

缺点：

  • ID号码不够随机，能够泄露发号数量的信息，不太安全。
  • DB宕机会造成整个系统不可用。
  • Leaf 取号段的时机是在号段消耗完的时候进行的，也就意味着号段临界点的ID下发时间取决于下一次从DB取回号段的时间，并且在这期间进来的请求也会因为DB号段没有取回来，导致线程阻塞
双buffer优化

对于第三个缺点，可以采用双buffer策略优化。

采用双buffer的方式，Leaf服务内部有两个号段缓存区segment。当前号段已下发10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复。

  • 每个biz-tag都有消费速度监控，通常推荐segment长度设置为服务高峰期发号QPS的600倍（10分钟），这样即使DB宕机，Leaf仍能持续发号10-20分钟不受影响。
  • 每次请求来临时都会判断下个号段的状态，从而更新此号段，所以偶尔的网络抖动不会影响下个号段的更新。

常见问题

雪花ID时钟回拨问题？

NTP即Network Time Protocol（网络时间协议），是一个互联网协议，用于同步计算机之间的系统时钟。

1、如果系统开了NTP网络对时协议的话，系统时间是有可能回退的，这会导致雪花算法生成的ID重复。所以一般系统会关闭NTP对时协议。Linux命令如下：

timedatectl set-ntp true／false

但即使关闭了NTP对时协议，也可能遇到时间回退的情况，比如说闰秒。遇到这种情况，可以通过设置一到两位时间回拨位的方式解决。（改造雪花算法）

参考：雪花算法时钟回拨

2、时间回拨的问题Sonyflake简单暴力，就是直接等待

参考：Sonyflake