邢台网站制作哪里有,深圳市光明区属于哪个区,闸北区网站建设网页设计,上传网站需要什么软件说明
文章内容通过学习小林Coding内的优质文章后整理而来#xff0c;整理成思维导图的方式是为了帮助自己理解、记忆和复习。如若侵权请联系删除#xff0c;再次对小林Coding内的优质文章表示感谢。参考文章如下#xff1a;
主从复制是怎么实现的#xff1f;为什么要有哨…
说明
文章内容通过学习小林Coding内的优质文章后整理而来整理成思维导图的方式是为了帮助自己理解、记忆和复习。如若侵权请联系删除再次对小林Coding内的优质文章表示感谢。参考文章如下
主从复制是怎么实现的为什么要有哨兵
思维导图会不断修改完善下方的文字内容不一定会跟着修改请大家以思维导图的内容为准。
Redis高可用
Redis部署方式
单服务器部署
宕机需要时间恢复期间无法提供服务硬盘损坏数据丢失
多服务器部署 一台服务器出问题其他服务器还能提供服务 有什么问题 服务器之间的数据如何保持一致数据的读写操作在服务器间如何分配 问题如何解决 交给主从复制
主从复制
是什么
主从服务器使用读写分离方式主可读写从只读主发生写操作时自动将写操作同步给从
有什么用
保证主从服务器的数据一致性
怎么确定主从关系
B服务器执行下面命令就变成A服务器的从节点replicaof A 的 IP 地址 A 的 Redis 端口号
第一次同步 为什么 刚建立主从关系时主从服务器的数据不一致需要进行第一次同步 什么步骤 建立链接、协商同步 从执行 replicaof 命令后就会给主发送 psync 命令 psync表示要进行数据同步 psync包含两参数 runID 每个Redis服务器在启动时会生成一个随机runID来标识自己第一次同步从不知道主的runID因此设置为 ? offset 表示复制的进度第一次同步设置为-1 主收到psync命令后将 FULLRESYNC 作为响应命令返回给对方 FULLRESYNC返回两参数 主的runID主的复制进度offset 从收到响应之后记录相应的参数 主同步全量数据给从 步骤 主执行 bgsave 命令fork子进程来生成 RDB 文件并发送给从从收到 RDB 文件后先清空当前数据后载入 RDB 文件 问题 在生产RDB文件期间主收到的写操作不会写到RDB文件中主从数据会不一致 解决 主在这三个时间间隙中将收到的写操作命令写入到replication buffer里 主生成RDB文件期间主发送RDB给从期间从加载RDB文件期间 主发送新写操作命令给从 从载入RDB文件后回复一个确认消息给主主将replication buffer里的写操作命令发送给从来执行这时主从的数据就一致了
命令传播 是什么 主从完成第一次同步后双方会维护一个 TCP 长连接后续主通过该连接继续将写操作命令传播给从来执行使主从数据一致
增量复制 为什么需要增量复制 主从服务器在命令传播时网络连接不一定永远稳定若网络不稳定部分写操作命令同步失败主从的数据就会不一致 断开的网络恢复正常后怎么重新保证主从的数据一致 Redis2.8前主从重新进行数据全量复制性能不好Redis2.8后使用增量复制把网络断开期间的写操作命令同步给从 过程 从恢复网络后发送 psync 命令给主此时 psync 命令里的offset不是 -1 主收到 psync 命令后用 CONTINUE 响应命令告诉从将采用增量复制的方式同步数据 主将主从服务器断线期间所执行的写命令发送给从执行 问题 主怎么知道那些是增量数据 存储相关信息 repl_backlog_buffer 一个环形缓冲区用于主从断连后从中找到差异的数据 replication offset 标记环形缓冲区的同步进度 主使用 master_repl_offset 记录自己写到的位置从使用 slave_repl_offset 记录自己读到的位置 主进行命令传播时不仅会将写命令发送给从还会将写命令写入到 repl_backlog_buffer 因此缓冲区里会保存着最近传播的写命令 当从重新连上主服务器时从通过 psync 命令将slave_repl_offset 发送给主主根据 master_repl_offset 和 slave_repl_offset 之间的差距来决定对从服务器执行哪种同步操作 从要读取的数据还在 repl_backlog_buffer 里使用增量同步从要读取的数据不在 repl_backlog_buffer 里使用全量同步 repl_backlog_buffer 默认大小是 1M因其是环形缓冲区当缓冲区写满后主继续写入的话就会覆盖之前的数据。若从想读的数据被覆盖就只能进行全量同步性能损耗较大 优化调整repl_backlog_buffer大小降低覆盖概率 设置多大 sw保险起见可以设置为2sws从断线后重新连接主所需的平均秒数w主平均每秒产生的写命令数据量大小 怎么设置 修改redis.confrepl-backlog-size 1mb
经理角色分摊主服务器的压力 为什么要分摊 主从在第一次数据同步的过程中主会生成 RDB 文件和传输 RDB 文件这两个操作比较耗时 主生成 RDB 文件时会忙于使用 fork() 创建子进程如果主的内存数据非常大执行 fork() 函数时会阻塞主线程使得 Redis 无法正常处理请求传输 RDB 文件会占用主的网络带宽影响主响应命令请求 怎么分摊 从有自己的从节点将拥有从节点的从当作经理角色它不仅接收主的同步数据同时作为主将数据同步给自己的从节点 怎么操作 服务器执行下面命令将其作为经理服务器的从节点。执行完成之后经理就会将数据同步给自己的从节点replicaof 想作为经理的IP Redis端口
哨兵机制
为什么需要哨兵机制
主从模式是读写分离的如果主节点挂了则没法服务客户端的写请求也没有主节点给从节点同步数据。如果需要恢复服务需要人工介入恢复主节点或将一个从节点改为主节点。需要一套更加智能的方式Redis2.8后提供哨兵模式可检测主节点是否存活若主节点挂了则重新推举一个从节点成为主节点并且把新主节点的相关信息通知给从节点和客户端主从故障迁移
哨兵介绍 是什么 哨兵其实是一个运行在特殊模式下的 Redis 进程 做什么 监控主从节点的状态选主通知
如何判断主节点是否故障 主节点主观下线 哨兵节点每隔 1 秒给所有主从节点发送 PING 命令当主从节点收到 PING 命令后会发送一个响应命令给哨兵如果主节点或者从节点没有在规定的时间内响应哨兵就会将它们标记为【主观下线】规定时间设置 修改哨兵配置文件的down-after-milliseconds单位是毫秒 主节点客观下线 可能主节点没有故障只是因为主节点的系统压力比较大或者网络发送了拥塞导致没有在规定时间内响应哨兵的 PING 命令会造成误判 为了减少误判针对主节点还设置了【客观下线】状态即经过集群投票让多个哨兵一起判断避免单个哨兵自身网络不好误判主节点下线认定的下线为【客观下线】单个节点判断的为【主观下线】 投票步骤 当一个哨兵判断主节点为【主观下线】后向其他哨兵发起is-master-down-by-addr 命令其他哨兵收到这个命令后就会根据自身和主节点的网络状况做出赞成投票或者拒绝投票的响应当这个哨兵的赞同票数达到哨兵配置文件中的 quorum 配置项设定的值后这时主节点就会被【该哨兵】标记为【客观下线】如集群中有三个哨兵quorum为2则三个哨兵中至少需要两个赞成发起投票者也算赞成quorum 一般设置为(哨兵个数/2) 1
哪个哨兵进行主从故障转移 在判断主节点客观下线后由哪个节点(Leader)来进行主从故障转移 候选者 那个将主节点标记为【客观下线】的节点其实就是第一个判断主节点为【主观下线】的节点如果某个时间点有两个哨兵节点判断到主节点为客观下线则有两个候选者 Leader选举 候选者会让其他哨兵对它进行投票每个哨兵只有一次投票机会候选者可以投给自己 多个候选者哨兵投给谁 先收到谁的命令就投给谁先到先得 需要满足 拿到半数以上大于半数的赞成票 拿到的票数需要大于等于哨兵配置文件中的 quorum 值 注意候选者会默认给自己投一票没有则需要重新选举 为什么哨兵节点至少要有 3 个 哨兵集群中只有 2 个哨兵节点此时如果一个哨兵想要成功成为 Leader必须获得 2 票只要挂一个就没办法进行主从节点切换哨兵集群中有 3 个哨兵节点要挂一个还是有机会投票成功。挂两个就需要人工介入 为什么 quorum 设置为(哨兵个数/2) 1 如集群有三个节点其中两个节点宕机quorum设置为1这时可以完成客观下线却不能完成主从切换因此quorum设置为1没有意义
主从故障转移的过程 挑选从节点 做什么 在已下线主节点属下的所有从节点里面挑选出一个状态良好、数据完整的从节点给其发送SLAVEOF no one命令将其转换为主节点 怎么做 过滤掉下线和网络状态不好的节点 Redis 有个叫 down-after-milliseconds * 10 配置项其 down-after-milliseconds 是主从节点断连的最大连接超时时间。如果在 down-after-milliseconds 毫秒内主从节点都没有通过网络联系上我们就可以认为主从节点断连了。如果发生断连的次数超过了 10 次就说明这个从节点的网络状况不好不适合作为新主节点 优先级最高的从节点胜出 Redis 有个叫 slave-priority 配置项可以根据服务器配置给从节点设置优先级 复制进度最靠前的从节点胜出 如果某个从节点的 slave_repl_offset 最接近 master_repl_offset说明它的复制进度是最靠前的 ID 号小的从节点胜出 每个从节点都有一个编号这个编号就是 ID 号是用来唯一标识从节点的 被挑选从节点转化为主节点 哨兵 leader 向被选中的从节点发送 SLAVEOF no one 命令让这个从节点解除从节点的身份将其变为新主节点在发送 SLAVEOF no one 命令之后leader 会以每秒一次的频率向被升级的从节点发送 INFO 命令没进行故障转移之前INFO 命令的频率是每十秒一次并观察命令回复中的角色信息当被升级节点的角色信息从原来的 slave 变为 master 时 leader 就知道从节点顺利升级为主节点了 将从节点指向新主节点 哨兵 leader 向所有从节点发送 SLAVEOF 命令让它们成为新主节点的从节点 通知客户端主节点更换信息 通过 Redis 的发布者/订阅者机制来实现。每个哨兵节点提供发布者/订阅者机制客户端可以从哨兵订阅消息主从切换完成后哨兵就会向 switch-master 频道发布新主节点的 IP 地址和端口的消息客户端收到信息然后用新主节点的 IP 地址和端口进行通信通过发布者/订阅者机制机制客户端不仅可以在主从切换后得到新主节点的连接信息还可以监控到主从节点切换过程中发生的各个重要事件。有助于客户端了解主从切换进度事件通知有哪些 旧主节点上线将其变为从节点 主从切换后哨兵集群继续监视旧主节点当旧主节点重新上线时哨兵集群就会向它发送 SLAVEOF 命令让它成为新主节点的从节点
哨兵集群是如何组成 配置哨兵 sentinel monitor 哨兵之间相互感知 配置哨兵时不需要填其他哨兵信息哨兵节点之间可以通过 Redis 的发布者/订阅者机制来相互发现在主从集群中主节点上有一个名为sentinel:hello的频道不同哨兵就是通过它来相互发现实现互相通信的 哨兵集群如何知道从节点信息 主节点知道所有从节点信息所以哨兵会每 10 秒一次的频率向主节点发送 INFO 命令来获取所有从节点的信息
