傻瓜式做网站哪个软件好,阿里云主机怎么做两个网站吗,葫芦岛市营商环境建设管理局网站,公司招聘网站主从复制 主从复制是 Redis 高可用服务最基础的保证#xff0c;将一台 Redis 主服务器#xff0c;同步数据到多台 Redis 从服务器上#xff0c;即一主多从的模式#xff0c;且主从服务器之间采用的是「读写分离」的方式。
主服务器可以进行读写操作#xff0c;当发生写操… 主从复制 主从复制是 Redis 高可用服务最基础的保证将一台 Redis 主服务器同步数据到多台 Redis 从服务器上即一主多从的模式且主从服务器之间采用的是「读写分离」的方式。
主服务器可以进行读写操作当发生写操作时自动将写操作同步给从服务器而从服务器一般是只读并接收主服务器同步过来的写操作命令然后执行这条命令。 我们可以使用 replicaofRedis 5.0 之前使用 slaveof命令形成主服务器和从服务器的关系。
// 服务器B执行这条命令
replicaof 服务器A的IP地址 服务器A的Redis端口号主从复制共有三种模式全量复制、基于长连接的命令传播、增量复制。
主从服务器第一次同步的时候就是采用全量复制此时主服务器会两个耗时的地方分别是生成 RDB 文件和传输 RDB 文件。
建立链接、协商同步。给全量复制做准备主服务器同步数据给从服务器。主服务器会执行 bgsave 命令来生成 RDB 文件然后把文件发送给从服务器。从服务器收到 RDB 文件后会先清空当前的数据然后载入 RDB 文件主服务器发送新的写操作命令给从服务器。为了保证主从服务器的数据一致性主服务器将 bgsave 期间收到的写操作命令写入到 replication buffer 缓冲区里。在主服务器生成的 RDB 文件发送完从服务器完成 RDB 文件的载入后会回复一个确认消息给主服务器。接着主服务器将 replication buffer 缓冲区里所记录的写操作命令发送给从服务器从服务器执行命令这时主从服务器的数据就一致了
为了避免过多的从服务器和主服务器进行全量复制可以把一部分从服务器升级为「经理角色」让它也有自己的从服务器分摊主服务器的压力。
在「从服务器」上执行下面这条命令使其作为目标服务器的从服务器。如果目标服务器本身也是「从服务器」那么该目标服务器就会成为「经理角色」不仅可以接收主服务器同步的数据也会把数据同步给自己旗下的从服务器从而减轻主服务器的负担。
replicaof 目标服务器的IP 6379第一次同步完成后主从服务器会维护着一个长连接主服务器在接收到写操作命令后会通过这个连接将写命令传播给从服务器来保证主从服务器的数据一致性。
如果遇到网络异常中断导致无法进行命令传播时就利用 repl_backlog_size 缓冲区进行增量复制实现主从服务器的数据一致性。 哨兵模式 在使用 Redis 主从服务时当 Redis 的主从服务器出现故障宕机需要进行手动恢复。
为了解决这个问题Redis 增加了哨兵模式Redis Sentinel哨兵模式做到了可以监控主从服务器并且提供主从节点故障转移的功能。 如果主节点或者从节点没有在规定的时间内响应哨兵的 PING 命令哨兵就会将它们标记为「主观下线」。这个「规定的时间」是由配置项 down-after-milliseconds 参数设定的单位是毫秒。
同时针对「主节点」设计「主观下线」和「客观下线」两个状态客观下线只适用于主节点。因为有可能「主节点」其实并没有故障只是因为主节点的系统压力比较大或者网络拥塞导致主节点没有在规定时间内响应哨兵的 PING 命令。
所以为了减少误判哨兵在部署时会用多个节点部署成哨兵集群最少需要三台机器来部署哨兵集群通过多个哨兵节点一起判断就可以避免因为单个哨兵自身网络状况不好导致误判主节点下线的情况。同时多个哨兵的网络同时不稳定的概率较小由它们一起做决策误判率也能降低。
当一个哨兵判断主节点「主观下线」后就会向其他哨兵发起命令其他哨兵收到这个命令后就会根据自身和主节点的网络状况做出赞成投票或者拒绝投票的响应。 当这个哨兵的赞同票数达到配置文件中的 quorum 配置项设定的值后主节点就会被该哨兵标记为「客观下线」。
哨兵判断完主节点客观下线后就要开始在多个「从节点」中选出一个从节点来做新主节点。这时候还需要在哨兵集群中选出一个 leader让 leader 来执行主从切换。
选举 leader 的过程其实也是一个投票的过程在投票开始前是哪个哨兵节点判断主节点为「客观下线」这个哨兵节点就是候选者所谓的候选者就是想当 leader 的哨兵。
候选者会向其他哨兵发送命令表明希望成为 leader 来执行主从切换并让其他哨兵对它进行投票。每个哨兵只有一次投票机会如果用完就不能再参与投票了可以投给自己或投给别人但是只有候选者才能把票投给自己。
举例来说假设哨兵节点有 3 个quorum 设置为 2那么任何一个想成为 leader 的哨兵只要拿到 2 张赞成票就可以选举成功了。如果没有满足条件就需要重新进行选举。
选举出哨兵 leader 后就可以进行主从故障转移的过程了。
在已下线的主节点旧主节点下属的所有「从节点」里挑选出一个从节点并将其转换为主节点根据节点的优先级、复制进度、ID 号尽可能让数据最全的节点成为新主节点让已下线的主节点下属的所有「从节点」修改复制目标修改为复制「新主节点」将新主节点的 IP 地址和信息通过「发布/订阅机制」通知给客户端继续监视旧主节点等这个旧主节点重新上线时将它设置为新主节点的从节点 集群脑裂 在 Redis 主从架构中假设主节点网络突然发生了问题它与所有的从节点都失联了但是和客户端的网络还是正常的。客户端并不知道 Redis 内部已经出现了问题继续向主节点写数据因为主从节点之间的网络问题这些数据始终无法同步给从节点。
这时哨兵也发现主节点失联它就认为主节点挂了但实际上主节点还是正常运行只是网络出问题了于是哨兵就会在「从节点」中选举出一个新主节点这时集群就有两个主节点了 —— 脑裂出现了相当于出现了两个大脑。
过了一会主节点网络突然好了重新上线时因为哨兵之前已经选举出了一个新主节点就会把旧主节点降级为从节点然后从节点会向新主节点请求数据同步。
因为第一次同步是全量同步从节点会清空本地的数据再做全量同步。所以之前客户端写入的数据就会丢失。
简单来说由于网络问题集群节点之间失去联系主从数据不同步哨兵重新平衡选举后产生两个主服务。等网络恢复后旧主节点会降级为从节点再与新主节点进行同步复制时由于从节点会清空自己的缓冲区导致之前客户端写入的数据丢失。
解决方案
当主节点发现从节点下线或者通信超时的总数量达到阈值时禁止写数据直接返回错误给客户端。
在 Redis 配置文件中有两个参数可以设置。
min-slaves-to-write x主节点必须要有至少 x 个从节点连接如果小于这个数主节点就会禁止写数据min-slaves-max-lag x主从数据复制和同步的延迟不能超过 x 秒如果超过主节点就会禁止写数据
可以把这两个配置项搭配起来使用分别给它们设置一定的阈值假设为 N 和 T。即主库连接的从库中至少有 N 个从库且和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒否则主库就不会再接收客户端的写请求了。
等到选举出新主库时只有新主库能接收和处理客户端请求此时新写的数据会直接写到新主库中。而原主库会被哨兵降为从库即使它的数据被清空了也不会有数据丢失的问题。
