关于分布式系统唯一ID的生成方案

系统唯一ID是我们在设计一个系统的时候常常会遇见的问题

生成ID的方法有很多，适应不同的场景、需求以及性能要求。所以有些比较复杂的系统会有多个ID生成的策略

一些常见的ID生成策略。

1. 数据库自增长序列或字段

分表分库的时候会有麻烦，多个系统或者数据库的id合并
会有麻烦，而且还有系统和数据库版本差异，算法的不同
大量新增记录的时候，IO会集中在一个分区上，造成热点数据。

优化方案：
有多个Master库，则每个Master库设置的起始数字不一样，步长一样，可以是Master的个数。比如：Master1 生成的是 1，4，7，10，Master2生成的是2,5,8,11 Master3生成的是 3,6,9,12。这样就可以有效生成集群中的唯一ID，也可以大大降低ID生成数据库操作的负载。

2. UUID

UUID是由32个的16进制数字组成，所以每个UUID的长度是128位（16^32 = 2^128）。UUID作为一种广泛使用标准，有多个实现版本，影响它的因素包括时间、网卡MAC地址、自定义Namesapce等等。

生成ID性能非常好，基本不会有性能问题。
全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更等情况下，可以从容应对。

缺点
不可读，使用字符串存储，查询的效率比较低，不是递增

优化方案：

3. UUID的变种

用算法，提取一部分数据，这个算法叫comb，保留GUID的10个字节，用另6个字节表示GUID生成的时间（DateTime）。（有兴趣可以看看）

4.Redis生成ID

适合使用Redis来生成每天从0开始的流水号。比如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key，使用INCR进行累加。，同上面设置步长和初始值的分布式思想异曲同工
优点：

1）不依赖于数据库，灵活方便，且性能优于数据库。

2）数字ID天然排序，对分页或者需要排序的结果很有帮助。

缺点：

1）如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。，其实这个对于用Java开发的spring类型项目不算太难

2）需要编码和配置的工作量比较大。

4.Twitter的雪花算法

结果是一个long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是0。
基本就是全球唯一了

snowflake算法在工程实现上有单机版本和分布式版本。
在分布式上面，由于使用的是GMT的时间，同步麻烦

5.zookeeper注册中心生成

不太好用，zookeeper配置麻烦