分区取模分库分表策略:多表事务分库内闭环解决方案

简介: 当表数据超过一定量级,就需要通过分表来解决单表的性能瓶颈问题;当数据库负载超过一定水平线,就需要通过分库来解决单库的连接数、性能负载的瓶颈问题。本文将阐述在不同情况下,让不同数量级表,在同一个业务ID的事务操作路由到同一分库中的方案,省去解决垮库事务的烦恼。

image.png

作者 | 雨庄
来源 | 阿里技术公众号

一 前言

技术同学都知道,当表数据超过一定量级,我们就需要通过分表来解决单表的性能瓶颈问题;当数据库负载超过一定水平线,我们就需要通过分库来解决单库的连接数、性能负载的瓶颈问题。

本文主要阐述在同时满足以下业务场景:

  • 分表分库存储
  • 需要对分表数量不同的表进行同事务操作
  • 这些表的分库分表策略依赖的Sharding业务ID一致

等情况下,让这些不同数量级表,在同一个业务ID的事务操作路由到同一分库中的方案,省去解决垮库事务的烦恼。

二 案例

1 背景

假设有2个数据库实例,需要保存商家订单明细和汇总2张表的数据,这2张表的 分库分表策略都用shop_id取模策略,按单表数据500w的原则进行分表分库:

(1)shop_order_detail 商家订单明细表,日均数据6000w

image.png

(2)shop_order_stat 商家订单统计表,日均数据2000w

image.png

配置完成后生成的库表:

image.png

然后我们要做这么一件事情:在同一个事务中,新增用户订单明细成功后,更新用户订单统计数据:

image.png

2 问题

此时,我要处理一笔 user_id = 3 的订单数据:

image.png

如图,执行新增shop_order_detail表操作的时候,操作被路由到了DB0中;执行更新shop_order_stat表操作的时候,操作被路由到了DB1。这时候 这两个操作跨库了,无法在同一个事务中执行, 流程异常中断。

如果用TDDL组件的话就会报这样的错:

### Cause: ERR-CODE: [TDDL-4603][ERR_ACCROSS_DB_TRANSACTION] Transaction accross db is not supported in current transaction policy

三 解决方案

解决多表跨库事务的方案有很多,本文阐述的是如下解决方案:

将shop_order_stat作为shop_order_detail的映射基础表,调整shop_order_detail的分表策略,让shop_order_detail和shop_order_stat的数据都路由到同一个库中。

但该方案的前提是目标表的表数量是映射基础表表数量的N倍数。比如shop_order_stat的总表数量是4,shop_order_detail的总表数量是12,故shop_order_detail的总表数是shop_order_stat总表数的3倍。

shop_order_detail新分表分库策略的推导思路如下:

1 调整分库策略

首先,我们看shop_id在0~11范围内,用shop_id % 4分库分表策略shop_order_stat的sharding分布图:

image.png

用shop_id % 12分库分表策略shop_order_detail的sharding分布图:

image.png

图中看出,两张表都是根据shop_id做sharding,但现有同一个shop_id有可能会被路由到不同的库中,导致跨库操作。

此时,我只需要把shop_order_detail的分库策略调整为跟shop_order_stat一致,保证同一个shop_id能路由到同一个DB分片中就能解决这个问题。调整后的sharding分布图:

image.png

但调整完分库策略后,原本的表映射策略就失效了:

image.png

原本的shop_id = 5数据可以通过shop % 12 = 5的取模策略映射到DB0的shop_order_detail_05表上。调整完分库策略后,shop_id = 9被路由到了DB0中,通过shop % 12 = 9的取模策略会映射到shop_order_detail_09这张表上,但shop_order_detail_09这张表不在DB0中,所以操作失败了。

这时候,我们需要调整分表策略,把shop_id = 9的数据既映射到DB0中的shop_order_detail_05表中。

2 分区取模策略

首先,以shop_order_stat的单库表数量2作为分块大小,总表数量4作为分区大小,对shop_id=[0~11]进行分区操作,并且将shop_id根据分块大小取模:

image.png

当前分库数量为2,shop_order_stat的单库表数量为6,计算出跨库步长=分库下标*单库表数量:

image.png

根据分区下标和分块大小,计算出分区步长=分区下标*分块大小,最后根据分块取模数+跨库步长+分区步长就能定位到最终的分表下标了:

image.png

这样就完成了把shop_id = 9的数据既映射到DB0中的shop_order_detail_05表中的工作。

四 计算公式

分表下标路由策略计算公式:

