今天咱们来聊聊分布式数据库中一个基础但又关键的问题，那就是如何生成数据表的记录 ID 。
当数据量越来越大，并发量越来越高，传统的单库单表遇到性能瓶颈时，我们自然会想到分库分表。利用分库分表虽能分摊压力，但在享受性能提升的同时，也会遇到很多问题，比如多表查询、分布式事务等等，这些咱们在前几期重点聊过。本期重点说一说分布式数据库中数据表记录 ID 的生成方案。
对于传统的单库单表，利用数据库的自增字段很容易搞定。但在多库多表的情况下就不同了，简单利用数据库自增会出现大面积的 ID 重复，比如 a 表 123，b 表也是 123，这显然行不通。
我们可以基于数据库的自增 ID 做改造，比如 a 表 135，b 表 246，这样能轻松解决问题。不过这个方案依赖数据库的自增属性，无需额外侵入代码，但不足的是在扩容时，因为加入新表，自增 ID 需要重新分配，比较麻烦。比较好的方式是根据业务量多建表，可以扛个三四年，业务大了再重构，问题也不大。
基于数据库自增策略的还有 Redis，其性能不错。虽然有同学担心 Redis 会挂，但即使挂了，通过持久化的 AOF 机制也能恢复，所以这个方案也是可行的，原理跟数据库自增 ID 有点类似。
其实分布式 ID 公认的方案是采用雪花算法，大名鼎鼎，应用广泛。它的核心由三部分组成：一个是代表当前时间的时间戳，一个是代表生成 ID 机器的机器码，还有一个是递增的序列号。同一机器同一毫秒，序列号连续，机器码放在内存里，同一毫秒按部就班递增就行，下一毫秒再重新计算。原理比较简单，但雪花算法可能会在时间戳上出问题，如果改动服务器时间，可能会引发一系列问题，导致生成重复 ID，也就是常说的时间回拨问题。不过这种情况很少，服务器时间一般不会轻易动，即便要动，也建议在维护期内调整。
雪花算法是一种 ID 生成策略，实际开发中建议不要照搬官方的，因为生成的 ID 比较长，有 64 位，而我们真实的机器没那么多的情况，并发量也不可能那么大，所以还是建议大家根据实际情况做适当缩减。
好了，本期关于分布式数据库 ID 生成方案的内容就到这里啦，如果您对本期内容有任何疑问，欢迎在评论区给我留言，谢谢大家！
