分布式全局唯一ID

方案一、UUID

UUID的方式能生成一串唯一随机32位长度数据，它是无序的一串数据，按照开放软件基金会(OSF)制定的标准计算，UUID的生成用到了以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字。UUID的底层是由一组32位数的16进制数字构成。

优点：实现简单，全局唯一，不需要考虑冲突的问题，适合标示用户的场景。

缺点：UUID长度过程，mysql建议主键字段长度越短越好，而且UUID包含MAC地址信息，有可能会造成MAC地址泄露。UUID由于是无序的，所以插入性能不是很好，适合写频率较低的场景，因为在数据库设计中，主键一般都是聚集索引，而索引一般是B+树，B+对于有序的插入是分裂追加节点，而对于无序节点的插入，需要移动后续所有节点，性能表现较差。

方案二、自增主键

这个方案就是利用了MySQL的主键自增auto_increment，默认每次ID加n。在分布式的情况下，需要设置每个库的初始值和步长，避免主键冲突。

优点：递增主键，读写效率高，具有一定的业务可读性。

缺点：步长一旦设置，后期无法扩容。

方案三、雪花snowflake算法

雪花算法生成64位的二进制正整数，然后转换成10进制的数。64位二进制数由如下部分组成：

优点：整个ID有序递增，此方案每秒能够产生409.6万个ID，性能好、

缺点：依赖机器的时钟同步，如果出现时钟回调，有可能会主键重复。

方案四：Redis生产方案

利用redis的incr原子性操作自增来生产ID，一般算法为：年份 + 天数 + 小时 + redis自增

优点：ID递增，可读性强。

缺点：需要多发一次网络请求，对性能要求不高的可以考虑。

方案五：Sequence特性

这个特性在SQL Server 2012、Oracle中可用。这个特性是数据库级别的，允许在多个表之间共享序列号。

优点：没什么明显的优点

缺点：只能在SQL Server、Oracle使用

方案五：通过数据库集群编号+集群内的自增类型两个字段共同组成唯一主键

优点：实现简单，维护简单

缺点：需要业务逻辑处理复合主键，且该方法只能一开始就使用，不能从别的方案切换过来。

待续……