分库表数据倾斜的处理让我联想到了 AKF 模型

简介: 这里的特殊性可以是表中字段的某一个属性,比如订单编号、创建时间等等。这就需要我们根据实际情况,既要拆分的均匀又要拆分之后能满足未来几年的发展,同时还要满足现有业务的支持。

1 背景
最近在做需求的时候需要在一张表中增加一个字段。

这张表情况如下:

1、拆分了多个库多张表

2、库表拆分按表中商户编码字段 hash 之后取模进行拆分

由于库表拆分按照商户编码,有些大商家的单子数量远远要高于其他普通商家,这样就造成了严重的数据倾斜。

在增加字段的时候尝试多种办法,执行多次都添加失败。

虽然通过一些特殊手段还是可以将字段加上的,

但是如果这张表中的数据一直持续下去,导致的结果可能是这张表越来越难以扩展,并且随着数据量的增加还对未来造成一定的隐患。

所以决定对此表再次进行拆分,这时让我想起多年前看的一本书《架构真经》在第二章中介绍分而治之的方法论,其中 AKF 模型很实用,对我的启发很大。

接下来就简单介绍下。

关于《架构真经》的介绍:本书全面概括了互联网技术架构的理念、设计、实施和监控方面的相关场景、条件和方法,是一本有关设计和构建可扩展性系统的深入且实用的指南。作者马丁・阿伯特和迈克・费舍尔已经为数以百计高速增长公司的上千个不同系统提供了帮助,凭借着多年积累的实战经验,提炼出 50 条互联网技术架构原则,可以支持几乎任何高速增长公司的扩展。

2 理论模型介绍
关于 AKF 简介
AKF 是以 AKF 公司的合作伙伴的名字(AKF Partner)命名的,AKF 扩展立方体主要围绕系统扩展为主题进行介绍。提出了 X、Y、Z 三种扩展方向。通过不同方向的扩展来达到接近无限扩展的目的。

X 轴是水平扩展,通俗说就是复制多份数据或服务

Y 轴是针对动词(服务)或名词(资源)的拆分,或者说就是业务上的拆分

Z 轴是根据实际情况对客户独特属性进行拆分(ID,名称,地理位置等)

X,Y,Z 轴分别代表了不同的扩展方向,下面简单解释一下:

X 轴代表无差别的克隆服务和数据库。实际场景中我们的应用服务,以及数据库数据的副本理论上是可以无限扩展的。在每个克隆实体间无差别的分配任务,每个克隆实体都可以完成其他克隆实体的任务,无论任务分配给了谁。比如应用服务复制部署了多份,通过负载均衡分发请求,每个应用都可以处理其他应用的请求。

X 轴优点:成本低,操作与应用简单

X 轴缺点:X 轴无差别的处理请求,要求请求之间尽量不要有依赖关系,或者中间状态。数据集过大依然是风险,同时随着系统变大业务变多指令集耦合也会变得很多。

Y 轴代表的是按照交易处理的数据类型、交易任务的类型或两者组合分割的工作责任。我们一般用动词或资源进行分离,比如:登录,查询,结算等等。把同样的工作分割成流水线式的工作流或并行的处理流,Y 轴代表的更多是对工作的 “工业革命”,将耦合紧密的工作进行进行专门处理。Y 轴实质代表责任、行动或数据。实施成本一般比 X 轴扩展代价高。假如有 100 个人分别造 100 辆车,每个人负责造一辆,完成造车全部的任务,不如让 100 个人执行子任务,如发动机的安装、喷漆、四轮定位。这样就会减少前后交互所需要的上下文信息,更专注做某件事情。内聚性更高,耦合性更低。Y 轴主要解决指令集的扩展性。

Y 轴优点:可以解决指令集与数据集的约束与耦合,充分体现分而治之的思想,代码简单,故障隔离等。

Y 轴缺点:成本相对较高,系统庞大,业务复杂

Z 轴通常基于请求或客户的信息进行分割。比如我们在拆分客户时会有 “普通会员” 和 “vip 会员 “之分,服务 “普通会员” 与服务 “vip 会员” 可能会有不同。vip 会员可能会有更多的服务项目,会有单独的人在处理 vip 会员的事情。但是他们都是会员。再比如一些客户可能需要专门的账单、付款条件和基于业务量的特别互动。我们可能安排最好的财务代表、甚至特别的经理负责一个或多个客户,以专门处理他们的独特需求。Z 轴主要解决数据集的扩展性。

Z 轴分割是成本最高的分割方向,Z 轴分割有助于提高交易和数据的可扩展性,如果实施得当也有助于扩展指令集和过程

Z 轴优点:解决单一数据集过大问题,可以应对数据指数增长。

Z 轴缺点:成本最高,很难解决指令集问题。

3 理论实践
通过上面的理论介绍,接下来指导我们对实际业务场景的拆分。

针对文章开头提到的某些大商户单子远远多余其他商户的情况,很显然这是数据集的扩展性导致的问题。

更应该在 Z 轴上进行扩展拆分,也就是通过商户的特殊性,进行再次拆分来平衡数据。

