数据库分布式架构巧设计,水平拆分不再难

本文涉及的产品
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
云原生数据库 PolarDB 分布式版,标准版 2核8GB
简介: 在阿里云生态日,袋鼠云首席数据库架构师赵晓宏分享了《高容量大并发数据库服务——数据库分布式架构设计》。他从分布式需求、拆分原则、拆分难点及解决方案、数据库规范设计、运维相关五个方面进行了分享。在分享中,他主要介绍了水平拆分的原则以及解决方案,分享了DRDS的架构与实践。

在阿里云生态日,袋鼠云首席数据库架构师赵晓宏分享了《高容量大并发数据库服务——数据库分布式架构设计》。他从分布式需求、拆分原则、拆分难点及解决方案、数据库规范设计、运维相关五个方面进行了分享。在分享中,他主要介绍了水平拆分的原则以及解决方案,分享了DRDS的架构与实践。

 

以下内容根据直播视频整理而成。

 

分布式需求

为什么要做分布式?首先是因为高并发,分布式应用带来更大量的数据库请求;高容量,业务增长,产生大量在线数据,关系型数据库要支持业务就要支持大数据量的存储;资源向上扩展存在天花板,无法做到无限制的纵向扩展;支撑业务高速发展,平滑扩容。

拆分原则

051b421049878add9a7e33b37e6148ace02858ca

上图是数据库改造的进阶。业务初期,客户量比较少,可能在一个实例上把所有的服务、数据都能存放下来并且支持业务的发展。当客户量和数据量变大时,数据库很容易成为一个瓶颈,怎么去做改造?建议先做服务化的改造,不同的业务模块做一个垂直的梳理,不同服务的数据库相互隔离,中间的交互由业务去实现,这样数据库就可以分布在不同的实例上,并且可以支持相对较高的并发和容量。再往上发展时,单实例依然是一个瓶颈,此时要考虑做一个水平的拆分,把一个服务的数据分布在不同的实例上。拆分需要循序渐进,先垂直后水平,防止过度设计,紧密结合业务及应用架构设计。

拆分难点及解决方案

水平拆分难点

首先是系统复杂度增大,系统架构设计需要彻底的重构;技术挑战,应用需要处理复杂的分布式逻辑;稳定性挑战;分布式的局限性,不支持跨库join、分布式事务、全局sequence等。

解决方案:客户端实现数据路由

825db0289a9d5aad234f3c55321eae1f3c48052d

该方案的优点是不需要引入中间件,直接在客户端配置,程序把控力强,简单场景方便使用。缺点是对代码侵入性强,因为代码端要去管理路由;配置管理复杂,如果配置错误,数据可能完全乱掉,修复也会比较复杂。

解决方案:数据库中间件

b53e3666f239a0fc291edc0163b6f65b6dc52825

使用中间件可以实现自动的分库分表,对应用透明,使用类似于单实例;使用门槛低,应用只需要考虑分布式事务,跨库join,而不用考虑数据的路由;方便水平扩容。使用了中间件之后,应用看到的还是单实例数据库,不需要考虑分布式的情况,对开发来说是比较有优势的。

水平切分原理及设计原则

3146548d78dd526e230b1d3c5226d130382ba703

数据库拆分都是用字段hash把数据分配到不同的底层库。选择的原则是拆分尽量均匀并且一次查询尽量落到单实例库上,这样能够更快的返回,而且有更大的并发。那么,中间件怎么实现数据库的分布式?如上图所示,选择了MEMBE_ID字段,将字段值做一个hash分类到不同库中。比如发出查询test1234的请求,就会直接转到库1里。

数据访问——SQL转发

8d9bceb8987f9a62044ea888c33c56e115017fc2

当我们输入一个SQL语句:select * from tb1 where member_id =‘test1234’,APP输入请求会转到中间件,中间件会对这条SQL语句进行解析,按照路由规则把这条请求分发到底层的数据库,库2还有一个请求是查询MEMBE_ID是1234的数据。最终的查询结果会返回DRDS层做一个聚合,速度也比较快。

DRDS