分表下标 = 业务ID取模 % 分块大小 + 业务ID取模 / 分块大小 单库表数量 + 业务ID取模 / 分区大小 分块大小
  • 业务ID取模 = 业务ID % 总表数量
  • 分区大小 = 目标映射表的总表数量
  • 分块大小 = 目标映射表的单库表数量

以上面的案例为例,调整shop_order_detail的分库分表路由策略:

(1)shop_order_stat 商家订单统计表

image.png

(2)shop_order_detail 商家订单明细表

image.png

TDDL sharding-rule配置代码示例:

image.png

Java代码示例:

long shopId = 9;
int dbs = 2;
int tables = 12;
int oneDbTables = 6;
int partitionSize = 4;
int blockSize = 2;
int sharding = (int) (shopId % tables);
// 目标分库
int dbIndex = (int) (shopId % partitionSize / dbs);
// 目标分表
int tableIndex = sharding % blockSize + sharding % partitionSize / blockSize * oneDbTables + sharding / partitionSize * blockSize;

五 结尾

我是本地生活外卖商家运营研发团队中的一员,在实际业务场景的设计中遇到了多表事务分库内闭环的问题,没有找到适合的案例参考,才孵化出这个解决方案。

目前该方案已经在落地上线,有相同业务场景需求的同学可直接套用计算公式既可,欢迎大家交流沟通。


免费领取电子书

《阿里巴巴大数据及 AI 实战》

本书将深度剖析淘宝、高德、友盟+、1688、优酷、阿里妈妈、阿里影业大数据实战场景,是 2020 不容错过的企业大数据实战手册。

扫码加阿里妹好友,回复“阿里ai”获取吧~(英文字母小写,若扫码无效,可直接添加alimei4、alimei5、alimei6、alimei7)

image.png

相关文章
|
3月前
|
存储 中间件 数据库连接
|
5月前
|
分布式计算 关系型数据库 数据挖掘
实时数仓 Hologres产品使用合集之当使用动态分区管理功能按日期进行分区后,通过主键和segment_key进行时间范围查询性能变差是什么原因
实时数仓Hologres的基本概念和特点:1.一站式实时数仓引擎:Hologres集成了数据仓库、在线分析处理(OLAP)和在线服务(Serving)能力于一体,适合实时数据分析和决策支持场景。2.兼容PostgreSQL协议:Hologres支持标准SQL(兼容PostgreSQL协议和语法),使得迁移和集成变得简单。3.海量数据处理能力:能够处理PB级数据的多维分析和即席查询,支持高并发低延迟查询。4.实时性:支持数据的实时写入、实时更新和实时分析,满足对数据新鲜度要求高的业务场景。5.与大数据生态集成:与MaxCompute、Flink、DataWorks等阿里云产品深度融合,提供离在线
|
2月前
|
存储 SQL 关系型数据库
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
MySQL如何进行分库分表、数据迁移?从相关概念、使用场景、拆分方式、分表字段选择、数据一致性校验等角度阐述MySQL数据库的分库分表方案。
411 15
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
|
3月前
|
存储 SQL 关系型数据库
(二十三)MySQL分表篇:该如何将月增上亿条数据的单表处理方案优雅落地?
前面《分库分表的正确姿势》、《分库分表的后患问题》两篇中,对数据库的分库分表技术进行了全面阐述,但前两篇大多属于方法论,并不存在具体的实战实操,而只有理论没有实践的技术永远都属纸上谈兵,所以接下来会再开几个单章对分库分表各类方案进行落地。
308 3
|
4月前
|
SQL 存储 开发者
云架构数据倾斜问题之聚合操作导致数据膨胀如何解决
云架构数据倾斜问题之聚合操作导致数据膨胀如何解决
|
5月前
|
存储 消息中间件 负载均衡
技术心得记录:架构设计之数据分片
技术心得记录:架构设计之数据分片
|
存储
分区表和分桶表(高频重点)
分区表和分桶表(高频重点)
204 0
37MyCat - 分片规则(按单月小时拆分)
37MyCat - 分片规则(按单月小时拆分)
47 0
|
负载均衡 监控 定位技术
分库表数据倾斜的处理让我联想到了 AKF 模型
这里的特殊性可以是表中字段的某一个属性,比如订单编号、创建时间等等。这就需要我们根据实际情况,既要拆分的均匀又要拆分之后能满足未来几年的发展,同时还要满足现有业务的支持。
181 0
|
SQL 算法 Java
自定义水平分库分表策略【范围分片】
自定义水平分库分表策略【范围分片】
下一篇
无影云桌面