数据库主键自增序列_分布式数据库唯一ID生成方式

分布式系统中我们会对一些数据量大的业务进行分拆，如：用户表，订单表。因为数据量巨大一张表无法承接，就会对其进行分库分表。

但一旦涉及到分库分表，就会引申出分布式系统中唯一主键ID的生成问题，永不迁移数据和避免热点的文章中要求需要唯一ID的特性：

• 整个系统ID唯一
• ID是数字类型，而且是趋势递增的
• ID简短，查询效率快

什么是递增？如：第一次生成的ID为12，下一次生成的ID是13，再下一次生成的ID是14。这个就是生成ID递增。

什么是趋势递增？如：在一段时间内，生成的ID是递增的趋势。如：再一段时间内生成的ID在【0，1000】之间，过段时间生成的ID在【1000，2000】之间。但在【0-1000】区间内的时候，ID生成有可能第一次是12，第二次是10，第三次是14。

1.数据库自增ID

新建一个公共库，库里面新建一个序列表，主键id自增，每次请求增加数据都往这个表中插入数据，然后获取到id，然后使用即可。

优点：方便简单

缺点：单库生成自增id，高并发下，会有瓶颈

适用场景：

并发很低，几百/s，不会出现性能瓶颈

2.UUID

优点：本地生成，不基于任何第三方

缺点：

• 太长，作为数据库主键性能太差，不适合作为主键
• 不具有有序性，会导致B+树索引在写的时候有过多的随机写操作(连续的id可以产生部分顺序写)
• 写的时候不能产生有顺序的 append 操作，而需要进行 insert 操作，将会读取整个 B+ 树节点到内存，在插入这条记录后会将整个节点写回磁盘，这种操作在记录占用空间比较大的情况下，性能下降明显

适用场景：

随机生成文件名、编号，生成token等。

3.系统时间+拼接业务字段值

例如：当前时间戳 + 用户id + 业务含义编码，并发高的时候，会有重复，此时就不行了，不建议使用。

4.Redis

Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。

优点：

• 不依赖于数据库，灵活方便，且性能优于数据库。
• 数字ID天然排序，对分页或者需要排序的结果很有帮助。

缺点：

• 由于redis是内存的KV数据库，即使有AOF和RDB，但是依然会存在数据丢失，有可能会造成ID重复。
• 依赖于redis，redis要是不稳定，会影响ID生成。

5.雪花snowflake算法

twitter开源的分布式id生成算法，把一个64位的long型的id，1个bit是不用的，用其中的41 bit作为毫秒数，用10 bit作为工作机器id，12 bit作为序列号，理论上最多支持1024台机器每秒生成4096000个序列号。

• 1 bit：不用
  因为二进制里第一个bit为如果是1，那么都是负数，但是我们生成的id都是正数，所以第一个bit统一都是0
• 41 bit：表示的是时间戳，单位是ms
  41 bit可以表示的数字多达2^41 - 1，也就是可以标识2 ^ 41 - 1个毫秒值，换算成年就是表示69年的时间
• 10 bit：记录工作机器id
  代表的是这个服务最多可以部署在2^10台机器上哪，也就是1024台机器，但是10 bit里5个bit代表机房id，5个bit代表机器id。意思就是最多代表2 ^ 5个机房(32个机房)，每个机房里可以代表2 ^ 5个机器(32台机器)。
• 12 bit：记录同一个毫秒内产生的不同id
  12 bit可以代表的最大正整数是2 ^ 12 - 1 = 4096，也就是说可以用这个12bit代表的数字来区分同一个毫秒内的4096个不同的id

缺点：

• 依赖机器的时钟，如果服务器时钟回拨，会导致重复ID生成

优点：

• 此方案每秒能够产生409.6万个ID，性能快
• 时间戳在高位，自增序列在低位，整个ID是趋势递增的，按照时间有序递增
• 灵活度高，可以根据业务需求，调整bit位的划分，满足不同的需求