分布式唯一Id生成方案

一 背景

1. 分布式系统中我们会对一些数据量大的业务进行拆分，如：订单表。因为数据量巨大一张表无法承接，就会对其进行分库分表。但一旦涉及到分库分表，就会引申出分布式中唯一主键Id的生成问题。
2. 文章中需要唯一ID的特性：

整个系统ID唯一
ID是数字类型，而且趋势递增的
ID简短，查询效率快

3. 什么是递增？
   12，13，14
4. 什么是趋势递增？
   先从[0,1000]之间，再到[1000,2000]
   [0,1000]生成ID有可能是12，10，14

二 分布式ID的几种生成方案

2.1 UUID

2.1.1优点

1. 代码实现简单
2. 全球唯一，迁移数据容易

2.1.2 缺点

1. 每次生成ID是无序的，无法保证趋势递增
2. UUID的字符串存储，查询效率慢
3. 存储空间大
4. 无业务含义，不可读

2.2 MySQL主键自增

利用MySQL的主键自增auto_increment,默认每次ID加1。

2.2.1 优点

1. 数字化id增加，查询效率高

2.2.2 缺点

1. 存在单点问题，如果MySQL挂了，就没法生成ID
2. 数据库压力大，高并发扛不住

2.3 MySQL多实例主键自增

设置step步长和auto_increment初始值

2.3.1 优点

1. 解决了单点问题

2.3.2 缺点

1. 一旦把步长定好后，就无法扩容；

2.4 雪花算法

雪花算法生成64位的二进制正整数，然后转换为10进制的数

1位标识位：始终是0
41位时间戳：当前时间戳-开始时间戳；开始时间戳是我们id生成器开始使用的时间，由我们程序来指定的。
10位机器标识码：工作机器id，可以部署1024个节点，如果机房分机房部署，可以由5位机房Id+5位机器Id组成
12位序列号：该序列是用来在同一毫秒内生成不同的ID，如果这个毫秒内生成的数量超过4096（2的12次幂），那么生成器会等待到下个毫秒继续生成的。
雪花算法不依赖第三方，速度快，适合高并发场景。

2.5 redis

利用redis的incr原子性操作自增功能，
业务标识+时间戳(年月日)+redis自增
‘车辆来源,0:不限；1：内部推荐IN；2：直接到店SH；3：同行介绍PE’,
优点是：实现起来比较简单，适用于对业务并发量不是很大的情况下。
缺点是：并发量很大的情况下，对性能要求很高的话，每次都要向redis进行请求，对redis依赖比较大，
所以redis适合并发量不是很大的情况