支付业务订单系统分库分表

数据库 其他数据库
建议把订单数据冗余一份,分买家库和卖家库,数据库通过消息中间件或者其他同步工具进行异步更新,这种场景最好将买家库的分片键(截取买家ID)和卖家库(截取卖家ID)的分片键都包含在订单ID中,这样卖家相关的业务查询订单明细时,可以直接走卖家库。

支付业务订单系统分库分表

支付系统中订单业务最主要的查询维度有四个:订单、用户、商家、运营。

从查询数据库字段的角度来讲,B2B、B2C等模式:

  • 商户编号+商户订单号查询,商户编号+商户订单号属于唯一性约束。
  • 商户编号查询,例如商户后台查询,运营后台查询。
  • 系统订单号查询,订单系统自身生成,全局唯一性约束。
  • 用户编号查询,例如电商业务,查询自己的订单
  • 系统订单号+用户编号查询,例如用户精准查询个人订单
  • 无条件查询,例如运营后台查询

B2B业务

设计到分库分表字段的核心查询业务:

  • 商户编号+商户订单号查询,商户编号+商户订单号属于唯一性约束。
  • 商户编号查询,例如商户后台查询,运营后台查询。
  • 系统订单号查询,订单系统自身生成,全局唯一性约束。

一种分库分表思路:

系统订单号生成规则:通过将分库分表的数据写入到生成规则内,这样可以进行定位位置。

商户编号规则:取商户编号后4位做分片键,进行hash取模。

B2C业务

建议把订单数据冗余一份,分买家库和卖家库,数据库通过消息中间件或者其他同步工具进行异步更新,这种场景最好将买家库的分片键(截取买家ID)和卖家库(截取卖家ID)的分片键都包含在订单ID中,这样卖家相关的业务查询订单明细时,可以直接走卖家库。

综合分析

如果是 2C 和 2B 业务综合存在,建议进行业务拆分,没有必要把数据全部放在同一个业务逻辑内。

订单数据有个比较特殊的点,随着时间的推进,大量的数据会变成冷数据,使用率会降低。还有一种根据创建时间来进行分表是一个不错的选择。所以分库分表其实没有统一的方案,要根据业务进行详细的设计。

例如根据创建时间来进行分表:

  • 时间差,是不是要冗余查询,因为支付订单的时效性来讲,是不是可以默认查询2天的数据。
  • 支付订单是存在有效期的,比如订单过期,所以是不是可以设置规则,接口只能查询当日的数据。
  • 商户后台可以通过一些数据同步手段,例如 canal 同步到 es 等等手段。

总结:实际场景实际分析,没有统一的方案。​

责任编辑:武晓燕 来源: 今日头条
相关推荐

2022-10-09 18:14:31

订单系统分库分表

2022-10-10 17:37:59

分库分表订单业务

2022-06-30 14:07:10

分库分表系统

2017-07-06 00:27:17

虚拟订单中心京东数据

2020-02-14 14:13:13

架构运维技术

2022-06-30 07:34:46

分库分表外卖订单系统

2021-09-08 09:48:39

数据库工具技术

2017-03-02 13:23:53

订单系统水平分库

2020-07-30 17:59:34

分库分表SQL数据库

2022-07-11 08:16:47

NewSQL关系数据库系统

2019-11-12 09:54:20

分库分表数据

2020-11-18 09:39:02

MySQL数据库SQL

2021-08-31 20:21:11

VitessMySQL分库

2021-08-02 08:05:05

系统订单 Python

2021-01-26 05:37:08

分库分表内存

2020-07-28 09:04:09

NewSQL分库分表

2019-01-16 14:00:54

数据库分库分表

2020-09-27 08:00:49

分库分表

2018-09-21 15:50:58

数据库MySQL分库分表

2021-10-29 07:25:32

分库分表技巧
点赞
收藏

51CTO技术栈公众号