网站建设 wordpress系统,长清做网站公司,去哪儿旅行app下载安装,电商建站【Redis】高可用#xff1a;主从复制详解
我们知道要避免单点故障#xff0c;即保证高可用#xff0c;便需要冗余#xff08;副本#xff09;方式提供集群服务。而Redis 提供了主从库模式#xff0c;以保证数据副本的一致#xff0c;主从库之间采用的是读写分离的方式。…【Redis】高可用主从复制详解
我们知道要避免单点故障即保证高可用便需要冗余副本方式提供集群服务。而Redis 提供了主从库模式以保证数据副本的一致主从库之间采用的是读写分离的方式。本文主要阐述Redis的主从复制。 文章目录【Redis】高可用主从复制详解搭建主从架构主从复制概述主从复制原理全量复制增量复制更深入理解命令传播分摊主服务器的压力为什么主从全量复制使用RDB而不使用AOF当主服务器不进行持久化时复制的安全性读写分离及其中的问题主从机制优缺点小结面试题Redis主从节点时长连接还是短连接怎么判断 Redis 某个节点是否正常工作主从复制架构中过期key如何处理Redis 是同步复制还是异步复制主从复制中两个 Buffer(replication buffer 、repl backlog buffer)有什么区别如何应对主从数据不一致主从切换如何减少数据丢失异步复制同步丢失集群产生脑裂数据丢失主从如何做到故障自动切换搭建主从架构
例如现在有实例 1ip172.16.19.3和实例 2ip172.16.19.5我们在实例 2 上执行以下这个命令后实例 2 就变成了实例 1 的从库并从实例 1 上复制数据
replicaof 172.16.19.3 6379主从复制概述
**主从复制**是指将一台Redis服务器的数据复制到其他的Redis服务器。前者称为主节点(master)后者称为从节点(slave)数据的复制是单向的只能由主节点到从节点。
主从复制的作用主要包括
数据冗余主从复制实现了数据的热备份是持久化之外的一种数据冗余方式。故障恢复当主节点出现问题时可以由从节点提供服务实现快速的故障恢复实际上是一种服务的冗余。负载均衡 在主从复制的基础上配合读写分离可以由主节点提供写服务由从节点提供读服务即写Redis数据时应用连接主节点读Redis数据时应用连接从节点分担服务器负载尤其是在写少读多的场景下通过多个从节点分担读负载可以大大提高Redis服务器的并发量。高可用基石除了上述作用以外主从复制还是哨兵和集群能够实施的基础因此说主从复制是Redis高可用的基础。
不过由于数据都是存储在一台服务器上如果出事就完犊子了比如
如果服务器发生了宕机由于数据恢复是需要点时间那么这个期间是无法服务新的请求的如果这台服务器的硬盘出现了故障可能数据就都丢失了。
要避免这种单点故障最好的办法是将数据备份到其他服务器上让这些服务器也可以对外提供服务这样即使有一台服务器出现了故障其他服务器依然可以继续提供服务。 主从库之间采用的是读写分离的方式。
读操作主库、从库都可以接收写操作首先到主库执行然后主库将写操作同步给从库。 主从复制原理
全量同步复制比如第一次同步时增量同步复制只会把主从库网络断连期间主库收到的命令同步给从库
Redis主从复制的工作流程大概可以分为如下几步 保存主节点master信息 这一步只是保存主节点信息保存主节点的ip和port。主从建立连接 从节点slave发现新的主节点后会尝试和主节点建立网络连接。发送ping命令 连接建立成功后从节点发送ping请求进行首次通信主要是检测主从之间网络套接字是否可用、主节点当前是否可接受处理命令。权限验证 如果主节点要求密码验证从节点必须正确的密码才能通过验证。同步数据集 主从复制连接正常通信后主节点会把持有的数据全部发送给从节点。命令持续复制 接下来主节点会持续地把写命令发送给从节点保证主从数据一致性。
全量复制
主从第一次建立连接时会执行全量同步将master节点的所有数据都拷贝给slave节点流程 这里有一个问题master如何得知salve是第一次来连接呢
有几个概念可以作为判断依据
Replication Id简称replid是数据集的标记id一致则说明是同一数据集。每一个master都有唯一的replidslave则会继承master节点的replidoffset偏移量随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset说明slave数据落后于master需要更新。
因此slave做数据同步必须向master声明自己的replication id 和offsetmaster才可以判断到底需要同步哪些数据。
因为slave原本也是一个master有自己的replid和offset当第一次变成slave与master建立连接时发送的replid和offset是自己的replid和offset。
master判断发现slave发送来的replid与自己的不一致说明这是一个全新的slave就知道要做全量同步了。
master会将自己的replid和offset都发送给这个slaveslave保存这些信息。以后slave的replid就与master一致了。
因此master判断一个节点是否是第一次同步的依据就是看replid是否一致。 完整流程描述
slave节点请求增量同步master节点判断replid发现不一致拒绝增量同步master将完整内存数据生成RDB发送RDB到slaveslave清空本地数据加载master的RDBmaster将RDB期间的命令记录在repl_baklog并持续将log中的命令发送给slaveslave执行接收到的命令保持与master之间的同步
最后两步参考AOF持久化机制
增量复制 为什么会设计增量复制 主从服务器在完成第一次同步后就会基于长连接进行命令传播。
可是网络总是不按套路出牌的嘛说延迟就延迟说断开就断开。
如果主从服务器间的网络连接断开了那么就无法进行命令传播了这时从服务器的数据就没办法和主服务器保持一致了客户端就可能从「从服务器」读到旧的数据。 增量复制的流程 什么是增量同步就是只更新slave与master存在差异的部分数据。如图 主要有三个步骤
从服务器在恢复网络后会发送 psync 命令给主服务器此时的 psync 命令里的 offset 参数不是 -1主服务器收到该命令后然后用 CONTINUE 响应命令告诉从服务器接下来采用增量复制的方式同步数据然后主服务将主从服务器断线期间所执行的写命令发送给从服务器然后从服务器执行这些命令。
那么关键的问题来了主服务器怎么知道要将哪些增量数据发送给从服务器呢
答案藏在这两个东西里
repl_backlog_buffer是一个「环形」缓冲区用于主从服务器断连后从中找到差异的数据replication offset标记上面那个缓冲区的同步进度主从服务器都有各自的偏移量主服务器使用 master_repl_offset 来记录自己「写」到的位置从服务器使用 slave_repl_offset 来记录自己「读」到的位置。 repl_backlog原理 master怎么知道slave与自己的数据差异在哪里呢?
这就要说到全量同步时的repl_baklog文件了。
这个文件是一个固定大小的数组只不过数组是环形也就是说角标到达数组末尾后会再次从0开始读写这样数组头部的数据就会被覆盖。
repl_baklog中会记录Redis处理过的命令日志及offset包括master当前的offset和slave已经拷贝到的offset slave与master的offset之间的差异就是salve需要增量拷贝的数据了。
随着不断有数据写入master的offset逐渐变大slave也不断的拷贝追赶master的offset 直到数组被填满 此时如果有新的数据写入就会覆盖数组中的旧数据。不过旧的数据只要是绿色的说明是已经被同步到slave的数据即便被覆盖了也没什么影响。因为未同步的仅仅是红色部分。
但是如果slave出现网络阻塞导致master的offset远远超过了slave的offset 如果master继续写入新数据其offset就会覆盖旧的数据直到将slave现在的offset也覆盖 棕色框中的红色部分就是尚未同步但是却已经被覆盖的数据。此时如果slave恢复需要同步却发现自己的offset都没有了无法完成增量同步了。只能做全量同步。 那么在网络恢复时如果从服务器想读的数据已经被覆盖了主服务器就会采用全量同步这个方式比增量同步的性能损耗要大很多。
因此为了避免在网络恢复时主服务器频繁地使用全量同步的方式我们应该调整下 repl_backlog_buffer 缓冲区大小尽可能的大一些减少出现从服务器要读取的数据被覆盖的概率从而使得主服务器采用增量同步的方式。
那 repl_backlog_buffer 缓冲区具体要调整到多大呢
repl_backlog_buffer 最小的大小可以根据这面这个公式估算。 我来解释下这个公式的意思
second 为从服务器断线后重新连接上主服务器所需的平均 时间(以秒计算)。write_size_per_second 则是主服务器平均每秒产生的写命令数据量大小。
举个例子如果主服务器平均每秒产生 1 MB 的写命令而从服务器断线之后平均要 5 秒才能重新连接主服务器。
那么 repl_backlog_buffer 大小就不能低于 5 MB否则新写地命令就会覆盖旧数据了。
当然为了应对一些突发的情况可以将 repl_backlog_buffer 的大小设置为此基础上的 2 倍也就是 10 MB。 更深入理解
命令传播
主从服务器在完成第一次同步后双方之间就会维护一个 TCP 连接。 后续主服务器可以通过这个连接继续将写操作命令传播给从服务器然后从服务器执行该命令使得与主服务器的数据库状态相同。
而且这个连接是长连接的目的是避免频繁的 TCP 连接和断开带来的性能开销。
上面的这个过程被称为基于长连接的命令传播通过这种方式来保证第一次同步后的主从服务器的数据一致性。
分摊主服务器的压力
在前面的分析中我们可以知道主从服务器在第一次数据同步的过程中主服务器会做两件耗时的操作生成 RDB 文件和传输 RDB 文件。
主服务器是可以有多个从服务器的如果从服务器数量非常多而且都与主服务器进行全量同步的话就会带来两个问题
由于是通过 bgsave 命令来生成 RDB 文件的那么主服务器就会忙于使用 fork() 创建子进程如果主服务器的内存数据非大在执行 fork() 函数时是会阻塞主线程的从而使得 Redis 无法正常处理请求传输 RDB 文件会占用主服务器的网络带宽会对主服务器响应命令请求产生影响。
这种情况就好像刚创业的公司由于人不多所以员工都归老板一个人管但是随着公司的发展人员的扩充老板慢慢就无法承担全部员工的管理工作了。
要解决这个问题老板就需要设立经理职位由经理管理多名普通员工然后老板只需要管理经理就好。
Redis 也是一样的从服务器可以有自己的从服务器我们可以把拥有从服务器的从服务器当作经理角色它不仅可以接收主服务器的同步数据自己也可以同时作为主服务器的形式将数据同步给从服务器组织形式如下图 通过这种方式主服务器生成 RDB 和传输 RDB 的压力可以分摊到充当经理角色的从服务器。
那具体怎么做到的呢
其实很简单我们在「从服务器」上执行下面这条命令使其作为目标服务器的从服务器
replicaof 目标服务器的IP 6379此时如果目标服务器本身也是「从服务器」那么该目标服务器就会成为「经理」的角色不仅可以接受主服务器同步的数据也会把数据同步给自己旗下的从服务器从而减轻主服务器的负担。
为什么主从全量复制使用RDB而不使用AOF RDB文件内容是经过压缩的二进制数据不同数据类型数据做了针对性优化文件很小。而AOF文件记录的是每一次写操作的命令写操作越多文件会变得很大其中还包括很多对同一个key的多次冗余操作。在主从全量数据同步时传输RDB文件可以尽量降低对主库机器网络带宽的消耗从库在加载RDB文件时一是文件小读取整个文件的速度会很快二是因为RDB文件存储的都是二进制数据从库直接按照RDB协议解析还原数据即可速度会非常快而AOF需要依次重放每个写命令这个过程会经历冗长的处理逻辑恢复速度相比RDB会慢得多所以使用RDB进行主从全量复制的成本最低。 假设要使用AOF做全量复制意味着必须打开AOF功能打开AOF就要选择文件刷盘的策略选择不当会严重影响Redis性能。而RDB只有在需要定时备份和主从全量复制数据时才会触发生成一次快照。而在很多丢失数据不敏感的业务场景其实是不需要开启AOF的。
当主服务器不进行持久化时复制的安全性
为什么不持久化的主服务器自动重启非常危险呢为了更好的理解这个问题看下面这个失败的例子其中主服务器和从服务器中数据库都被删除了。
我们设置节点A为主服务器关闭持久化节点B和C从节点A复制数据。这时出现了一个崩溃但Redis具有自动重启系统重启了进程因为关闭了持久化节点重启后只有一个空的数据集。节点B和C从节点A进行复制现在节点A是空的所以节点B和C上的复制数据也会被删除。当在高可用系统中使用Redis Sentinel关闭了主服务器的持久化并且允许自动重启这种情况是很危险的。比如主服务器可能在很短的时间就完成了重启以至于Sentinel都无法检测到这次失败那么上面说的这种失败的情况就发生了。
如果数据比较重要并且在使用主从复制时关闭了主服务器持久化功能的场景中都应该禁止实例自动重启。
读写分离及其中的问题
在主从复制基础上实现的读写分离可以实现Redis的读负载均衡由主节点提供写服务由一个或多个从节点提供读服务多个从节点既可以提高数据冗余程度也可以最大化读负载能力在读负载较大的应用场景下可以大大提高Redis服务器的并发量。下面介绍在使用Redis读写分离时需要注意的问题。
延迟与不一致问题
前面已经讲到由于主从复制的命令传播是异步的延迟与数据的不一致不可避免。如果应用对数据不一致的接受程度程度较低可能的优化措施包括优化主从节点之间的网络环境如在同机房部署监控主从节点延迟通过offset判断如果从节点延迟过大通知应用不再通过该从节点读取数据使用集群同时扩展写负载和读负载等。
数据过期问题
在单机版Redis中存在两种删除策略
惰性删除服务器不会主动删除数据只有当客户端查询某个数据时服务器判断该数据是否过期如果过期则删除。
定期删除服务器执行定时任务删除过期数据但是考虑到内存和CPU的折中删除会释放内存但是频繁的删除操作对CPU不友好该删除的频率和执行时间都受到了限制。
在主从复制场景下为了主从节点的数据一致性从节点不会主动删除数据而是由主节点控制从节点中过期数据的删除。由于主节点的惰性删除和定期删除策略都不能保证主节点及时对过期数据执行删除操作因此当客户端通过Redis从节点读取数据时很容易读取到已经过期的数据。
Redis 3.2中从节点在读取数据时增加了对数据是否过期的判断如果该数据已过期则不返回给客户端将Redis升级到3.2可以解决数据过期问题。
故障切换问题
在没有使用哨兵的读写分离场景下应用针对读和写分别连接不同的Redis节点当主节点或从节点出现问题而发生更改时需要及时修改应用程序读写Redis数据的连接连接的切换可以手动进行或者自己写监控程序进行切换但前者响应慢、容易出错后者实现复杂成本都不算低。
总结
在使用读写分离之前可以考虑其他方法增加Redis的读负载能力如尽量优化主节点减少慢查询、减少持久化等其他情况带来的阻塞等提高负载能力使用Redis集群同时提高读负载能力和写负载能力等。如果使用读写分离可以使用哨兵使主从节点的故障切换尽可能自动化并减少对应用程序的侵入。
主从机制优缺点
主从机制其实也是为后续的一些高可用机制打下了基础但是本身也存在一些缺陷当然在后续的高可用机制中得到了解决具体如下
优点 能够为后续的高可用机制打下基础在持久化的基础上能够将数据同步到其他机器在极端情况下做到灾备的效果能够通过主写从读的形式实现读写分离提升Redis整体吞吐并且读的性能可以通过对从节点进行线性扩容无限提升 缺点 全量数据同步时如果数据量比较大在之前会导致线上短暂性的卡顿一旦主节点宕机从节点晋升为主节点同时需要修改应用方的主节点地址还需要命令所有从节点去复制新的主节点整个过程需要人工干预写入的QPS性能受到主节点限制虽然主从复制能够通过读写分离来提升整体性能但是只有从节点能够做到线性扩容升吞吐写入的性能还是受到主节点限制木桶效应整个Redis节点群能够存储的数据容量受到所有节点中内存最小的那台限制比如一主两从架构master32GB、slave132GB、slave216GB那么整个Redis节点群能够存储的最大容量为16GB
小结
简述全量同步和增量同步区别
全量同步master将完整内存数据生成RDB发送RDB到slave。后续命令则记录在repl_baklog逐个发送给slave。增量同步slave提交自己的offset到mastermaster获取repl_baklog中从offset之后的命令给slave
什么时候执行全量同步
slave节点第一次连接master节点时slave节点断开时间太久repl_baklog中的offset已经被覆盖时
什么时候执行增量同步
slave节点断开又恢复并且在repl_baklog中能找到offset时 主从复制共有三种模式全量复制、基于长连接的命令传播、增量复制。 主从服务器第一次同步的时候就是采用全量复制此时主服务器会两个耗时的地方分别是生成 RDB 文件和传输 RDB 文件。为了避免过多的从服务器和主服务器进行全量复制可以把一部分从服务器升级为「经理角色」让它也有自己的从服务器通过这样可以分摊主服务器的压力。 第一次同步完成后主从服务器都会维护着一个长连接主服务器在接收到写操作命令后就会通过这个连接将写命令传播给从服务器来保证主从服务器的数据一致性。 如果遇到网络断开增量复制就可以上场了不过这个还跟 repl_backlog_size 这个大小有关系。 如果它配置的过小主从服务器网络恢复时可能发生「从服务器」想读的数据已经被覆盖了那么这时就会导致主服务器采用全量复制的方式。所以为了避免这种情况的频繁发生要调大这个参数的值以降低主从服务器断开后全量同步的概率。 面试题
Redis主从节点时长连接还是短连接
长连接
怎么判断 Redis 某个节点是否正常工作
Redis 判断节点是否正常工作基本都是通过互相的 ping-pong 心态检测机制如果有一半以上的节点去 ping 一个节点的时候没有 pong 回应集群就会认为这个节点挂掉了会断开与这个节点的连接。
Redis 主从节点发送的心态间隔是不一样的而且作用也有一点区别
Redis 主节点默认每隔 10 秒对从节点发送 ping 命令判断从节点的存活性和连接状态可通过参数repl-ping-slave-period控制发送频率。Redis 从节点每隔 1 秒发送 replconf ack{offset} 命令给主节点上报自身当前的复制偏移量目的是为了 实时监测主从节点网络状态上报自身复制偏移量 检查复制数据是否丢失 如果从节点数据丢失 再从主节点的复制缓冲区中拉取丢失数据。
主从复制架构中过期key如何处理
主节点处理了一个key或者通过淘汰算法淘汰了一个key这个时间主节点模拟一条del命令发送给从节点从节点收到该命令后就进行删除key的操作。
Redis 是同步复制还是异步复制
Redis 主节点每次收到写命令之后先写到内部的缓冲区然后异步发送给从节点。
主从复制中两个 Buffer(replication buffer 、repl backlog buffer)有什么区别
replication buffer 、repl backlog buffer 区别如下
出现的阶段不一样 repl backlog buffer 是在增量复制阶段出现一个主节点只分配一个 repl backlog bufferreplication buffer 是在全量复制阶段和增量复制阶段都会出现主节点会给每个新连接的从节点分配一个 replication buffer 这两个 Buffer 都有大小限制的当缓冲区满了之后发生的事情不一样 当 repl backlog buffer 满了因为是环形结构会直接覆盖起始位置数据;当 replication buffer 满了会导致连接断开删除缓存从节点重新连接重新开始全量复制。
如何应对主从数据不一致 为什么会出现主从数据不一致 主从数据不一致就是指客户端从从节点中读取到的值和主节点中的最新值并不一致。
之所以会出现主从数据不一致的现象是因为主从节点间的命令复制是异步进行的所以无法实现强一致性保证主从数据时时刻刻保持一致。
具体来说在主从节点命令传播阶段主节点收到新的写命令后会发送给从节点。但是主节点并不会等到从节点实际执行完命令后再把结果返回给客户端而是主节点自己在本地执行完命令后就会向客户端返回结果了。如果从节点还没有执行主节点同步过来的命令主从节点间的数据就不一致了。 如何如何应对主从数据不一致 第一种方法尽量保证主从节点间的网络连接状况良好避免主从节点在不同的机房。
第二种方法可以开发一个外部程序来监控主从节点间的复制进度。具体做法
Redis 的 INFO replication 命令可以查看主节点接收写命令的进度信息master_repl_offset和从节点复制写命令的进度信息slave_repl_offset所以我们就可以开发一个监控程序先用 INFO replication 命令查到主、从节点的进度然后我们用 master_repl_offset 减去 slave_repl_offset这样就能得到从节点和主节点间的复制进度差值了。如果某个从节点的进度差值大于我们预设的阈值我们可以让客户端不再和这个从节点连接进行数据读取这样就可以减少读到不一致数据的情况。不过为了避免出现客户端和所有从节点都不能连接的情况我们需要把复制进度差值的阈值设置得大一些。
主从切换如何减少数据丢失
主从切换过程中产生数据丢失的情况有两种
异步复制同步丢失集群产生脑裂数据丢失
我们不可能保证数据完全不丢失只能做到使得尽量少的数据丢失。
异步复制同步丢失
对于 Redis 主节点与从节点之间的数据复制是异步复制的当客户端发送写请求给主节点的时候客户端会返回 ok接着主节点将写请求异步同步给各个从节点但是如果此时主节点还没来得及同步给从节点时发生了断电那么主节点内存中的数据会丢失。 减少异步复制的数据丢失的方案 Redis 配置里有一个参数 min-slaves-max-lag表示一旦所有的从节点数据复制和同步的延迟都超过了 min-slaves-max-lag 定义的值那么主节点就会拒绝接收任何请求。
假设将 min-slaves-max-lag 配置为 10s 后根据目前 master-slave 的复制速度如果数据同步完成所需要时间超过10s就会认为 master 未来宕机后损失的数据会很多master 就拒绝写入新请求。这样就能将 master 和 slave 数据差控制在10s内即使 master 宕机也只是这未复制的 10s 数据。
那么对于客户端当客户端发现 master 不可写后我们可以采取降级措施将数据暂时写入本地缓存和磁盘中在一段时间等 master 恢复正常后重新写入 master 来保证数据不丢失也可以将数据写入 kafka 消息队列等 master 恢复正常再隔一段时间去消费 kafka 中的数据让将数据重新写入 master 。
集群产生脑裂数据丢失
先来理解集群的脑裂现象这就好比一个人有两个大脑那么到底受谁控制呢
那么在 Redis 中集群脑裂产生数据丢失的现象是怎样的呢
在 Redis 主从架构中部署方式一般是「一主多从」主节点提供写操作从节点提供读操作。
如果主节点的网络突然发生了问题它与所有的从节点都失联了但是此时的主节点和客户端的网络是正常的这个客户端并不知道 Redis 内部已经出现了问题还在照样的向这个失联的主节点写数据过程A此时这些数据被主节点缓存到了缓冲区里因为主从节点之间的网络问题这些数据都是无法同步给从节点的。
这时哨兵也发现主节点失联了它就认为主节点挂了但实际上主节点正常运行只是网络出问题了于是哨兵就会在从节点中选举出一个 leeder 作为主节点这时集群就有两个主节点了 —— 脑裂出现了。
这时候网络突然好了哨兵因为之前已经选举出一个新主节点了它就会把旧主节点降级为从节点A然后从节点A会向新主节点请求数据同步因为第一次同步是全量同步的方式此时的从节点A会清空掉自己本地的数据然后再做全量同步。所以之前客户端在过程 A 写入的数据就会丢失了也就是集群产生脑裂数据丢失的问题。
总结一句话就是由于网络问题集群节点之间失去联系。主从数据不同步重新平衡选举产生两个主服务。等网络恢复旧主节点会降级为从节点再与新主节点进行同步复制的时候由于会从节点会清空自己的缓冲区所以导致之前客户端写入的数据丢失了。 减少脑裂的数据丢的方案 当主节点发现「从节点下线的数量太多」或者「网络延迟太大」的时候那么主节点会禁止写操作直接把错误返回给客户端。
在 Redis 的配置文件中有两个参数我们可以设置
min-slaves-to-write x主节点必须要有至少 x 个从节点连接如果小于这个数主节点会禁止写数据。min-slaves-max-lag x主从数据复制和同步的延迟不能超过 x 秒如果主从同步的延迟超过 x 秒主节点会禁止写数据。
我们可以把 min-slaves-to-write 和 min-slaves-max-lag 这两个配置项搭配起来使用分别给它们设置一定的阈值假设为 N 和 T。
这两个配置项组合后的要求是主节点连接的从节点中至少有 N 个从节点「并且」主节点进行数据复制时的 ACK 消息延迟不能超过 T 秒否则主节点就不会再接收客户端的写请求了。
即使原主节点是假故障它在假故障期间也无法响应哨兵心跳也不能和从节点进行同步自然也就无法和从节点进行 ACK 确认了。这样一来min-slaves-to-write 和 min-slaves-max-lag 的组合要求就无法得到满足原主节点就会被限制接收客户端写请求客户端也就不能在原主节点中写入新数据了。
等到新主节点上线时就只有新主节点能接收和处理客户端请求此时新写的数据会被直接写到新主节点中。而原主节点会被哨兵降为从节点即使它的数据被清空了也不会有新数据丢失。我再来给你举个例子。
假设我们将 min-slaves-to-write 设置为 1把 min-slaves-max-lag 设置为 12s把哨兵的 down-after-milliseconds 设置为 10s主节点因为某些原因卡住了 15s导致哨兵判断主节点客观下线开始进行主从切换。同时因为原主节点卡住了 15s没有一个从节点能和原主节点在 12s 内进行数据复制原主节点也无法接收客户端请求了。这样一来主从切换完成后也只有新主节点能接收请求不会发生脑裂也就不会发生数据丢失的问题了。
主从如何做到故障自动切换
主节点挂了 从节点是无法自动升级为主节点的这个过程需要人工处理在此期间 Redis 无法对外提供写操作。
此时Redis 哨兵机制就登场了哨兵在发现主节点出现故障时由哨兵自动完成故障发现和故障转移并通知给应用方从而实现高可用性。
