需求：下订单，查看过自己的订单号规律？
- 全局唯一
- 趋势递增，不是严格递增1、2、3、4
- 长度固定
- 整形，不是字符串
- 安全性
- 高并发
策略一：UUID/GUID（通用唯一标识码）——适合单体应用
用到了以太网卡地址（MAC）、纳秒级时间、芯片ID码和许多可能的数字。
- 优点：
- 使用简单
- 不依赖其他组件
- 不影响数据库拓展
- 缺点：
- 数据库索引效率低
- 太过于无意义，用户不友好
- 长度36的字符串，空间占用大
- 应用集群环境，机器多的时候，重复几率大
策略二：数据库自增
- 优点
- 无需编码
- 性能过得去
- 索引友好
- 缺点
- 大表不能做水平分表，否则插入删除易出现问题
- 依赖前期规划，拓展麻烦
- 依赖MySQL内部维护“自增锁”，高并发下插入数据影响性能
- 在业务操作父、子表（关联表）插入时，要“先父后子”
策略三：推特的雪花算法
- 优点
- 性能较优，速度快
- 无需第三方依赖，实现也很简单
- 可以根据实际情况调整和扩展算法，方便灵活
策略四：基于Redis自增
Redis性能很高的原因是什么？操作物理内存，IO多路复用，单线程
- 优点
- 扩展性强，可以方便的结合业务进行处理
- 利用Redis操作原子性的特性，保证在并发的时候不会重复
- 缺点
- 引入Redis就意味着引入其他第三方的依赖
- 增加一次网络开销
- 需要对Redis服务实现高可用
本文地址：https://blog.csdn.net/ybshengkai00/article/details/107583419
