数据库读写分离同步延时问题怎么解决?

本文涉及的产品
云数据库 RDS MySQL,集群系列 2核4GB
推荐场景:
搭建个人博客
RDS MySQL Serverless 基础系列,0.5-2RCU 50GB
RDS MySQL Serverless 高可用系列,价值2615元额度,1个月
简介: 数据库读写分离是很多公司绕不过去的一个发展阶段,从单体数据库,到主备模式,再到读写分离,分库分表。每一个阶段都能为我们解决一些问题,但也带来了新的挑战。本篇文章我们就主要研究一下数据库读写分离及其带来的问题如何解决。

1 数据库架构的发展历程

首先简单介绍一下数据库架构的发展历程,基本就是单体、主备、读写分离、分库分表,下面我们分别进行介绍。

1.1 单体架构

image.png

业务发展初期,数据库的压力相对较小,这时候使用单独一个库就可以。

引出的问题:如果数据库出现故障,我们的业务就不能使用,只能说是停机重启修复故障。

1.2 主备架构

由于单体带出的问题,这时候我们就需要加一个备用库,紧急情况可以用备库顶上,相当于加一个替补队员。

image.png

通过MySQL自带的主从同步机制,就可以放我们的替补队员上线。

当正式队员(主库)发生故障,我们就可以人工让其下线,让替补队员(备库)顶上。

引出的问题:随着业务大规模爆发,主库的压力过大,我们就想让备库承担起更大的责任来。

1.3 读写分离架构

读写分离架构本质也就是主备架构,与主备架构没有本质区别,就是在主备架构的基础上,增加一层对读写请求的处理,使其能够更大程度上利用备用库为我们分担一些读的压力。

image.png

读写分离架构,需要在中间加一层控制读写请求的路由

1.4 分库分表

分库分表的本质上是切分数据,是由于数据量级的提升,不对数据切分会严重影响数据库读写性能。

甚至是如果不切分,磁盘、内存、CPU无法承载这样的压力,数据库随时在奔溃的边缘。

image.png

分库分表与前三者是有本质区别的,分库分表后每一个库分片都可以采取以上三种方式的任意一种,可以是单体分片,也可以是主备分片,也可以是做了读写分离的分片。

分库分表和前三者中的一种是共生的关系。

不知道如何进行分库分表设计的可以读我之前的这篇文章《收好这份武林秘籍,让你分库分表再无烦恼》

2 读写分离设计方案

主从复制是MySQL数据库自带的功能,但是想要做读写分离就需要我们自己做一些工作配合MySQL主从同步配合使用。可选择的方案有很多。

2.1 代理

在应用程序和数据库之间增加代理层,代理层接收应用程序对数据库的请求,根据不同请求类型转发到不同的实例,实现读写分离的同时还可以实现负载均衡(读请求按照负载均衡的规则传入各个从节点)。

代理也就是借助中间件的方式,控制不同类型请求,进入不同的数据库。

目前常用的mysql的读写分离中间件有:

  • MySQL-Proxy

    MySQL自己的一个开源项目,通过其自带的Lua脚本进行SQL判断

  • Atlas

    Qihoo 360,在mysql-proxy 0.8.2版本的基础上,对其进行了优化,增加了一些新的功能特性。

  • MyCat
  • MaxScale

    MariaDB 开发

  • Amoeba

    阿里开发

  • ...

2.2 应用内路由

在程序中进行控制,我们利用持久层框架的拦截器实现,动态路由不同数据源。

利用Sharding-JDBC也可以实现

实现思路:

  • 配置多数据源
  • 设置默认的数据源,配置数据源的切换策略
  • 拦截进入数据库的请求,根据业务需求设置走哪个数据源。

3 读写分离造成的读延迟怎么办?

凡是采用读写分离架构,就会有同步延迟问题,我们只能想办法去克服这个问题。

3.1 数据同步写入从库

主从复制模式,一般都是异步写数据到从库,当然这个异步也可以设置为同步,只有当从库写完成,主库上的写请求才能返回。

这种方案是最佳单也是最有效的一种,但也是性能最差的一种,尤其是有大量从库的情况下,严重影响请求效率。

3.2 缓存(中间件)路由法

写请求时缓存记录一个key,这个key的失效时间设置为主从同步的延时,读请求的时候先去缓存中确认是否存在key,如果key存在说明发生了写请求,数据未同步到从库,这时走主库即可,若不存在这个key,直接走从库的查询即可。

中间件应该也是可以判断是否同步完成,与使用缓存记录类似。

这种方案最大的弊端是引入了缓存,系统复杂度上升。

3.3 选择性强制读主库

对于一些特殊的业务场景,采用强制读主库。

弊端,需要把每一个这种情况都找出来,设置成强制走主库。

3.4 等GTID 方案

MySQL 在执行完事务后,会将该事务的 GTID 会给客户端,然后客户端可以使用该命令去要执行读操作的从库中执行,等待该 GTID,等待成功后,再执行读操作;如果等待超时,则去主库执行读操作,或者再换一个从库执行上述流程。

