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