MySQL主从原理及保证数据一致性问题

一.MySQL主从原理

二.怎样利用缓存保证数据的一致性

前言:今天单就MySQL主从及原理和遇到问题分析下,当然要支撑高并发仅仅靠MySQL是不可行的,上家公司用的是 MySQL+Nginx+redis+rabitMQ+elasticsearch+mongoDB等来支撑高并发;根据业务场景组合拳吧,下面进入正题.....

如果想从MySQL方便做到支持一定量的并发,那么必然会想到:读写分离

MySQL 做读写分离的前提,是把 MySQL 集群拆分成“主 + 从”结构的数据集群,这样才能实现程序上的读写分离,并且 MySQL 集群的主库、从库的数据是通过主从复制实现同步的。

在面试过程中,我们一般会被问到:

@1.你们公司MySQL有几台从库?每台从库作用是什么?(考察你对你用的系统熟悉程度)

@2.主从复制过程原理是什么?(考察你的基础知识)

总的来讲,MySQL 的主从复制依赖于 binlog ,也就是记录 MySQL 上的所有变化并以二进制形式保存在磁盘上。复制的过程就是将 binlog 中的数据从主库传输到从库上。这个过程一般是异步的,也就是主库上执行事务操作的线程不会等待复制 binlog 的线程同步完成。

上家公司用的一般是1主1从1备份,个别的实例和库会有多个从库;

主从复制大概分三个过程:

a:MySQL 主库在收到客户端提交事务的请求之后,会先写入 binlog,再提交事务,更新存储引擎中的数据,事务提交完成后,返回给客户端“操作成功”的响应。

b:从库会创建一个专门的 I/O 线程,连接主库的 log dump 线程,来接收主库的 binlog 日志,再把 binlog 信息写入 relay log 的中继日志里,再返回给主库“复制成功”的响应。

c:从库会创建一个用于回放 binlog 的线程,去读 relay log 中继日志,然后回放 binlog 更新存储引擎中的数据,最终实现主从的数据一致性。

下面找了张图:

在完成主从复制之后,你就可以在写数据时只写主库,在读数据时只读从库,这样即使写请求会锁表或者锁记录,也不会影响读请求的执行。

那么写入binlog日志记录数据方式有哪几种勒?

  1. statement: 会将对数据库操作的sql语句写道binlog中
  2. row: 会将每一条数据的变化写道binlog中。
  3. mixed: statement与row的混合。Mysql决定何时写statement格式的binlog, 何时写row格式的binlog。(MySQL4.0版本后)

既然可以有多个从库,那大促流量大时,是不是只要多增加几台从库,就可以抗住大促的并发读请求了?why?

当然不是;因为:

从库数量增加,从库连接上来的 I/O 线程也比较多,主库也要创建同样多的 log dump 线程来处理复制的请求,对主库资源消耗比较高,同时还受限于主库的网络带宽。所以在实际使用中,一个主库一般跟 2~3 个从库(1 套数据库,1 主 2 从 1 备主),这就是一主多从的 MySQL 集群结构。

MySQL 主从复制还有哪些模型?

主要有三种;

@1:同步复制:事务线程要等待所有从库的复制成功响应。

@2:异步复制:事务线程完全不等待从库的复制成功响应。

@3:半同步复制:MySQL 5.7 版本之后增加的一种复制方式,介于两者之间,事务线程不用等待所有的从库复制成功响应,只要一部分复制成功响应回来就行,比如一主二从的集群,只要数据成功复制到任意一个从库上,主库的事务线程就可以返回给客户端。

主从必会遇到主从延迟问题,怎么解决?

使用缓存解决;(通过缓存解决 MySQL 主从复制延迟时,会出现数据库与缓存数据不一致的情况,所以这块要处理好)

 那么怎么保证redis的数据一致性,且听寡人缓缓道来。。

前言:缓存机制是互联网搬砖人必须要掌握的基础知识之一,在使用Redis中间件时数据的幂等性问题是每个搬砖人应该掌握的。本篇文章围绕一致性问题逐步引入讲解下Redis的一致性问题。

首先思考下为啥要使用缓存?

存储如mysql通常支持完整的ACID特性,因为可靠性,持久性等因素,性能普遍不高,高并发的查询会给mysql带来压力,造成数据库系统的不稳定。同时也容易产生延迟。根据局部性原理,80%请求会落到20%的热点数据上,在读多写少场景,增加一层缓存非常有助提升系统吞吐量和健壮性。

通常的开发模式中,都会使用mysql作为存储,而redis作为缓存,加速和保护mysql。但是,当mysql数据更新之后,redis怎么保持同步呢。强一致性同步成本太高,如果追求强一致,那么没必要用缓存了,直接用mysql即可。通常考虑的,都是最终一致性。

本篇列举三种方案解决一致性问题分析。在面试过程中,面试官可能会一一列举出来锤炼我们。所以我们必须都要去了解,然后拿出我胡汉三怕过谁的气势征服他们。

以下是三种方案:

1. 先更新数据库,再更新缓存
2. 先删除缓存,再更新数据库
3. 先更新数据库,再删除缓存

