企业年金一般一个月交多少,长沙财优化公司,西安手机网站建设公司,wordpress首页全屏插件目录标题 主从复制第一次同步命令传播分担主服务器压力增量复制总结面试题什么是Redis主从复制Redis主从复制的原理Redis主从复制的优点Redis主从复制的缺点Redis主从复制的配置步骤Redis主从复制的同步策略主从节点是长还是短连接判断某个节点是否正常工作主从复制架构中… 目录标题 主从复制第一次同步命令传播分担主服务器压力增量复制总结面试题什么是Redis主从复制Redis主从复制的原理Redis主从复制的优点Redis主从复制的缺点Redis主从复制的配置步骤Redis主从复制的同步策略主从节点是长还是短连接判断某个节点是否正常工作主从复制架构中过期key如何处理Redis 是同步复制还是异步复制主从复制中两个 Buffer(replication buffer 、repl backlog buffer)有什么区别如何应对主从数据不一致主从切换如何减少数据丢失主从如何做到故障自动切换 哨兵模式为什么要有哨兵模式哨兵机制如何工作如何判断主节点是真的故障主观下线客观下线具体怎么判定为客观下线 哪个哨兵进行主从故障转移候选者如何成为 Leaderwhy哨兵节点至少有 3 个 主从故障转移的过程面试题什么是Redis哨兵模式Redis哨兵模式的原理Redis哨兵模式的优点Redis哨兵模式的缺点哨兵模式的配置步骤 主从复制 多台服务器如何保持数据一致性数据的读写操作是否每台服务器都可以处理Redis提供主从复制它可以保证多台服务器的数据一致性且主从服务器之间采用的是读写分离的方式。
主服务器可以进行读写操作当发生写操作时自动将写操作同步给从服务器而从服务器一般是只读并接受从服务器同步过来写操作命令然后执行这条命令 也就是说所有的数据修改只在主服务器上进行然后将最新的数据同步给从服务器这样就使得主从服务器的数据是一致的。
第一次同步
多台服务器之间通过replicaofRedis5.0之前使用slaveof命令形成主服务器和从服务器的关系
比如现在有服务器 A 和 服务器 B我们在服务器 B 上执行下面这条命令
# 服务器 B 执行这条命令
replicaof 服务器 A 的 IP 地址 服务器 A 的 Redis 端口号主从服务器间的第一次同步的过程可分为三个阶段
第一阶段是建立链接、协商同步第二阶段是主服务器同步数据给从服务器第三阶段是主服务器发送新写操作命令给从服务器。
命令传播
主从服务器在完成第一次同步后双方之间就会维护一个TCP连接。 后续主服务器可以通过这个连接继续将写操作命令传播给从服务器然后从服务器执行该命令使得与主服务器的数据库状态相同。而且这个连接是长连接的目的是避免频繁的 TCP 连接和断开带来的性能开销。上面的这个过程被称为基于长连接的命令传播通过这种方式来保证第一次同步后的主从服务器的数据一致性。
分担主服务器压力
从服务器可以有自己的从服务器我们可以把拥有从服务器的从服务器当作经理角色它不仅可以接收主服务器的同步数据自己也可以同时作为主服务器的形式将数据同步给从服务器组织形式如下图 通过这种方式主服务器生成 RDB 和传输 RDB 的压力可以分摊到充当经理角色的从服务器。
那具体怎么做到的呢其实很简单我们在「从服务器」上执行下面这条命令使其作为目标服务器的从服务器
replicaof 目标服务器的IP 6379此时如果目标服务器本身也是「从服务器」那么该目标服务器就会成为「经理」的角色不仅可以接受主服务器同步的数据也会把数据同步给自己旗下的从服务器从而减轻主服务器的负担。
增量复制
在 Redis 2.8 之前如果主从服务器在命令同步时出现了网络断开又恢复的情况从服务器就会和主服务器重新进行一次全量复制很明显这样的开销太大了必须要改进一波。
所以从 Redis 2.8 开始网络断开又恢复后从主从服务器会采用增量复制的方式继续同步也就是只会把网络断开期间主服务器接收到的写操作命令同步给从服务器。 主要有三个步骤
从服务器在恢复网络后会发送 psync 命令给主服务器此时的 psync 命令里的 offset 参数不是 -1主服务器收到该命令后然后用 CONTINUE 响应命令告诉从服务器接下来采用增量复制的方式同步数据然后主服务将主从服务器断线期间所执行的写命令发送给从服务器然后从服务器执行这些命令。
总结
主从复制共有三种模式全量复制、基于长连接的命令传播、增量复制。
主从服务器第一次同步的时候就是采用全量复制此时主服务器会两个耗时的地方分别是生成 RDB 文件和传输 RDB 文件。为了避免过多的从服务器和主服务器进行全量复制可以把一部分从服务器升级为「经理角色」让它也有自己的从服务器通过这样可以分摊主服务器的压力。
第一次同步完成后主从服务器都会维护着一个长连接主服务器在接收到写操作命令后就会通过这个连接将写命令传播给从服务器来保证主从服务器的数据一致性。
如果遇到网络断开增量复制就可以上场了不过这个还跟 repl_backlog_size 这个大小有关系。
如果它配置的过小主从服务器网络恢复时可能发生「从服务器」想读的数据已经被覆盖了那么这时就会导致主服务器采用全量复制的方式。所以为了避免这种情况的频繁发生要调大这个参数的值以降低主从服务器断开后全量同步的概率。
面试题
什么是Redis主从复制
Redis主从复制是指将一个Redis服务器主节点的数据复制到其他Redis服务器从节点上的过程。主节点负责写操作而从节点负责读操作从而实现数据的备份、读写分离和负载均衡。
Redis主从复制的原理
主从复制的原理是通过Redis的发布/订阅机制实现的。当主节点有写操作时会将写操作的命令传播给所有从节点从节点会执行相同的命令来达到数据同步的目的。
Redis主从复制的优点
数据备份主节点的数据会被复制到从节点上当主节点发生故障时从节点可以接管服务保证数据的可用性。读写分离主节点负责写操作从节点负责读操作可以提高系统的读写性能。负载均衡可以通过增加从节点来分担主节点的负载提高系统的并发能力。
Redis主从复制的缺点
数据延迟由于主从复制是异步的过程主节点的写操作需要经过网络传输到从节点因此从节点上的数据可能会有一定的延迟。这意味着如果在主节点写入数据后立即进行读操作可能读取到的是旧数据。单点故障虽然主从复制可以提高系统的可用性但是主节点仍然是一个单点故障。当主节点发生故障时需要手动将一个从节点升级为主节点这个过程可能会导致一段时间的服务不可用。无法实现自动故障转移Redis主从复制需要手动进行故障转移即将一个从节点升级为主节点这个过程需要人工干预。在高负载的情况下可能会导致一段时间的服务不可用。无法保证数据一致性由于主从复制是异步的过程当主节点发生故障时从节点上的数据可能会滞后于主节点。在这种情况下如果没有进行数据同步的操作可能会导致数据不一致的问题。配置复杂Redis主从复制的配置相对复杂需要在主节点和从节点上进行配置并确保配置的正确性。如果配置不正确可能会导致主从复制失败或者数据不一致的问题。
Redis主从复制的配置步骤
配置主节点在主节点的配置文件中设置slaveof参数为空启动主节点。配置从节点在从节点的配置文件中设置slaveof参数为主节点的地址和端口号启动从节点。验证主从复制可以通过在主节点上写入数据然后在从节点上读取数据来验证主从复制是否成功。
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 的配置文件中有两个参数我们可以设置
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 哨兵机制就登场了哨兵在发现主节点出现故障时由哨兵自动完成故障发现和故障转移并通知给应用方从而实现高可用性。
哨兵模式
为什么要有哨兵模式
主从模式采用读写分离如果主节点挂了将没有主节点来服务客户端请求如果要恢复服务时需要人工介入太不智能了。Redis 在 2.8 版本以后提供的哨兵*Sentinel*机制它的作用是实现主从节点故障转移。它会监测主节点是否存活如果发现主节点挂了它就会选举一个从节点切换为主节点并且把新主节点的相关信息通知给从节点和客户端。
哨兵机制如何工作
哨兵其实是一个运行在特殊模式下的 Redis 进程所以它也是一个节点哨兵节点主要负责三件事监控、选主、通知
如何判断主节点是真的故障
哨兵会每隔 1 秒给所有主从节点发送 PING 命令当主从节点收到 PING 命令后会发送一个响应命令给哨兵这样就可以判断它们是否在正常运行。 如果主节点或者从节点没有在规定的时间内响应哨兵的 PING 命令哨兵就会将它们标记为「主观下线」。这个「规定的时间」是配置项 down-after-milliseconds 参数设定的单位是毫秒。
主观下线客观下线
客观下线只适用于主节点。之所以针对「主节点」设计「主观下线」和「客观下线」两个状态是因为有可能「主节点」其实并没有故障可能只是因为主节点的系统压力比较大或者网络发送了拥塞导致主节点没有在规定时间内响应哨兵的 PING 命令。
所以为了减少误判的情况哨兵在部署的时候不会只部署一个节点而是用多个节点部署成哨兵集群最少需要三台机器来部署哨兵集群通过多个哨兵节点一起判断就可以就可以避免单个哨兵因为自身网络状况不好而误判主节点下线的情况。同时多个哨兵的网络同时不稳定的概率较小由它们一起做决策误判率也能降低。
具体怎么判定为客观下线
当一个哨兵判断主节点为「主观下线」后就会向其他哨兵发起命令其他哨兵收到这个命令后就会根据自身和主节点的网络状况做出赞成投票或者拒绝投票的响应。 当这个哨兵的赞同票数达到哨兵配置文件中的 quorum 配置项设定的值后这时主节点就会被该哨兵标记为「客观下线」。例如现在有 3 个哨兵quorum 配置的是 2那么一个哨兵需要 2 张赞成票就可以标记主节点为“客观下线”了。这 2 张赞成票包括哨兵自己的一张赞成票和另外两个哨兵的赞成票。PSquorum 的值一般设置为哨兵个数的二分之一加1例如 3 个哨兵就设置 2。哨兵判断完主节点客观下线后哨兵就要开始在多个「从节点」中选出一个从节点来做新主节点。
哪个哨兵进行主从故障转移
哨兵是以哨兵集群的方式存在的。需要在哨兵集群中选出一个 leader让 leader 来执行主从切换。选举 leader 的过程其实是一个投票的过程在投票开始前肯定得有个「候选者」。哪个哨兵节点判断主节点为「客观下线」这个哨兵节点就是候选者所谓的候选者就是想当 Leader 的哨兵。
候选者如何成为 Leader
候选者会向其他哨兵发送命令表明希望成为 Leader 来执行主从切换并让所有其他哨兵对它进行投票。每个哨兵只有一次投票机会如果用完后就不能参与投票了可以投给自己或投给别人但是只有候选者才能把票投给自己。那么在投票过程中任何一个「候选者」要满足两个条件
第一拿到半数以上的赞成票第二拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。
举个例子假设哨兵节点有 3 个quorum 设置为 2那么任何一个想成为 Leader 的哨兵只要拿到 2 张赞成票就可以选举成功了。如果没有满足条件就需要重新进行选举。这时候有的同学就会问了如果某个时间点刚好有两个哨兵节点判断到主节点为客观下线那这时不就有两个候选者了这时该如何决定谁是 Leader 呢
每位候选者都会先给自己投一票然后向其他哨兵发起投票请求。如果投票者先收到「候选者 A」的投票请求就会先投票给它如果投票者用完投票机会后收到「候选者 B」的投票请求后就会拒绝投票。这时候选者 A 先满足了上面的那两个条件所以「候选者 A」就会被选举为 Leader。
why哨兵节点至少有 3 个
如果哨兵集群中只有 2 个哨兵节点此时如果一个哨兵想要成功成为 Leader必须获得 2 票而不是 1 票。所以如果哨兵集群中有个哨兵挂掉了那么就只剩一个哨兵了如果这个哨兵想要成为 Leader这时票数就没办法达到 2 票就无法成功成为 Leader这时是无法进行主从节点切换的。
因此通常我们至少会配置 3 个哨兵节点。这时如果哨兵集群中有个哨兵挂掉了那么还剩下两个个哨兵如果这个哨兵想要成为 Leader这时还是有机会达到 2 票的所以还是可以选举成功的不会导致无法进行主从节点切换。
当然你要问如果 3 个哨兵节点挂了 2 个怎么办这个时候得人为介入了或者增加多一点哨兵节点。再说一个问题Redis 1 主 4 从5 个哨兵 quorum 设置为 3如果 2 个哨兵故障当主节点宕机时哨兵能否判断主节点“客观下线”主从能否自动切换
哨兵集群可以判定主节点“客观下线”。哨兵集群还剩下 3 个哨兵当一个哨兵判断主节点“主观下线”后询问另外 2 个哨兵后有可能能拿到 3 张赞同票这时就达到了 quorum 的值因此哨兵集群可以判定主节点为“客观下线”。哨兵集群可以完成主从切换。当有个哨兵标记主节点为「客观下线」后就会进行选举 Leader 的过程因为此时哨兵集群还剩下 3 个哨兵那么还是可以拿到半数以上5/213的票而且也达到了 quorum 值满足了选举 Leader 的两个条件 所以就能选举成功因此哨兵集群可以完成主从切换。
如果 quorum 设置为 2 并且如果有 3 个哨兵故障的话。此时哨兵集群还是可以判定主节点为“客观下线”但是哨兵不能完成主从切换了大家可以自己推演下。如果 quorum 设置为 3并且如果有 3 个哨兵故障的话哨兵集群即不能判定主节点为“客观下线”也不能完成主从切换了。可以看到quorum 为 2 的时候并且如果有 3 个哨兵故障的话虽然可以判定主节点为“客观下线”但是不能完成主从切换这样感觉「判定主节点为客观下线」这件事情白做了一样既然这样还不如不要做quorum 为 3 的时候就可以避免这种无用功。所以quorum 的值建议设置为哨兵个数的二分之一加1例如 3 个哨兵就设置 25 个哨兵设置为 3而且哨兵节点的数量应该是奇数。
主从故障转移的过程
在哨兵集群中通过投票的方式选举出了哨兵 leader 后就可以进行主从故障转移的过程了如下图 主从故障转移操作包含以下四个步骤
第一步在已下线主节点旧主节点属下的所有「从节点」里面挑选出一个从节点并将其转换为主节点。第二步让已下线主节点属下的所有「从节点」修改复制目标修改为复制「新主节点」第三步将新主节点的 IP 地址和信息通过「发布者/订阅者机制」通知给客户端第四步继续监视旧主节点当这个旧主节点重新上线时将它设置为新主节点的从节点
面试题
什么是Redis哨兵模式
Redis哨兵模式是一种用于监控和管理Redis实例的解决方案。它由一个或多个哨兵节点组成哨兵节点通过相互通信来监控Redis实例的状态并在主节点发生故障时自动将从节点升级为主节点。
Redis哨兵模式的原理
Redis哨兵模式的原理是通过哨兵节点之间的相互通信来实现的。每个哨兵节点会定期向其他哨兵节点发送PING命令如果一个哨兵节点发现主节点不可用它会向其他哨兵节点发送选举消息最终哨兵节点会协商选择一个从节点升级为新的主节点。
Redis哨兵模式的优点
自动故障转移当主节点发生故障时哨兵节点可以自动将一个从节点升级为新的主节点从而实现故障转移保证系统的可用性。主节点选举哨兵节点可以在主节点不可用时协商选举一个新的主节点保证系统的持续可用性。配置简单哨兵模式相对于主从复制来说配置更加简单只需要配置哨兵节点的信息即可。
Redis哨兵模式的缺点
响应时间较长由于哨兵节点之间需要相互通信来检测和管理Redis实例因此在故障转移和主节点选举过程中可能会有一定的延迟导致系统的响应时间变长。单点故障哨兵模式仍然存在单点故障问题当所有的哨兵节点都不可用时系统将无法进行故障转移和主节点选举。
哨兵模式的配置步骤
配置哨兵节点在哨兵节点的配置文件中设置监控的Redis实例信息并启动哨兵节点。配置Redis实例在Redis实例的配置文件中设置哨兵模式的相关参数并启动Redis实例。验证哨兵模式可以通过停止主节点的Redis实例观察哨兵节点是否能够自动将从节点升级为新的主节点来验证哨兵模式的可用性。