阿里云的DRDS是淘宝积累多年的产品。DRDS具有五大功能:分库分表,DRDS的核心功能,支持数据的多维度切分和路由访问;内建读写分离功能,可以灵活配置访问权重;自带全局唯一ID组件,DRDS层维护全局的sequence;小表广播,查询引擎识别和下推复杂查询,兼容98% MySQL语法;弹性扩容组件实现自动化在线水平扩容。

3a759a8a5907a06c4b9f5453992cafae93016431

DRDS框架如上图所示。网络层完全兼容MySQL协议,可以做SQL解析、执行计划,实现路由功能来决定SQL分配到一个库还是多个库。结果集处理包括排序、聚合等动作,此外还支持一些管理工作。底层依赖MySQL协议和底层物理库通信。

8bf0dbbec7453c9d30605f8e509b9a238d5dd252

DRDS物理层框架上层是应用服务器,连接DRDS的一个集群。DRDS是集群式的,不是主备,保证了可扩展和高可用性。集群连接的是底层的MySQL。

7d19e61da0f0d6737ebfa7f2abe64d2ed5cd21ac

主库和读库是使用数据库的原生复制实现的,数据是强一致的。DRDS会自动判断请求,然后做一个分发,事务型的操作会全部路由到一个主库上。

f6058e129dcf175f9d276ca93b14190bfc653a70

下推join是指把join从DRDS层往下,在MySQL层实现join。所以,在业务设计上要避免跨库join,比如有两张表join,则必须保证有相同的拆分原则,上图中table1和table2都是根据ID做拆分,相同的ID分配到相同的数据库。

4da74954cf9a50cd6e24065a9080bf189d2ed590

广播表也是避免跨库join的一个方法。上图中,table1已经做过拆分,table2没有做过拆分,它是一个小表,我们可以把它的数据完全冗余到每一个库里面,那么任何一个跟table2做join的查询都能在一个库去实现。最后,把结果在DRDS层做聚合。

数据库规范设计:最佳实践

查询应尽可能带上分库条件,如果说一个表拆分到底层10个库,每次查询如果都带上分库条件的话DRDS很轻易把这个请求路由到底层库上,如果没有分库条件,DRDS不知道数据到底存放在哪里,这样的话会分别从10个库取数据,然后在DRDS层做聚合,网络、计算的开销比较大。Join有几种解决方案:尽可能参与Join的每张表都带上相同的分库条件,这样就还会限定在一个库里面;分库键=分库键的Join;广播表Join。单库事务尽量限制在单库范围内,避免引入分布式事务。

运维相关

cc0a3c09e4ce243441cb6aa2fc97b3c18b0c3913

DRDS支持直接实例的创建、释放以及拆分库的创建、建表的接入。数据运维支持导入、扩容、小表复制(即小表广播,DRDS层自己实现数据的复制)、规格升级(纵向的升级)。数据服务包括分库分表、读写分离、异构索引(从不同的维度在大表中查询,如何选择拆分?异构索引底层也是做数据冗余,根据不同的拆分情况做查询)、DRDS指令。

b290b92d16b387b8fda542d0fcfc5362ff18f094

