Only老K说-海量订单ID生成的策略

场景搭建：时间轴回滚几个月。口罩一罩难求。或者是双十一的时候生成订单的时候…
订单ID生成要求：
唯一性：高可用：高并发：趋势递增：安全性
简单说说淘宝的双十一的情况：双十一成交量大概是十亿比。（10亿/24小时/60分/60秒打约1.2万一秒

ID生成策略-数据库自增ID

搞个图形化界面去弄个自增长

以上是一种ID生成策略，但是我相信用的还是很少的原因：MySQL在优化的比较好的情况下，它的最大并发量也只是能够达到700。这种情况下如果需要完成上面的需求，起码需要10多个MySQL来完成（第一点：不太现实，。除非钱多了没地方花，专门搞这么多个MySQL来做ID生成。第二点：就算给你了这么多怎么搞呢？）
这里简单说说第二点：（到做到数据同步的两种方式）
MySQL主从同步（发现不可以，因为我们基本上都是inser或者update语句，还是只有一个数据库来完成。没有意义）

MySQL主主同步（可能存在主键冲突）

解决方案：改配置文件中的自增长长度（my.cnf）

如果是非主键能使用自增长嘛？ 自己可以去试试，是不可以的。但是我们还是可以实现的，使用last_insert_id()函数

需要注意：使用自增长ID有可能会被抓住机会，特别是不注意安全的时候，比如说请求地址被获取，又没有加密，还使用get提交（嗯。没有出事还好，出事了会很难看）

ID生成策略-UUID

UUID（通用唯一识别码）：时间戳(当前日期+时间)+时钟序列+机器识别号

UUID使用

进入randomUUID(方法中看下源码…)
默认是version 4的版本（基于随机数）随机数，你懂的，有可能是会重复的哦，所以一般还是推荐使用version1的。当然不能有时间回拨问题

version1 基于时间
version2 DCE（安全）
version3 MD5
version5 SHA1

优点很明显，代码简单，缺点就是对于我们来说是不可读的，没有办法去判断那个是先那个是后（没有递增关系）

而且数据也很长。所以存放的数据量也会比较大（这个是不好的，看下图）

不递增，可读性差，查询慢

ID生成策略-雪花算法（Snowflake）

大自然中几乎找不到两朵完全相同的雪花
组成：41位时间戳+10位机器ID+12位序号（自增），转换成长度为18的长