方案一:先更新数据库,再更新缓存
1、A更新数据库数据为a
2、B更新数据库数据为b
3、B更新缓存数据为b
4、A更新缓存数据为a
问题:这就出现请求A更新缓存应该比请求B更新缓存早才对,但是因为网络等原因,B却比A更早更新了缓存。会导致了脏数据,本方案可靠性不高。

方案二:先删除缓存,再更新数据库
1、A删除缓存
2、B查询缓存未查到
3、B查询数据库为b,并更新缓存
4、A修改数据库为a
问题:最终,数据库数据为a,而缓存数据为b
有个延时策略可以解决这个方法,就是在更新数据库之后,定时任务(例如1s后)执行删除缓存,把这期间保存的缓存数据删除掉,这个1s时间需要自己估项目的读数据业务逻辑的耗时。

针对删除失败,需要考虑到重试机制,详细见方案三。

方案三:先更新数据库,再删除缓存
1、缓存失效
2、A未查询到缓存,查询数据库
3、B更新数据库
4、B删除缓存
5、A更新缓存

问题:如果删除缓存出现异常呢?

我们可以基于通过使用 Canal 组件来获读取最新的 Binlog 日志数据添加到队列中来实现一套方案。

找了一张不错的图如下:

  • 1
    点赞
  • 21
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
### 回答1: mysql主从复制可以通过以下几种方式来保持数据的一致性: 1. 在主库上开启 binlog,从库上开启 relay log,通过 binlog 和 relay log 来同步数据。 2. 在主库上开启 GTID,从库上也开启 GTID,通过 GTID 来同步数据。 3. 在主库上开启半同步复制,从库上开启半同步复制,通过半同步复制来保证数据一致性。 4. 在主库和从库上都开启并行复制,通过并行复制来加快数据同步的速度。 以上几种方式都可以保证数据一致性,具体选择哪种方式需要根据实际情况来决定。 ### 回答2: MySQL主从复制是一种数据同步的机制,数据的一致性是保证主库和从库之间数据完全一致的关键要素。 首先,MySQL使用二进制日志(binary log)记录主库上发生的所有操作,并将这些操作传递给从库进行重放。这确保了主库和从库拥有相同的数据集。 其次,MySQL主从复制通过复制事件(replication event)对数据进行同步。在主库上执行的每个数据库操作都被记录为一个事件,并按照顺序传递给从库进行执行。这样,不论是数据的插入、更新还是删除操作,从库都能按照相同的顺序和方式执行,保持数据的一致性。 此外,MySQL主从复制采用基于事务的方式进行数据复制。主库上执行的每个事务都会被记录为一个复制事件,并且这些事务在从库上以相同的顺序和方式执行,从而确保数据的一致性。 在主从复制中,还存在一个重要的因素是延迟(lag)。由于网络、硬件等原因,从库上执行复制事件可能会有一定的延迟。为了保持数据的一致性,需要通过设置参数和监控机制,确保从库上的延迟不会影响主库和从库之间的数据一致性。 同时,为了避免主库的故障导致数据丢失,MySQL提供了半同步复制(semi-synchronous replication)机制。通过将事务在主库上的提交确认同步到至少一个从库后再返回给客户端,确保了主库上的数据改变已经有效地被至少一个从库接收,从而提高了数据的一致性和可靠性。 综上所述,MySQL主从复制通过二进制日志记录、复制事件同步、基于事务的复制和延迟监控,以及半同步复制等机制,保证了数据在主库和从库之间的一致性。 ### 回答3: MySQL主从复制是一种常用的数据复制方案,用于同步将一个数据库的变更应用到其他多个数据库上。为了保持数据的一致性MySQL主从复制采用了以下几个机制: 1. 二进制日志(Binary Log):主服务器将所有的数据更新操作(如插入、更新、删除等)记录在二进制日志中,并定期将其发送给从服务器。从服务器通过读取主服务器的二进制日志,将这些操作逐一应用到自己的数据库中。这保证了数据的变更在从服务器上按照相同的顺序被执行。 2. GTID(Global Transaction Identifier):GTID是一个全局事务标识符,用于跟踪主服务器上的每个事务操作。主服务器在每个事务的开始和结束时生成一个GTID,并发送给从服务器。从服务器通过比较主服务器和自己的GTID来判断是否已经应用了相应的事务操作,以避免重复应用。 3. 复制线程和日志解析器:MySQL从服务器通过启动一个复制线程(I/O Thread)与主服务器建立连接,并通过日志解析器(SQL Thread)解析并执行主服务器发来的二进制日志。这两个线程协同工作,确保数据的变更被正确地复制到从服务器。 4. 延迟监控和错误检测:MySQL主从复制提供了延迟监控功能,可以检测从服务器与主服务器之间的延迟情况。如果发生网络故障或其他错误,复制过程可能会中断或延迟,MySQL会自动检测并尝试重新连接。同时,还可以通过配置参数来设置复制过程的超时时间,确保数据同步的正常性和一致性。 综上所述,MySQL主从复制通过二进制日志、GTID、复制线程和日志解析器、延迟监控和错误检测等机制来保持数据的一致性。这些机制确保了主服务器上的数据变更能够同步地应用到从服务器上,从而达到数据的一致性和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值