mysql分布式id生成策略

1. 数据库自增长序列或字段（分布式的场景采用添加步长的方法）

最常见的方式。利用数据库，全数据库唯一。

首先，数据库自增ID需要锁表

而且，UUID的生成强依赖于数据库，每次获取UUID都需要经过一次数据库的调用，性能损耗很大。

其实，在这种大并发的场景中，数据库的主键都不建议使用数据库的自增ID。因为虽然这个简单，但是如果随便业务发展，需要对原有的数据进行重新分库分表的时候，可能会产生主键冲突，这影响了系统的平滑扩容

优点：

1）简单，代码方便，性能可以接受。
2）数字ID天然排序，对分页或者需要排序的结果很有帮助。

缺点：

1）不同数据库语法和实现不同，数据库迁移的时候或多数据库版本支持的时候需要处理。
2）在单个数据库或读写分离或一主多从的情况下，只有一个主库可以生成。有单点故障的风险。
3）在性能达不到要求的情况下，比较难于扩展。
4）如果遇见多个系统需要合并或者涉及到数据迁移会相当痛苦。
5）分表分库的时候会有麻烦。

优化方案：

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

2. UUID（不推荐）

常见的方式。可以利用数据库也可以利用程序生成，一般来说全球唯一。

优点：

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

缺点：

1）没有排序，无法保证趋势递增。
2）UUID往往是使用字符串存储，查询的效率比较低。
3）存储空间比较大，如果是海量数据库，就需要考虑存储量的问题。
4）传输数据量大
5）不可读。

3. 雪花算法

twitter生成全局ID生成器的算法策略。

图片发自简书App
如图所示，这里第1位不可用，前41位表示时间，中间10位用来表示工作机器的id，后12位的序列号.

其中时间比较好理解，工作机器id则是机器标识，序列号是一个自增序列。有多少位表示在这一个单位时间内，此机器最多可以支持2^12个并发。在进入下一个时间单位后，序列号归0。

简单来说：就是把64的Long型数据由以下几个部分组成：

符号位(1位)-时间戳(41位)-数据中心标识(5位)-ID生成器实例标识(5位)-序列号(12位)

通过部署多个ID生成器，位各个业务系统生成全局唯一的Long型ID。

优点：生成Long型易操作，有序

缺点：需要独立部署id生成器，增加维护成本

4. Redis生成ID

当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR和INCRBY来实现。

可以使用Redis集群来获取更高的吞吐量。假如一个集群中有5台Redis。可以初始化每台Redis的值分别是1,2,3,4,5，然后步长都是5。各个Redis生成的ID为：

A：1,6,11,16,21

B：2,7,12,17,22

C：3,8,13,18,23

D：4,9,14,19,24

E：5,10,15,20,25

这个，随便负载到哪个机确定好，未来很难做修改。但是3-5台服务器基本能够满足器上，都可以获得不同的ID。但是步长和初始值一定需要事先需要了。使用Redis集群也可以方式单点故障的问题。

另外，比较适合使用Redis来生成每天从0开始的流水号。比如订单号=日期+当日自增长号。可以每天在Redis中生成一个Key，使用INCR进行累加。

优点：

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

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

缺点：

1）如果系统中没有Redis，还需要引入新的组件，增加系统复杂度。

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