图解支付系统订单号设计与最佳实践

数据库 其他数据库
假如你也好奇为什么有了数据库自增ID外还需要业务ID,或者想了解如何在业务ID中编织进业务信息比如业务系统,数据版本,分库分表位等,值得花几分钟了解一下。同时我也不建议在支付系统中使用雪花算法来生成业务ID。

本文主要讲清楚支付系统订单号(或业务ID)各种设计方案对比,各子域的订单号(或业务ID)为什么要统一规范,以及最佳实践。最后还会简单分析微信支付和支付宝的对客订单号的组成差异。

假如你也好奇为什么有了数据库自增ID外还需要业务ID,或者想了解如何在业务ID中编织进业务信息比如业务系统,数据版本,分库分表位等,值得花几分钟了解一下。

同时我也不建议在支付系统中使用雪花算法来生成业务ID。

订单号和业务ID本质都是标识一笔交易,以下统称为:业务ID。

1. 什么是业务ID

数据库一般都会设计一个自增ID做为主键,同时还会设计一个能唯一标识一笔业务的ID,这就是所谓的业务ID(也称业务键)。比如收单域有收单单号,支付域有支付号,渠道网关域有渠道支付号等,这些都属于业务ID。

为什么有了自增ID后,还需要有业务ID呢?一般来说有以下几个核心原因:

  • 分库分表的强诉求。一旦分库分表,各表之间的自增ID就一定会重复。
  • 全球化部署的强诉求。在跨境支付系统建设时,部分国家地区要求本地化部署,需要通过业务ID知道业务运行在哪个机房。
  • 标识业务语义,在处理故障时能快速定位是哪个域哪个业务。
  • 方便系统升级。通过业务ID的版本所在位判断业务应该走新系统,还是走老系统。

2. 为什么业务ID要统一规范

互联网支付系统基本都是微服务化部署,每个子域都是相对独立的一些同学在研发,架构实现差异非常大,但是业务ID是必须要统一的。主要有以下几个原因:

  • 减少维护成本。避免在不同服务中重复发明相似机制,也减少了沟通成本。方便做成统一的组件。
  • 加速异常处理和诊断。在分布式环境下发现和解决问题一般都比较复杂,统一的业务ID规范可以快速判断问题所在的域,以及对应的业务。
  • 避免新同学因经验不足导致设计缺陷,在后期无法满足业务诉求。

3. 常见业务ID生成规范及应用场景

业务ID生成规则有很多种,比如知名的Snowflake算法,UUID算法,时间戳+随机数/序列号等。以下是部分规范的简要介绍。

  • Snowflake算法

组成:时间戳 + 数据中心标识 + 机器节点 + 序列号。

适用场景:无中心化的环境中生成大量的唯一ID,无具体业务语义,且性能要求极高。比如社交媒体的聊天消息记录。

  • UUID算法

高度唯一且随机。

适用场景:不想让外界感知内部系统的交易量级。比如调用外部渠道的请求号,如果使用序列号,有可能会让外部猜测出交易的规模。

  • 编码系统

特定组织中心化生成。

适用场景:药品或供应链管理,全球范围内标识或追踪商品。

  • 业务规则编码

把一些业务语义编码到ID中。

适用场景:金融支付、电商订单等。

4. 支付系统业务ID生成最佳实践

4.1. 业务ID生成规范

下面以32位的支付系统业务ID生成为例说明。实际应用时可灵活调整。

图片图片

第1-8位:日期。通过单号一眼能看出是哪天的交易。

第9位:数据版本。用于单据号的升级。

第10位:系统版本。用于内部系统版本升级,尤其是不兼容升级的时候,老业务使用老的系统处理,新业务使用新系统处理。

第11-13位:系统标识码。支付系统内部每个域分配一段,由各域自行再分配给内部系统。比如010是收单核心,012是结算核心。

第14-15位:业务标识位。由各域内部定,比如00-15代表支付类业务,01支付,02预授权,03请款等。

第16-17位:机房位。用于全球化部署。

第18-19位:用户分库位。支持百库。

第20-21位:用户分表位。支持百表。

第22位:预发生产标识位。比如0代表预发环境,1代表生产环境。

第23-24位:预留。各域根据实际情况扩展使用。

第24-32位:序列号空间。一亿规模,循环使用。一个机房一天一亿笔是很大的规模了。如果不够用,可以扩展到第24位,到十亿规模。

4.2. 业务ID生成技术实现

序列号通常采用数据库生成,保证机房内唯一性。

图片图片

简要流程如下:

  1. DB初始化序列号数据。KEY为业务类型,VALUE初始为0;
  2. 调用业务ID生成组件。核心传参:数据版本号,系统版本号,系统名,业务类型等。
  3. 业务ID生成组件查看对应业务类型是否有缓存数据。如果没有,就以指定步长(比如100)去更新数据库,然后缓存起来。
  4. 在内存中加一,然后根据规则生成业务ID,返回给调用方。

这里使用指定步长去更新数据库,主要是考虑提高性能。但是存在一定的损失,比如发布重启,缓存中的序列号就会被浪费掉。但因为是循环使用,所以基本上对业务没有影响。

5. 内外区分

    建议把内部订单号和外部订单号做个区分。所谓外部订单号主要指对客(包括个人用户和商户)的订单号,这种场景下,可以考虑把业务类型做为重点编织进到订单号里面。

    具体可以参考下面聊到的微信支付和支付宝对客订单号。

6. 微信支付和支付宝对客订单号的异同

    微信支付:

图片图片

    有兴趣的可以翻翻自己微信支付的订单记录,42000开头的是支付类的订单,1000050001开头是转账类订单,也就是微信支付把交易类型放在订单的开头。

    日期则放在交易类型的后面。

支付宝:

图片图片

    也可以翻翻自己支付宝的订单记录,日期放在开头,紧接着日期的就是交易类型,2000代表转账,比如202501012000xxxx。而2300或2200就是买东西的支付订单。

7. 结束语

本文主要讲了业务ID是什么,业界常见生成规则及适用场景,以及支付系统业务ID生成的最佳实践。

责任编辑:武晓燕 来源: 隐墨星辰
相关推荐

2019-08-23 08:09:18

订单号生成数据库ID

2019-08-15 11:11:38

Java数据库设计

2024-10-14 12:05:56

2021-07-01 06:58:12

高并发订单号SCM

2024-09-04 08:55:56

2020-10-21 12:10:30

订单号Java代码

2024-09-13 08:18:10

2021-12-28 06:55:09

事故订单号绩效

2017-10-20 08:25:10

数据收集工具数据源

2009-08-20 09:41:36

2013-06-13 09:21:31

RESTful APIRESTfulAPI

2016-12-27 08:49:55

API设计策略

2010-12-28 10:12:39

PHP

2024-10-14 08:09:08

2024-06-18 08:07:50

存储架构设计

2024-09-29 09:42:56

2023-02-03 18:31:35

订单流量录制

2024-02-19 08:12:15

DIKW 模型指标系统数据仓库

2009-06-22 14:48:21

DRY架构设计

2023-12-18 07:41:28

系统存储userID
点赞
收藏

51CTO技术栈公众号