业务系统到底需要什么样的ID生成器

ID 生成器在微博我们一直叫发号器，微博就是用这样的号来存储，而我微博里讨论的时候也都是以发号器为标签。它的主要目的确如平常大家理解的“为一个分布式系统的数据object产生一个唯一的标识”，但其实在一个真实的系统里可能也可以承担更多的作用。概括起来主要有以下几点：

1. 唯一性
2. 时间相关
3. 粗略有序
4. 可反解
5. 可制造

下面我会分别讲每个作用后面的考虑和权衡，也会对比介绍一下业界已知的几种 ID 设计。

1. 要唯一性，是否需要全局唯一？

   说起全局唯一，通常大家都会在想到发号器服务，分布式的通常需要更大空间，中心式的则需要在一个合适的地方在会聚。这就可能涉及到锁，而锁意味着成本和性能的下降。所以当前的系统是否需要全局的唯一性，就是一个需要考虑的问题。

   比如在通讯系统里，聊天消息可能就未必需要全局，因为一条消息只是某一个人发出，系统只要保证一个人维度的唯一性即可。本质上而言，这里利用了用户 ID 的唯一性，因为唯一性是可以依赖的，通常我们设计系统也都是基于类似的性质，比如后面降到的使用时间唯一性的方式。

2. 用时间来做什么？千万年太久，只争朝夕？

   前面说到唯一性可以依赖，我们需要选择的是依赖什么。通常的做法可以选择数据库自增，这在很多数据库里都是可以满足ACID 的操作。但是用数据库有个缺点，就是数据库有性能问题，在多机房情况下也很难处理。当然，你可以通过调整自增的步长来设计，但对于一个发号器而言，操作和维护都略重了。

   而时间是天然唯一的，因此也是很多设计的选择。但对于一个8Byte的 ID 而言，时间并没有那么多。你如果精确到秒级别，三十年都要使用30bit，到毫秒级则要再增加10bit，你也只剩下20bit 可以做其他事情了。之所以在8Byte 上捣鼓，因为8Byte 是一个Long，不管在处理器和编译器还是语言层面，都是可以更好地被处理。

   然而三十年够么？对于一个人来说，可能不够，但对一个系统而言，可能足够。我们经常开玩笑，互联网里能活三十年的系统有多少呢？三十年过去，你的系统可能都被重写 N 遍了。这样的信心同样来自于摩尔定律，三十年后，计算性能早就提高了上千倍，到时候更多Byte 都不会是问题了。

3. 粗略有多粗略，秒还是毫秒？

4.  余下全文请点击这里查看