分布式ID生成器

前言

最近想自己尝试从头做一个短域名系统，短域名系统中比较关键一环的技术就是一个较长的网址会有一到多个唯一ID去标识，最终达到短域名的效果。

如果是以实际情况来说，流量不大的话这个很容易实现效果，无论是数据库的自增ID还是利用Redis这种单机的发号，都可以解决问题。但是如果自己玩还这样做的话，那就很没意思了，所以，我会意淫一个较大的流量场景，然后不断调整方案解决思路直到达到满足假设流量场景的要求为止(意味着解决思路如果被打脸后还会回来更新这篇博客，hhhhhhhh)。

常见的ID生成

一般来说，数据库的自增ID是我们最常用的，又或者是使用Redis的incr去自增得到一个递增的唯一序号。在一般情况下这都是够用的。但如果有一天，访问的量级超出了单机的承受范围，我们需要扩容时，这些单机的自增ID基本上是没办法很好的水平扩容。

针对这种情况，在之前在美团技术团队分享的一篇文章中看到过一种方式，Redis同样也可以应用该思路，比如分布式下的MySQL自增ID，通过调整每台MySQL的增长步长来解决，其中增长步长和MySQL的机器数量相等，比如有两台MySQL机器，那么设置第一台MySQL的初始值为1，接下来的自增结果是:1，3，5，7，9...，第二台MySQL机器的初始值设置为2，接下来的自增结果是:2，4，6，8，10...。

这样虽然能很好的解决多台MySQL的ID自增问题，但是水平扩容却很麻烦，当你往里面新增一台机器的时候，新机器的初始值设置会变得很困难，需要很多额外的处理。比如最开始只有一台机器，按照上面的逻辑来说，会得到:1，2，3，4，5...这样往后的递增。但当新添一个机器时，机器总数变了，步长也会改变，所以如果没有任何处理直接添加第二台机器，就会得到:2，4，6，8，10...往后的递增，是不是发现其中序号4在没加机器前已经生成过了，这样会导很多致重复。

我的思路

我的这个思路不一定正确，只是我自己思考的一个尝试，所以，如果解决思路有问题请用力打我的脸。

一个理想的ID生成服务，每个服务都是无状态，互相没有依赖和通信，并且每个节点都可以生成全局唯一的ID，这样一来扩容起来就只需要考虑堆机器，而不用考虑任何其它因素。

而对于全局唯一的ID生成，则可以考虑snowflake的方案，该方案利用系统时间去递增ID，不依赖任何存储系统，该ID的结构如下:

这个唯一ID的构成不依赖其它任何系统如MySQL、Redis等，只依赖系统的时间，可以说天然无状态。除了ID是顺序递增外(对有些业务来说，顺序递增的ID不太友好)，对于我想要构建的无状态ID生成服务，是很好的选择。

但是如果依赖时间去构造ID，就还需要解决一个问题，就是系统时间的回退。比如在系统NTP同步时间的时候，系统时间就可能会出现短暂的回退，这对于依赖系统时间生成ID的服务来说，就意味着生成的ID可能会重复，这是不能接受的。

而对于时间回退的解决方式，网上的解决方案非常多，但是实现起来都比较复杂，所以我选择改动一下snowflake的结构，换种方式解决一下，我的结构如下:

其中，时间戳部分改为由程序自己在内存中维护的自增值，并且最后10bit留给机器作为编号来确保ID的唯一。而如何确保这部分自增序号不回退，就可以沿用一下微信团队分享的一个简单的处理思路。

如果我们能够接受序号不是连续递增的，回退这个问题就很好解决，比如现在生成的ID是1、2、3，可能后面就会变成4、10、11、12这样。而具体实现的逻辑则是，内存中维护一个自增序号和一个自增序号的上限(max seq)，获取自增序号时先检查当前序号+1是否>=自增序号上限，如果>=自增序号上限，则将这个自增序号上限扩大:自增序号上限(max seq)+=扩大步长(step)，然后持久化这个值到磁盘文件中，下次重新启动时则从该文件中获取到该自增序号上限并同时赋值给当前程序维护的自增序号。

最后也顺便分享一个我的原型实现:
ZhiyangLeeCN/SeqSrv

参考

Leaf——美团点评分布式ID生成系统
万亿级调用系统：微信序列号生成器架构设计及演变