这里的特殊性可以是表中字段的某一个属性,比如订单编号、创建时间等等。这就需要我们根据实际情况,既要拆分的均匀又要拆分之后能满足未来几年的发展,同时还要满足现有业务的支持。

4 总结
通过对 AKF 模型的学习我们在工作实践中如果遇到类似的情况可以按照这个模型进行对系统拆分。当然我们也不要过度使用。不同的业务或者场景可能使用其中一个就足够用了,但是又有其他一些场景,已经按照 XYZ 轴拆分过一次了但是不够满足需求,可以再次在三个轴之一再次进行拆分,已达到满足业务需要的目的。

XYZ 三个轴的扩展方向每个都有优缺点,要准确识别场景进行使用,或结合使用互补优缺点。

相关文章
|
安全 机器人 测试技术
带你读《无人机网络与通信》之一:无人机系统概述
本书针对无人机系统两个关键问题—通信组网和管控体系做了比较全面和深入的描述和探讨,特别是以大量笔墨分析了现有无线通信解决方案,对比了不同通信协议,得出了很有价值的研究结论。无人机的跨越式发展将涉及公共安全管理的问题,构建管控体系是当务之急,分级管理以及制定相应的适航标准是一件大事情,本书对此也进行了系统的、建设性的讨论。未来,高档无人机和无人机集群将对环境具有更强的感知能力和自适应能力,还有对任务的自规划和学习、调整能力,本书讨论的内容将为它们的发明、部署和监督提供宝贵的信息。
10116 0
|
消息中间件 设计模式 移动开发
高德打车通用可编排订单状态机引擎设计
订单状态流转是交易系统的最为核心的工作,订单系统往往都会存在状态多、链路长、逻辑复杂的特点,还存在多场景、多类型、多业务维度等业务特性。在保证订单状态流转稳定性的前提下、可扩展性和可维护性是我们需要重点关注和解决的问题。
高德打车通用可编排订单状态机引擎设计
|
9月前
|
边缘计算 人工智能 物联网
Ultralytics YOLO26来啦!5种尺寸全家桶,速度与精度兼顾
Ultralytics发布YOLO26,系列迄今最先进、易部署的模型,支持分类、检测、分割、姿态估计等多任务。五种尺寸灵活适配边缘设备,CPU推理提速43%,首创无NMS端到端推理,移除DFL提升兼容性,已上架魔搭社区。(239字)
1960 14
|
9月前
|
人工智能 API
千问大模型以32%的份额位居中国企业级大模型调用份额第一
国际市场调研机构沙利文(Frost&Sullivan)发布了最新一期《中国GenAI市场洞察:企业级大模型调用全景研究2025H2》报告,调研用户通过公有云、本地部署、MaaS等使用大模型的不同方式,盘点中国企业级大模型调用市场的全景。2025年下半年,中国企业级市场大模型的日均总消耗量为37万亿Tokens,其中,千问大模型占比32.1%位列第一,成为目前中国企业选择最多的大模型。
|
存储 SQL 关系型数据库
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
MySQL如何进行分库分表、数据迁移?从相关概念、使用场景、拆分方式、分表字段选择、数据一致性校验等角度阐述MySQL数据库的分库分表方案。
一篇文章搞懂MySQL的分库分表,从拆分场景、目标评估、拆分方案、不停机迁移、一致性补偿等方面详细阐述MySQL数据库的分库分表方案
|
Java Maven
解决idea每次新建maven项目都需要重新配置maven的问题
解决idea每次新建maven项目都需要重新配置maven的问题
1054 2
|
Docker 容器
iterm通过代理访问网络
下载fabric的docker镜像的时候,mac已经开了代理,但速度还是巨慢,原来iterm通过代理访问网络还要单独设置,在~/.zshrc 或者~/.bash_profile 配置文件中添加如下配置:
iterm通过代理访问网络
|
消息中间件 SQL NoSQL
再记一次止于三面的阿里面试之旅
Hello 大家好,我是阿粉,最近心情不是很好,因为阿粉面试阿里三面挂掉了, 当收到下面这封邮件的时候阿粉内心是拔凉拔凉的。阿粉被 “Unfortunately”,“another candidate” 这几个词深深的伤害到了。不过伤心归伤心,该自我总结还是得自我总结的,有机会再战。
1414 0
|
存储 NoSQL Redis
redis zset底层数据结构
zset底层存储结构  zset底层的存储结构包括ziplist或skiplist,在同时满足以下两个条件的时候使用ziplist,其他时候使用skiplist,两个条件如下: 有序集合保存的元素数量小于128个 有序集合保存的所有元素的长度小于64字节  当ziplist作为zset的底层存储结构时候,每个集合元素使用两个紧挨在一起的压缩列表节点来保存,第一个节点保存元素的成员,第二个元素保存元素的分值。
16962 1
|
机器人
AC/DC电源模块的工作原理、特点和应用
AC/DC电源模块的工作原理、特点和应用。
AC/DC电源模块的工作原理、特点和应用