Mysql自增ID

利用数据的主键自增长策略，对ID进行自增。

优点：对于分页操作和索引有很大的优势，能生成有序的自增ID
缺点：不利于数据库的扩容，一旦发生扩容就需要重新设置步长

解决办法：如果存在多个master，可以让每个master的起始id不同，每个master的步长一致，比如有三个master，第一个master生成的id为：1，4，7，10，第二个master生成的id为：2，5，8，11，第三个master生成的id为：3，6，9，12。

UUID

uuid是全球唯一标识，由32个16进制数构成，长度为16字节（64bit）。

优点：不依赖于网络就能得到全局唯一id，生成器性能很好
缺点：无序，不可读，占用空间过大（一般用于生成token）

解决办法：

  1. 对于无序性，我们可以采用NHibernate的Comb算法进行改进，保留生成的UUID的前10个字节，把后6个字节替换为时间。这样通过UUID的最后12个十六进制数就可以比较出UUID的生成顺序。
  2. 对于不可读，我们可以把UUID转换为Int64

Redis

由于redis是单线程的，所以可以使用它的INCR或INCRBY来生成全局唯一的自增ID。redis一般3-5台就能满足要求。我们可以通过哈希映射把对应的数据key映射到redis机器上。每台redis的初始ID不同，保持相同的步长（redis机器数量），如此就能获取到全局唯一的自增id。

优点：不依赖于数据库，性能高于数据库
缺点：系统中要引入redis，增加系统复杂度，需要更多的编码和配置工作

twitter的snowflake算法

用64bit来表示一个ID，其中41bit表示毫秒时间，10bit表示机器ID(5bit表示数据中心ID，5bit表示机器ID)，12bit表示每毫秒内的流水号（每毫秒也就能生成4096个id），还有1bit表示符号始终为0。

符号 时间 数据中心ID 机器ID 流水号

优点：不依赖于数据库，性能高于数据库，id在机器上按照时间递增
缺点：需要对每台机器进行时间同步，否则不能保证生成的id全局递增