如何设计订单编号?

近项目需要设计订单模块,其中首当其冲的就是订单号的设计。本文整理部分订单号设计思路,抛砖引玉。

设计要求

  • 唯一性 订单号不能重复
  • 安全性 外部人员不能通过订单号窥探到订单业务数据,比如:SKU 订单数等。
  • 可读性(可选) 内部人员可以比较直观的看出订单所属商家,品类等信息。

设计思路

数据库自增ID

优点:

  • 由于自增,唯一性条件满足。又因为是主键,查询效率也很高,且支持范围查询。

缺点:

  • 不满足安全性,自增ID可以直接看到订单数量。没有业务字段参与其中,没有可读性。

UUID

优点:

  • 在同一台机器上生产订单号(多台机器可能出现碰撞),满足唯一性条件。
  • 数据无意义,谁也不能猜到业务数据。安全性满足。

缺点:

  • 数据比较长(36位),没有可读性。

在不考虑可读性的情况下,UUID 也还是不错的。各个语言都有成熟的库,使用方便。

SnowFlake(雪花算法)

SnowFlake 使用 int64 数字做唯一ID,且 ID 引入时间戳,保持自增性且不重复。

雪花算法结构:

雪花算法结构

优点:

  • 数据格式紧凑,数据库使用 bigint 即可存储
  • ID保持自增性,满足唯一性。
  • 支持分布式生成。

缺点:

  • 可读性较差

其实也可以将业务数据放进去,比如从工作机器中抽个几位标识业务字段。

转为二进制也可解出业务数据。

自定义组合

假设订单号需包含:订单类型、商品大类ID、日期、用户ID。

简单组合

订单类型(1位) 商品大类ID(2位) 日期(10位)          用户ID(后4位)
1            22              1625133028          9527

订单号即:1226251330289527,长度16位。

这样也比较容易看出规律,需要将数据变形,比如将数据反过来显示,具体实现自行思考吧。

总结

订单号设计还是需要根据具体业务来设计。如果不考虑可读性,雪花算法就挺好。

参考:

updatedupdated2021-07-012021-07-01
Load Comments?