分布式——分布式订单号生成策略 （1）

需求：下订单，查看过自己的订单号规律？

 

1. 全局唯一
2. 趋势递增，不是严格递增1、2、3、4
3. 长度固定
4. 整形，不是字符串
5. 安全性
6. 高并发

策略一：UUID/GUID（通用唯一标识码）——适合单体应用

用到了以太网卡地址（MAC）、纳秒级时间、芯片ID码和许多可能的数字。

• 优点：
  • 使用简单
  • 不依赖其他组件
  • 不影响数据库拓展
• 缺点：
  • 数据库索引效率低
  • 太过于无意义，用户不友好
  • 长度36的字符串，空间占用大
  • 应用集群环境，机器多的时候，重复几率大

 

策略二：数据库自增

• 优点
  • 无需编码
  • 性能过得去
  • 索引友好
• 缺点
  • 大表不能做水平分表，否则插入删除易出现问题
  • 依赖前期规划，拓展麻烦
  • 依赖MySQL内部维护“自增锁”，高并发下插入数据影响性能
  • 在业务操作父、子表（关联表）插入时，要“先父后子”

 

策略三：推特的雪花算法

• 优点
  • 性能较优，速度快
  • 无需第三方依赖，实现也很简单
  • 可以根据实际情况调整和扩展算法，方便灵活

 

策略四：基于Redis自增

Redis性能很高的原因是什么？操作物理内存，IO多路复用，单线程

• 优点
  • 扩展性强，可以方便的结合业务进行处理
  • 利用Redis操作原子性的特性，保证在并发的时候不会重复
• 缺点
  • 引入Redis就意味着引入其他第三方的依赖
  • 增加一次网络开销
  • 需要对Redis服务实现高可用

 

 

本文地址：https://blog.csdn.net/ybshengkai00/article/details/107583419