在分布式环境下生成数据库主键是一件比较麻烦的事情，这里简单总结下，以供以后使用。
数据库自增长序列或字段
每个服务器使用自增主键，不同服务器的步长不一样，比如 A 服务器生成 1，3，5，7... B 服务器生成 2，4，6，8...。
缺点：难以扩展。合并数据库时非常麻烦。分库分表时难以处理。
UUID
常见的方式。可以利用数据库也可以利用程序生成，一般来说全球唯一。
缺点：没有排序，无法保证趋势递增。查询效率比较低。存储量比较大。不可读。
Redis 生成 ID
使用 Redis 的原子性生成自增主键（INCR 和 INCRBY 来实现）。
缺点：需要引入 Redis，系统复杂度增加
Twitter 的 snowflake 算法
snowflake的结构如下(每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
第一位为未使用，接下来的41位为毫秒级时间(41位的长度可以使用69年)，然后是5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点） ，最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）
一共加起来刚好64位，为一个Long型。(转换成字符串后长度最多19)
snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。经测试snowflake每秒能够产生26万个ID。
缺点：占用空间很大，不可读