支付业务订单系统分库分表
2023-03-14 09:31:14 时间
支付业务订单系统分库分表
支付系统中订单业务最主要的查询维度有四个:订单、用户、商家、运营。
从查询数据库字段的角度来讲,B2B、B2C等模式:
- 商户编号+商户订单号查询,商户编号+商户订单号属于唯一性约束。
- 商户编号查询,例如商户后台查询,运营后台查询。
- 系统订单号查询,订单系统自身生成,全局唯一性约束。
- 用户编号查询,例如电商业务,查询自己的订单
- 系统订单号+用户编号查询,例如用户精准查询个人订单
- 无条件查询,例如运营后台查询
B2B业务
设计到分库分表字段的核心查询业务:
- 商户编号+商户订单号查询,商户编号+商户订单号属于唯一性约束。
- 商户编号查询,例如商户后台查询,运营后台查询。
- 系统订单号查询,订单系统自身生成,全局唯一性约束。
一种分库分表思路:
系统订单号生成规则:通过将分库分表的数据写入到生成规则内,这样可以进行定位位置。
商户编号规则:取商户编号后4位做分片键,进行hash取模。
B2C业务
建议把订单数据冗余一份,分买家库和卖家库,数据库通过消息中间件或者其他同步工具进行异步更新,这种场景最好将买家库的分片键(截取买家ID)和卖家库(截取卖家ID)的分片键都包含在订单ID中,这样卖家相关的业务查询订单明细时,可以直接走卖家库。
综合分析
如果是 2C 和 2B 业务综合存在,建议进行业务拆分,没有必要把数据全部放在同一个业务逻辑内。
订单数据有个比较特殊的点,随着时间的推进,大量的数据会变成冷数据,使用率会降低。还有一种根据创建时间来进行分表是一个不错的选择。所以分库分表其实没有统一的方案,要根据业务进行详细的设计。
例如根据创建时间来进行分表:
- 时间差,是不是要冗余查询,因为支付订单的时效性来讲,是不是可以默认查询2天的数据。
- 支付订单是存在有效期的,比如订单过期,所以是不是可以设置规则,接口只能查询当日的数据。
- 商户后台可以通过一些数据同步手段,例如 canal 同步到 es 等等手段。
总结:实际场景实际分析,没有统一的方案。
相关文章
- 在 Go 里用 CGO?这 7 个问题你要关注!
- 9款优秀的去中心化通讯软件 Matrix 的客户端
- 求职数据分析,项目经验该怎么写
- 在OKR中,我看到了数据驱动业务的未来
- 火山引擎云原生大数据在金融行业的实践
- OpenHarmony富设备移植指南(二)—从postmarketOS获取移植资源
- 《数据成熟度指数》报告:64%的企业领袖认为大多数员工“不懂数据”
- OpenHarmony 小型系统兼容性测试指南
- 肯睿中国(Cloudera):2023年企业数字战略三大趋势预测
- 适用于 Linux 的十大命令行游戏
- GNOME 截图工具的新旧截图方式
- System76 即将推出的 COSMIC 桌面正在酝酿大变化
- 2GB 内存 8GB 存储即可流畅运行,Windows 11 极致精简版系统 Tiny11 发布
- 迎接 ecode:一个即将推出的具有全新图形用户界面框架的现代、轻量级代码编辑器
- loongarch架构介绍(三)—地址翻译
- Go 语言怎么解决编译器错误“err is shadowed during return”?
- 敏捷:可能被开发人员遗忘的部分
- Denodo预测2023年数据管理和分析的未来
- 利用数据推动可持续发展
- 在 Vue3 中实现 React 原生 Hooks(useState、useEffect),深入理解 React Hooks 的