MariaDB 的 MaxScale 就是使用该方案,MaxScale 是 MariaDB 开发的一个数据库智能代理服务(也支持 MySQL),允许根据数据库 SQL 语句将请求转向目标一个到多个服务器,可设定各种复杂程度的转向规则。

3.5 以不变应万变

有延迟就有延迟,对数据强一致性要求不高的场景可以放任不管。

相关实践学习
如何快速连接云数据库RDS MySQL
本场景介绍如何通过阿里云数据管理服务DMS快速连接云数据库RDS MySQL,然后进行数据表的CRUD操作。
全面了解阿里云能为你做什么
阿里云在全球各地部署高效节能的绿色数据中心,利用清洁计算为万物互联的新世界提供源源不断的能源动力,目前开服的区域包括中国(华北、华东、华南、香港)、新加坡、美国(美东、美西)、欧洲、中东、澳大利亚、日本。目前阿里云的产品涵盖弹性计算、数据库、存储与CDN、分析与搜索、云通信、网络、管理与监控、应用服务、互联网中间件、移动服务、视频服务等。通过本课程,来了解阿里云能够为你的业务带来哪些帮助     相关的阿里云产品:云服务器ECS 云服务器 ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,助您降低 IT 成本,提升运维效率,使您更专注于核心业务创新。产品详情: https://www.aliyun.com/product/ecs
目录
相关文章
|
4月前
|
canal 缓存 NoSQL
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
根据对一致性的要求程度,提出多种解决方案:同步删除、同步删除+可靠消息、延时双删、异步监听+可靠消息、多重保障方案
Redis缓存与数据库如何保证一致性?同步删除+延时双删+异步监听+多重保障方案
|
5月前
|
运维 监控 NoSQL
【MongoDB 复制集秘籍】Secondary 同步慢怎么办?深度解析与实战指南,让你的数据库飞速同步!
【8月更文挑战第24天】本文通过一个具体案例探讨了MongoDB复制集中Secondary成员同步缓慢的问题。现象表现为数据延迟增加,影响业务运行。经分析,可能的原因包括硬件资源不足、网络状况不佳、复制日志错误等。解决策略涵盖优化硬件(如增加内存、升级CPU)、调整网络配置以减少延迟以及优化MongoDB配置(例如调整`oplogSize`、启用压缩)。通过这些方法可有效提升同步效率,保证系统的稳定性和性能。
146 4
|
2月前
|
缓存 关系型数据库 MySQL
高并发架构系列:数据库主从同步的 3 种方案
本文详解高并发场景下数据库主从同步的三种解决方案:数据主从同步、数据库半同步复制、数据库中间件同步和缓存记录写key同步,旨在帮助解决数据一致性问题。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
高并发架构系列:数据库主从同步的 3 种方案
|
3月前
|
算法 大数据 数据库
云计算与大数据平台的数据库迁移与同步
本文详细介绍了云计算与大数据平台的数据库迁移与同步的核心概念、算法原理、具体操作步骤、数学模型公式、代码实例及未来发展趋势与挑战。涵盖全量与增量迁移、一致性与异步复制等内容,旨在帮助读者全面了解并应对相关技术挑战。
70 3
|
5月前
|
C# 开发者 Windows
全面指南:WPF无障碍设计从入门到精通——让每一个用户都能无障碍地享受你的应用,从自动化属性到焦点导航的最佳实践
【8月更文挑战第31天】为了确保Windows Presentation Foundation (WPF) 应用程序对所有用户都具备无障碍性,开发者需关注无障碍设计原则。这不仅是法律要求,更是社会责任,旨在让技术更人性化,惠及包括视障、听障及行动受限等用户群体。
111 0
|
5月前
|
SQL DataWorks 关系型数据库
DataWorks操作报错合集之如何处理在DI节点同步到OceanBase数据库时,出现SQLException: Not supported feature or function
DataWorks是阿里云提供的一站式大数据开发与治理平台,支持数据集成、数据开发、数据服务、数据质量管理、数据安全管理等全流程数据处理。在使用DataWorks过程中,可能会遇到各种操作报错。以下是一些常见的报错情况及其可能的原因和解决方法。
101 0
|
6月前
|
消息中间件 关系型数据库 数据库
实时计算 Flink版操作报错合集之在使用RDS数据库作为源端,遇到只能同步21个任务,是什么导致的
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
6月前
|
消息中间件 关系型数据库 MySQL
实时计算 Flink版产品使用问题之从MySQL数据库中捕获变更数据并进行实时处理如何按天分表同步CDC数据
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
6月前
|
关系型数据库 MySQL 数据库
MybatisPlus添加数据数据库没有数据,数据消失,使用Navicate看不到数据,Navicate中Mysql的数据与idea的数据不一定同步,Navicate与idea的数据库同步,其实有分页
MybatisPlus添加数据数据库没有数据,数据消失,使用Navicate看不到数据,Navicate中Mysql的数据与idea的数据不一定同步,Navicate与idea的数据库同步,其实有分页
|
7月前
|
关系型数据库 分布式数据库 数据库
PolarDB产品使用问题之迁移后数据库数据不同步是什么导致的
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。

热门文章

最新文章