☃️前言
ID 生成器在微博我们一直叫发号器，微博就是用这样的号来存储，而我微博里讨论的时候也都是以发号器为标签。它的主要目的确如平常大家理解的“为一个分布式系统的数据object产生一个唯一的标识”，但其实在一个真实的系统里可能也可以承担更多的作用。
概括起来主要有以下几点：
- 唯一性
- 时间相关
- 粗略有序
- 可反解
- 可制造
下面我会分别讲每个作用后面的考虑和权衡，也会对比介绍一下业界已知的几种 ID 设计。
- 要唯一性，是否需要全局唯一？
说起全局唯一，通常大家都会在想到发号器服务，分布式的通常需要更大空间，中心式的则需要在一个合适的地方在会聚。这就可能涉及到锁，而锁意味着成本和性能的下降。所以当前的系统是否需要全局的唯一性，就是一个需要考虑的问题。
比如在通讯系统里，聊天消息可能就未必需要全局，因为一条消息只是某一个人发出，系统只要保证一个人维度的唯一性即可。本质上而言，这里利用了用户 ID 的唯一性，因为唯一性是可以依赖的，通常我们设计系统也都是基于类似的性质，比如后面降到的使用时间唯一性的方式。 - 用时间来做什么？千万年太久，只争朝夕？
前面说到唯一性可以依赖，我们需要选择的是依赖什么。通常的做法可以选择数据库自增，这在很多数据库里都是可以满足ACID 的操作。但是用数据库有个缺点，就是数据库有性能问题，在多机房情况下也很难处理。当然，你可以通过调整自增的步长来设计，但对于一个发号器而言，操作和维护都略重了。
而时间是天然唯一的，因此也是很多设计的选择。但对于一个8Byte的 ID 而言，时间并没有那么多。你如果精确到秒级别，三十年都要使用30bit，到毫秒级则要再增加10bit，你也只剩下20bit 可以做其他事情了。之所以在8Byte 上捣鼓，因为8Byte 是一个Long，不管在处理器和编译器还是语言层面，都是可以更好地被处理。
然而三十年够么？对于一个人来说，可能不够，但对一个系统而言，可能足够。我们经常开玩笑，互联网里能活三十年的系统有多少呢？三十年过去，你的系统可能都被重写 N 遍了。这样的信心同样来自于摩尔定律，三十年后，计算性能早就提高了上千倍，到时候更多Byte 都不会是问题了。 - 粗略有多粗略，秒还是毫秒？
每秒一个或者每毫秒一个ID明显是不够的，刚才说到还有20bit 可以做其他事情，就包括一个SequenceID。如果要达到精确的有序，就要对 Sequence 进行并发控制，性能上肯定会打折。所以经常会有的一个选择就是，在这个秒的级别上不再保证顺序，而整个 ID 则只保证时间上的有序。后一秒的 ID肯定比前一秒的大，但同一秒内可能后取的ID比前面的号小。这在使用时非常关键，你要理解，系统也要接受才可以。
那时间用秒还是毫秒呢？其实不用毫秒的时候就可以把空出来的10bit 送给 Sequence，但整个ID 的精度就下降了。峰值速度是更现实的考虑。Sequence 的空间决定了峰值的速度，而峰值也就意味着持续的时间不会太久。这方面，每秒100万比每毫秒1000限制更小。 - 可反解，解开的是什么？
一个 ID 生成之后，就会伴随着信息终身，排错分析的时候，我们需要查验。这时候一个可反解的 ID 可以帮上很多忙，从哪里来的，什么时候出生的。跟身份证倒有点儿相通了，其实身份证就是一个典型的分布式 ID 生成器。
如果ID 里已经有了时间而且能解开，在存储层面可能不再需要timestamp 一类的字段了。微博的 ID 还有很多业务信息，这个后面会细讲。 - 可制造，为什么不用UUID？
互联网系统上可用性永远是优先指标。但由于分布式系统的脆弱，网络不稳定或者底层存储系统的不可用，业务系统随时面临着失败。为了给前端更友好的响应，我们需要能尽量容忍失败。比如在存储失败时，可能需要临时导出请求供后续处理，而后续处理时已经离开了当时的时间点，顺序跟其他系统错开了。我们需要制造出这样的ID 以便系统好像一直正常运行一样，可制造的 ID 让你可以控制生产日期（汗，有点儿假冒伪劣的意思了），然后继续下面的处理。
另一个重要场景就是数据清洗。这个属于较少遇到，但并不罕见的情况，可能是原来 ID 设计的不合理，也可能由于底层存储的改变，都可能出现。这样一个可制造的 ID 就会带来很多操作层面的便利。
这也是我们不用 UUID 的一个原因。UUID 标准可以保证在某时某地生成，但如果要控制生成一个特定时间的 UUID，可能需要底层库的改动。经验告诉我们，能在上层解决的问题不要透到下层，这种库的维护成本是非常高的。
设计细节UUID 就不说了， 其他公开出来的这里说下SnowFlake、Weibo以及 Ticktick 的设计。 - SnowFlake41bit留给毫秒时间，10bit给MachineID，也就是机器要预先配置，剩下12位留给Sequence。代码虽然露出来了，但其实已经不可用了，据说是内部改造中。
- Weibo微博使用了秒级的时间，用了30bit，Sequence 用了15位，理论上可以搞定3.2w/s的速度。用4bit来区分IDC，也就是可以支持16个 IDC，对于核心机房来说够了。剩下的有2bit 用来区分业务，由于当前发号服务是机房中心式的，1bit 来区分热备。是的，也没有用满64bit。
- Ticktick也就是当前在环信系统里要用到的。使用了30bit 的秒级时间，20bit 给Sequence。这里是有个考虑，第一版实现还是希望到毫秒级，所以20bit 的前10bit给了毫秒来用，剩下10bit给 Sequence。等到峰值提高的时候可以暂时回到秒级。
前面说到的三十年问题，因此我在高位留了2bit 做 Version，或者到时候改造使用更长字节数，用第一位来标识不同 ID，或者可以把这2bit 挪给时间用，可以给系统改造留出一定的时间。
剩下的10bit 留给 MachineID，也就是说当前 ID 生成可以直接内嵌在业务服务中，最多支持千级别的服务器数量。最后有2bit 做Tag 用，可能区分群消息和单聊消息。同时你也看出，这个 ID 最多支持一天10亿消息，也是怕系统增速太快，这2bit 可以挪给 Sequence，可以支持40亿级别消息量，或者结合前面的版本支持到百亿级别。
☃️实战
另外表如果使用数据库自增ID就存在一些问题：
- id的规律性太明显
- 受单表数据量的限制
场景分析一：如果我们的id具有太明显的规则，用户或者说商业对手很容易猜测出来我们的一些敏感信息，比如商城在一天时间内，卖出了多少单，这明显不合适。
场景分析二：随着我们商城规模越来越大，mysql 的单表的容量不宜超过500W，数据量过大之后，我们要进行拆库拆表，但拆分表了之后，他们从逻辑上讲他们是同一张表，所以他们的id是不能一样的， 于是乎我们需要保证id的唯一性。
全局ID生成器，是一种在分布式系统下用来生成 全局唯一 ID的工具，一般要满足下列特性：
为了增加ID的安全性，我们可以不直接使用Redis自增的数值，而是拼接一些其它信息：
成部分：符号位：1bit，永远为0
时间戳：31bit，以秒为单位，可以使用69年
序列号：32bit，秒内的计数器，支持每秒产生2^32个不同ID
redis 实现全局唯一 id:
@Component public class RedisIdWorker { /** * 开始时间戳 */ private static final long BEGIN_TIMESTAMP = 1640995200L; /** * 序列号的位数 */ private static final int COUNT_BITS = 32; private StringRedisTemplate stringRedisTemplate; public RedisIdWorker(StringRedisTemplate stringRedisTemplate) { this.stringRedisTemplate = stringRedisTemplate; } public long nextId(String keyPrefix) { // 1.生成时间戳 LocalDateTime now = LocalDateTime.now(); // 得到当前的秒数 long nowSecond = now.toEpochSecond(ZoneOffset.UTC); long timestamp = nowSecond - BEGIN_TIMESTAMP; // 2.生成序列号 // 2.1.获取当前日期，精确到天 String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd")); // 2.2.自增长 （每天一个key） long count = stringRedisTemplate.opsForValue().increment("icr:" + keyPrefix + ":" + date); // 3.拼接并返回 return timestamp << COUNT_BITS | count; } }
除了 redis 之外，还有 UUID 、雪花算法 等方式可以生成全局唯一 id。
