订单号的基本原则
订单号作为交易的重要标识,一个好的订单号应该满足以下要求:
- 唯一性。确保订单号的生成不会出现重复。
- 安全性。订单号不会泄露用户信息、业务运营状况等敏感信息。
- 可读性。好的订单号应该被易于阅读,客户反馈时降低传达错误概率。
- 按需包含日常运维信息。
基于以上原则设计的唯一标识在生活中有一个很好的例子——身份证号,其具体的设计可查看我的另一篇文章你的身份证号码都包含了哪些信息?。在身份证号中,18 位数字包含了地区、生日、派出所编码、性别、校验等信息,如果我们在订单号中加入一些非敏感的日常运维信息,将会极大提升工作效率。
电商巨头订单号
目前,淘宝订单号为 18 位,末6位为部分用户 ID, 2009 年 7 月的淘宝订单号为 10 位;京东订单号为 12 位,2015 年 1 月时订单为 10 位。可见订单号也是随着业务不断变化的,重要的是如何更好的服务于业务。
美团技术团队直接开源Leaf 订单号生成器,这是为数不多的大数据量生成订单解决方案的开源,我们从中能得到很多的借鉴。
常见设计
- 年月日时分秒 + 用户 ID
- 年月日时分秒 + 随机数 + 校验码
- 随机订单号
- 根据业务信息加密处理生成
- 根据业务运营情况生成
在设计订单号时,有些具备唯一性的 ID 是很好的防冲突手段,如用户 ID、时间戳等,但直接加入又会暴露敏感信息,因此可以混入取模、移位、异或、校验位等加密敏感信息,同时防止订单号被构造。
最后,没有银弹,根据业务的实际情况按需设计,合适的才是最好的。
— 2020.04.24 更 —
基于以上的订单设计原则,我们假设现在有这样一个订单场景:用户 ID 为 10000000 起始的自增 ID,任务 ID 为 1000 起始的自增 ID,一个任务只能被每个用户领取一次,我们对订单号有以下要求:
- 唯一性
- 订单号中体现下单日期
- 订单号不能泄露业务信息,如每日订单量、用户 ID 等
- 具备校验防伪功能
- 订单号为纯数字
- 在满足业务需求的前提下尽可能简短,长度在 10 ~ 14 位
根据订单号的要求,我们设计出以下格式的订单号:
1 | YYMMDD(6)/uid(2)/tid(2)/checksum(1) |
订单号长度共 11 位,前 6 位为下单日期(年份用两位表示已经足够),用户 ID 与任务 ID 取模运算结果各 2 位,校验位 1 位(用于防止订单号的伪造)。每天的订单容量为 10 万,如果业务增长很快,可以按需扩容。实现代码如下:
1 | class OrderNumber |
当运行了一段时间后,我们发现以上代码会有订单冲突的现象,比如 generate(10001500, 2678)
与 generate(10001597, 2625)
会得到相同的订单号,排查生成规则后发现,两个用户 ID 取模结果相同、任务 ID 取模结果也相同,所以导致了最终的订单号相同。进一步思考后发现,只要 ID 差值为模值,就会在取模后得到相同的结果,因此对取模结果加入异或随机数的运算,相关代码变更如下:
1 | public function generate($userId, $taskId): string |