1, 分布式集群架构
2, 分布式高并发环境的订单号要求
全局唯一
订单号信息安全要求
趋势递增要求
3, 订单号生成策略总结
策略 | 优点 | 缺点 | 格式 |
---|---|---|---|
uuid | 实现简单不占用带宽 | 无序、不可读、查询慢 | 32 位 |
db 自增 | 无代码、递归 | DB 单点故障、扩展有瓶颈 | |
snowflake | 不占用带宽、低位趋势递增 | 依赖服务器时间 | 18 位 |
redis | 无单点故障、性能优于 DB 递增 | 占用带宽、Redis 集群需要维护 | 12 位 |
3.1, 策略一: UUID(通用唯一识别码)
组成: 当前日期 + 时间 + 时钟序列 + 机器识别号(Mac 地址或其他)
分布式系统中, 所有元素 (web 服务器) 都不需要通过中央控制端来判断数据唯一性.
3.2, 策略二: 数据库自增 ID
关系型数据库都实现数据库自增 ID;MySQL 通过 auto_increment 实现, oralce 通过 sequence 实现.
在数据库集群环境下, 不同数据库节点可设置不同起步值, 相同步长值来实现集群下生成全局唯一, 递增 ID.
3.3, 策略三: snowflake 算法
组成: 41 位时间戳 + 10 为机器 ID+12 位序列号(自增), 转换位长度为 18 的长整型.
Twitter 位满足每秒上万条消息的创建, 每条消息都必须分配全局唯一 id, 这些 id 要趋势递增, 方便客户排序.
GitHub 上可以下载到 snowflake 源码
3.4, 策略四: Redis 自增 ID
Redis 实现了 incr(key)API 用于将 key 的值递增 1 并返回结果. 若 key 不存在, 则创建并赋值为 0.
Redis id 自增的方法 : 格式 : 前缀 + 自增 id 使用超时时间是为了防止自增到 9999 时订单号的位数变长
4, 四种 ID 自增的格式示例
uudi:205f1537-7991-4ed3-a2c7-c05aa8f8428b
数据库自增: 自增 ID
- snowflake:386992679587676176
- Redis:173372100001
来源: https://www.cnblogs.com/luao/p/10474213.html