一，唯一ID的特性：
整个系统ID唯一
ID是数字类型，而且是趋势递增的
ID简短，查询效率快
什么是递增？
如：第一次生成的ID为12，下一次生成的ID是13，再下一次生成的ID是14。这个就是生成ID递增。
什么是趋势递增？
如：在一段时间内，生成的ID是递增的趋势。如：再一段时间内生成的ID在【0，1000】之间，过段时间生成的ID在【1000，2000】之间。但在【0-1000】区间内的时候，ID生成有可能第一次是12，第二次是10，第三次是14。
二、分布式ID的几种生成方案
2.1、UUID
这个方案是小伙伴们第一个能过考虑到的方案
优点：
代码实现简单。
本机生成，没有性能问题
因为是全球唯一的ID，所以迁移数据容易
缺点：
每次生成的ID是无序的，无法保证趋势递增
UUID的字符串存储，查询效率慢
存储空间大
ID本事无业务含义，不可读
应用场景：
类似生成token令牌的场景
不适用一些要求有趋势递增的ID场景
此UUID方案是不适用老顾的需求。
实现代码：
<pre xml:space="preserve" style="margin: 0px; padding: 0px; border: 0px; line-height: 1.57143em; font-family: Monaco, Courier, monospace; color: rgb(56, 56, 56); font-size: 14px; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration-style: initial; text-decoration-color: initial;">import java.util.UUID;
public class Uuid {
public static void main(String[] args) {
for (int i = 0; i < 5; i++) {
//注意replaceAll前面的是正则表达式
String uuid = UUID.randomUUID().toString().replaceAll("-","");
System.out.println(uuid);
}
}
}</pre>
2.2、MySQL主键自增
这个方案就是利用了MySQL的主键自增auto_increment，默认每次ID加1。
优点：
数字化，id递增
查询效率高
具有一定的业务可读
缺点：
存在单点问题，如果mysql挂了，就没法生成iD了
数据库压力大，高并发抗不住
2.3、MySQL多实例主键自增
这个方案就是解决mysql的单点问题，在auto_increment基本上面，设置step步长
[图片上传失败...(image-b6deb9-1570518549756)]
每台的初始值分别为1,2,3...N，步长为N（这个案例步长为4）
优点：
- 解决了单点问题
缺点：
- 一旦把步长定好后，就无法扩容；而且单个数据库的压力大，数据库自身性能无法满足高并发
应用场景：
- 数据不需要扩容的场景
此方案也不满足老顾的需求，因为不方便扩容（记住这个方案，嘿嘿）
2.4、雪花snowflake算法
这个算法网上介绍了很多，老顾这里就不详细介绍。雪花算法生成64位的二进制正整数，然后转换成10进制的数。64位二进制数由如下部分组成：
1位标识符：始终是0
41位时间戳：41位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截 )得到的值，这里的的开始时间截，一般是我们的id生成器开始使用的时间，由我们程序来指定的
10位机器标识码：可以部署在1024个节点，如果机器分机房（IDC）部署，这10位可以由 5位机房ID + 5位机器ID 组成
12位序列：毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号
优点：
此方案每秒能够产生409.6万个ID，性能快
时间戳在高位，自增序列在低位，整个ID是趋势递增的，按照时间有序递增
灵活度高，可以根据业务需求，调整bit位的划分，满足不同的需求
缺点：
- 依赖机器的时钟，如果服务器时钟回拨，会导致重复ID生成
在分布式场景中，服务器时钟回拨会经常遇到，一般存在10ms之间的回拨；小伙伴们就说这点10ms，很短可以不考虑吧。但此算法就是建立在毫秒级别的生成方案，一旦回拨，就很有可能存在重复ID。
此方案暂不符合老顾的需求（嘿嘿，看看怎么优化这个方案，小伙伴们先记住）
2.5、Redis生成方案
利用redis的incr原子性操作自增，一般算法为：
年份 + 当天距当年第多少天 + 天数 + 小时 + redis自增
优点：
- 有序递增，可读性强
缺点：
- 占用带宽，每次要向redis进行请求
整体测试了这个性能如下：
需求：同时10万个请求获取ID
1、并发执行完耗时：9s左右
2、单任务平均耗时：74ms
3、单线程最小耗时：不到1ms
4、单线程最大耗时：4.1s
性能还可以，如果对性能要求不是太高的话，这个方案基本符合老顾的要求。
但不完全符合业务老顾希望id从 1 开始趋势递增。（当然算法可以调整为 就一个 redis自增，不需要什么年份，多少天等）。
2.6、小结
以上介绍了常见的几种分布式ID生成方案。一线大厂的分布式ID方案绝没有这个简单，他们对高并发，高可用的要求很高。
如Redis方案中，每次都要去Redis去请求，有网络请求耗时，并发强依赖了Redis。这个设计是有风险的，一旦Redis挂了，整个系统不可用。
而且一线大厂也会考虑到ID安全性的问题，如：Redis方案中，用户是可以预测下一个ID号是多少，因为算法是递增的。
这样的话竞争对手第一天中午12点下个订单，就可以看到平台的订单ID是多少，第二天中午12点再下一单，又平台订单ID到多少。这样就可以猜到平台1天能产生多少订单了，这个是绝对不允许的，公司绝密啊。
三、一线大厂是如何设计的呢?
一线大厂的设计思路其实和小伙伴们思路差不多，只是多想了1～2层，设计上面多了1～2个环节。
3.1、改造数据库主键自增
上述我们介绍了利用数据库的自增主键的特性，可以实现分布式ID；这个ID比较简短明了，适合做userId，正好符合如何永不迁移数据和避免热点? 根据服务器指标分配数据量(揭秘篇)文章中的ID的需求。但这个方案有严重的问题：
一旦步长定下来，不容易扩容
数据库压力山大
小伙伴们看看怎么优化这个方案。先看数据库压力大，为什么压力大？是因为我们每次获取ID的时候，都要去数据库请求一次。那我们可以不可以不要每次去取？
思路我们可以请求数据库得到ID的时候，可设计成获得的ID是一个ID区间段。
利用事务方式加行锁，上面的语句，在没有执行完之前，是不允许第二个用户服务请求过来的，第二个请求只能阻塞。
3.3、突发阻塞问题