EasyDB 是数据库的自动化管理平台,支持Oracle和MySQL、Redis,能够实现基本的监控、审计、备份、高可用、一键切换、资源管理。
相关实践学习
快速体验PolarDB开源数据库
本实验环境已内置PostgreSQL数据库以及PolarDB开源数据库:PolarDB PostgreSQL版和PolarDB分布式版,支持一键拉起使用,方便各位开发者学习使用。
相关文章
|
7天前
|
存储 Prometheus Cloud Native
分布式系统架构6:链路追踪
本文深入探讨了分布式系统中的链路追踪理论,涵盖追踪与跨度的概念、追踪系统的模块划分及数据收集的三种方式。链路追踪旨在解决复杂分布式系统中请求流转路径不清晰的问题,帮助快速定位故障和性能瓶颈。文中介绍了基于日志、服务探针和边车代理的数据收集方法,并简述了OpenTracing、OpenCensus和OpenTelemetry等链路追踪协议的发展历程及其特点。通过理解这些概念,可以更好地掌握开源链路追踪框架的使用。
58 41
|
4月前
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
4月前
|
负载均衡 Java 应用服务中间件
微服务分布式系统架构之zookeeper与dubbor-1
微服务分布式系统架构之zookeeper与dubbor-1
|
4月前
|
NoSQL 关系型数据库 MySQL
微服务架构下的数据库选择:MySQL、PostgreSQL 还是 NoSQL?
在微服务架构中,数据库的选择至关重要。不同类型的数据库适用于不同的需求和场景。在本文章中,我们将深入探讨传统的关系型数据库(如 MySQL 和 PostgreSQL)与现代 NoSQL 数据库的优劣势,并分析在微服务架构下的最佳实践。
|
17天前
|
设计模式 存储 算法
分布式系统架构5:限流设计模式
本文是小卷关于分布式系统架构学习的第5篇,重点介绍限流器及4种常见的限流设计模式:流量计数器、滑动窗口、漏桶和令牌桶。限流旨在保护系统免受超额流量冲击,确保资源合理分配。流量计数器简单但存在边界问题;滑动窗口更精细地控制流量;漏桶平滑流量但配置复杂;令牌桶允许突发流量。此外,还简要介绍了分布式限流的概念及实现方式,强调了限流的代价与收益权衡。
60 11
|
19天前
|
设计模式 监控 Java
分布式系统架构4:容错设计模式
这是小卷对分布式系统架构学习的第4篇文章,重点介绍了三种常见的容错设计模式:断路器模式、舱壁隔离模式和重试模式。断路器模式防止服务故障蔓延,舱壁隔离模式通过资源隔离避免全局影响,重试模式提升短期故障下的调用成功率。文章还对比了这些模式的优缺点及适用场景,并解释了服务熔断与服务降级的区别。尽管技术文章阅读量不高,但小卷坚持每日更新以促进个人成长。
45 11
|
21天前
|
消息中间件 存储 安全
分布式系统架构3:服务容错
分布式系统因其复杂性,故障几乎是必然的。那么如何让系统在不可避免的故障中依然保持稳定?本文详细介绍了分布式架构中7种核心的服务容错策略,包括故障转移、快速失败、安全失败等,以及它们在实际业务场景中的应用。无论是支付场景的快速失败,还是日志采集的安全失败,每种策略都有自己的适用领域和优缺点。此外,文章还为技术面试提供了解题思路,助你在关键时刻脱颖而出。掌握这些策略,不仅能提升系统健壮性,还能让你的技术栈更上一层楼!快来深入学习,走向架构师之路吧!
55 11
|
23天前
|
自然语言处理 负载均衡 Kubernetes
分布式系统架构2:服务发现
服务发现是分布式系统中服务实例动态注册和发现机制,确保服务间通信。主要由注册中心和服务消费者组成,支持客户端和服务端两种发现模式。注册中心需具备高可用性,常用框架有Eureka、Zookeeper、Consul等。服务注册方式包括主动注册和被动注册,核心流程涵盖服务注册、心跳检测、服务发现、服务调用和注销。
62 12
|
1月前
|
消息中间件 架构师 数据库
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
45岁资深架构师尼恩分享了一篇关于分布式事务的文章,详细解析了如何在10Wqps高并发场景下实现分布式事务。文章从传统单体架构到微服务架构下分布式事务的需求背景出发,介绍了Seata这一开源分布式事务解决方案及其AT和TCC两种模式。随后,文章深入探讨了经典ebay本地消息表方案,以及如何使用RocketMQ消息队列替代数据库表来提高性能和可靠性。尼恩还分享了如何结合延迟消息进行事务数据的定时对账,确保最终一致性。最后,尼恩强调了高端面试中需要准备“高大上”的答案,并提供了多个技术领域的深度学习资料,帮助读者提升技术水平,顺利通过面试。
本地消息表事务:10Wqps 高并发分布式事务的 终极方案,大厂架构师的 必备方案
|
1月前
|
存储 算法 安全
分布式系统架构1:共识算法Paxos
本文介绍了分布式系统中实现数据一致性的重要算法——Paxos及其改进版Multi Paxos。Paxos算法由Leslie Lamport提出,旨在解决分布式环境下的共识问题,通过提案节点、决策节点和记录节点的协作,确保数据在多台机器间的一致性和可用性。Multi Paxos通过引入主节点选举机制,优化了基本Paxos的效率,减少了网络通信次数,提高了系统的性能和可靠性。文中还简要讨论了数据复制的安全性和一致性保障措施。
43 1
下一篇
开通oss服务