a.分布式ID起源

随着项目的数据原来越大，DB部署在一台服务器上是无法处理后面数据量到达千万级别以上的情况出现，所以需要分布式ID的出现来处理之后数据库分库分表的处理情况

b.为何不选他们为分布式ID的方案

1.【原来】数据库自增 id

问题：单库生成自增 id，要是高并发的话，就会有瓶颈的

如果你硬是要改进一下，那么就专门开一个服务出来，这个服务每次就拿到当前 id 最大值，然后自己递增几个 id，一次性返回一批 id，然后再把当前最大 id 值修改成递增几个 id 之后的一个值；但是无论如何都是基于单个数据库。

2.UUID

问题：UUID 太长了、占用空间大，作为主键性能太差了

UUID更重要的是，UUID 不具有有序性，会导致 B+ 树索引在写的时候有过多的随机写操作（连续的 ID 可以产生部分顺序写），还有由于在写的时候不能产生有顺序的 append 操作，而需要进行 insert 操作，将会读取整个 B+ 树节点到内存，在插入这条记录后会将整个节点写回磁盘，这种操作在记录占用空间比较大的情况下，性能下降明显。

3.获取系统当前时间

问题：这个就是获取当前时间即可，但并发很高的时候，比如一秒并发几千，会有重复的情况，这个是肯定不合适的

4.twitter的snowflake算法

这里开始进入生产环节分析具体的

截取资料