分布式ID生成总结

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冲突，或者ID乱序、ID重复

优势：

• 生成ID时不依赖于数据库，彻底在内存生成，高性能高可用
• 容量大，每秒可生成几百万ID
• ID呈趋势递增，后续插入数据库的索引树的时候，性能较高