分库表数据倾斜的处理让我联想到了 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 三个轴的扩展方向每个都有优缺点,要准确识别场景进行使用,或结合使用互补优缺点。

相关文章
|
SQL 消息中间件 分布式计算
12中方法,彻底搞定数据倾斜!
12中方法,彻底搞定数据倾斜!
|
缓存 JavaScript Windows
windows环境下NPM / NodeJS的安装配置
npm(node package manager):nodejs的包管理器,用于node插件管理(包括安装、卸载、管理依赖等) 本文主要讲解如何搭建npm环境
7776 0
windows环境下NPM / NodeJS的安装配置
|
分布式计算 前端开发 Hadoop
【细节拉满】Hadoop课程设计项目,使用idea编写基于MapReduce的学生成绩分析系统(附带源码、项目文件下载地址)(三)
【细节拉满】Hadoop课程设计项目,使用idea编写基于MapReduce的学生成绩分析系统(附带源码、项目文件下载地址)(三)
972 0
|
11月前
|
存储 NoSQL 算法
阿里面试:亿级 redis 排行榜,如何设计?
本文由40岁老架构师尼恩撰写,针对近期读者在一线互联网企业面试中遇到的高频面试题进行系统化梳理,如使用ZSET排序统计、亿级用户排行榜设计等。文章详细介绍了Redis的四大统计(基数统计、二值统计、排序统计、聚合统计)原理和应用场景,重点讲解了Redis有序集合(Sorted Set)的使用方法和命令,以及如何设计社交点赞系统和游戏玩家排行榜。此外,还探讨了超高并发下Redis热key分治原理、亿级用户排行榜的范围分片设计、Redis Cluster集群持久化方式等内容。文章最后提供了大量面试真题和解决方案,帮助读者提升技术实力,顺利通过面试。
|
存储 Java 应用服务中间件
Java规则引擎Drools急速入门
Java规则引擎Drools急速入门
Java规则引擎Drools急速入门
|
设计模式 自然语言处理 Java
递归下降解析器的设计与实现
递归下降解析器的设计与实现
|
SQL 存储 缓存
聊聊分库分表后非Sharding Key查询的三种方案~(建议收藏)
聊聊分库分表后非Sharding Key查询的三种方案~(建议收藏)
1278 0
|
消息中间件 缓存 NoSQL
分布式事务 3PC
3PC(Three-Phase Commit)是一种增强型的2PC(Two-Phase Commit)协议,用于解决2PC协议存在的可靠性问题和性能问题。3PC协议将2PC协议的两个阶段分为了三个阶段,同时引入了超时机制,从而提高了协议的可靠性和容错性。
261 0
|
SQL 数据采集 算法
Mysql主从同步及主从同步延迟解决方案
Mysql主从同步及主从同步延迟解决方案
801 0
Mysql主从同步及主从同步延迟解决方案
|
消息中间件 JavaScript 前端开发
SpringBoot+Vue 实现网页版人脸登录、人脸识别,逼格很高!!!
SpringBoot+Vue 实现网页版人脸登录、人脸识别,逼格很高!!!