陆良县住房和城乡建设局网站,房产网签后能不能退房,网站策划选题,建设工程和工程建设Redis 的主从复制模式下#xff0c;一旦主节点由于故障不能提供服务#xff0c;需要人工进行主从切换#xff0c;同时大量的客户端需要被通知切换到新的主节点上#xff0c;对于上了一定规模的应用来说#xff0c;这种方案是无法接受的#xff0c;于是 Redis 从 2.8 开始…Redis 的主从复制模式下一旦主节点由于故障不能提供服务需要人工进行主从切换同时大量的客户端需要被通知切换到新的主节点上对于上了一定规模的应用来说这种方案是无法接受的于是 Redis 从 2.8 开始提供了 Redis Sentinel哨兵加个来解决这个问题。 一、基本概念 由于对 Redis 的许多概念都有不同的名词解释所以在介绍 Redis Sentinel 之前先对几个名词概念进行必要的说明如下表所示。 Redis Sentinel 相关名词解释 Redis Sentinel 是 Redis 的高可用实现方案在实际的生产环境中对提高整个系统的高可用是非常有帮助的。 1、主从复制的问题 Redis 的主从复制模式可以将主节点的数据改变同步给从节点这样从节点就可以起到两个作用 第一作为主节点的⼀个备份⼀旦主节点出了故障不可达的情况从节点可以作为后备 “顶” 上来并且保证数据尽量不丢失主从复制表现为最终一致性。第二从节点可以分担主节点上的读压力让主节点只承担写请求的处理将所有的读请求负载均衡到各个从节点上。 但是主从复制模式并不是万能的它同样遗留下以下几个问题 主节点发生故障时进行主备切换的过程是复杂的需要完全的人工参与导致故障恢复时间无法保障。 主节点可以将读压力分散出去但写压力 / 存储压力是无法被分担的还是受到单机的限制。其中第一个问题是高可用问题即 Redis 哨兵主要解决的问题。第二个问题是属于存储分布式的问题留给 Redis 集群去解决。 2、人工恢复主节点故障 Redis 主从复制模式下主节点故障后需要进行的人工工作是比较繁琐的在图中大致展示了整体过程。 1Redis 主节点故障后需要进行的操作 实际开发过程中对于服务器后端开发监控程序是非常重要的。服务器要求要有比较高的可用性而服务器长期运行总会出现一些 “意外”但也没法全靠人工来盯着这些服务器运行。所以此时就可以写一个程序用程序来盯着服务器的运行状态监控程序往往还需要搭配 “报警程序” 来发现服务器的运行出现状态异常。 运维人员通过监控系统发现 Redis 主节点故障宕机。 运维人员从所有节点中选择⼀个此处选择了 slave 1执行 slaveof no one使其作为新的主节点。 运维人员让剩余从节点此处为 slave 2执行 slaveof {newMasterIp} {newMasterPort}连上新的主节点从新的主节点开始数据同步。 告知客户端修改客户的的配置让客户端能够连接新的主节点用来完成修改数据的操作需要更新应用方连接的主节点信息到 {newMasterIp} {newMasterPort}。 如果原来挂了的主节点恢复执行 slaveof {newMasterIp} {newMasterPort}让其成为⼀个从节点挂到这组机器中。上述过程可以看到基本需要人工介入无法被认为架构是高可用的而这就是 Redis Sentinel 所要做的。 3、哨兵自动恢复主节点故障 当主节点出现故障时Redis Sentinel 能自动完成故障发现和故障转移并通知应用方从而实现真正的高可用。 Redis Sentinel 是一个分布式架构其中包含若干个 Sentinel 节点和 Redis 数据节点每个 Sentinel 节点会对数据节点和其余 Sentinel 节点进行监控当它发现节点不可达时会对节点做下线表示。如果下线的是主节点它还会和其他的 Sentinel 节点进行 “协商”当大多数 Sentinel 节点对主节点不可达这个结论达成共识之后它们会在内部 “选举” 出一个领导节点来完成自动故障转移的工作同时将这个变化实时通知给 Redis 应用方。整个过程是完全自动的不需要人工介入。整体的架构如下图所示。 这里的分布式架构是指Redis 数据节点、Sentinel 节点集合、客户端分布在多个物理节点上不要与后面将要学习的 Redis Cluster 分布式混淆。 1Redis Sentinel 架构 Redis Sentinel 相比于主从复制模式是多了若干单独的建议保持奇数最少应该是 3 个Sentinel 节点用于实现监控数据节点哨兵节点会定期监控这些进程之间会建立 tcp 长连接通过这样的长连接定期发送心跳包所有节点包含数据节点和其他哨兵节点。 针对主节点故障的情况故障转移流程大致如下 主节点故障从节点同步连接中断主从复制停止。 哨兵节点通过定期监控发现主节点出现故障。哨兵节点与其他哨兵节点进⾏协商达成多数认同主节点故障的共识。这步主要是防止该情况出故障的不是主节点而是发现故障的哨兵节点该情况经常发生于哨兵节点的网络被孤立的场景下。 哨兵节点之间使用 Raft 算法选举出⼀个 leader领导角色由该节点负责后续的故障转移工作。 哨兵领导者开始执行故障转移leader 从节点中选择⼀个作为新的主节点挑选出新的主节点之后哨兵节点就会自动控制这个被选中的节点执行 slaveof no one并且控制其他从节点修改 slaveof 到新的主节点上哨兵节点会自动通知客户端程序告知新的主节点是谁并且后续客户端再进行写操作就会针对新的节点进行操作。 通过上面的介绍可以看出 Redis Sentinel 具有以下几个功能 监控Sentinel 节点会定期检测 Redis 数据节点、其余哨兵节点是否可达。 故障转移实现从节点晋升promotion为主节点并维护后续正确的主从关系。 通知Sentinel 节点会将故障转移的结果通知给应用方。 注意只有一个 Redis 哨兵节点也是可以的。但是万一这个哨兵节点挂了后续 Redis 节点也挂了的话就无法进行自动回复的过程了。而且出现误判的概率也比较高毕竟网络传输数据容易出现抖动、延迟或者丢包等情况只有一个哨兵节点出现上述情况影响较大。 基本原则在分布式系统中应该避免使用 “单点”。 二、安装部署基于 Docker 1、准备工作 1安装 docker 参考【Docker】安装 DockerServer-Centos、GUI-Windows11—— 超详细教程-CSDN博客 2安装 docker-compose # 安装 docker-compose
yum install docker-compose# 停⽌之前的 redis-server
service redis-server stop# 停⽌ redis-sentinel (如果已经有的话)
service redis-sentinel stop# 使⽤ docker 获取 redis 镜像
docker pull redis:5.0.9 docker 中的 “镜像”可以自己构建也可以直接拿别人已经构建好的docker hub 中提供了 Redis 官方提供的镜像可以直接拖下来使用和 “容器” 类似于 “可执行程序” 和 “进程” 的关系。 docker pull 使用 docker 从中央仓库默认就是 docker hub拉取镜像 拉取到的镜像里面包含一个精简的 Linux 操作系统并且上面会安装 Redis。只要直接基于这个镜像创建一个容器跑起来此时 Redis 服务器就搭建好了。 此时就可以基于 Docker 来搭建 Redis 哨兵环境了。 2、编排 redis 主从节点 1编写 docker-compose.yml 此处涉及到多个 redis server同时也有多个 redis 哨兵节点。 每一个 redis server 或者一个 redis 哨兵节点都是作为一个单独的容器此时就可以通过一个配置文件把具体要创建每个容器运行的各种参数描述清楚后续通过一个简单的命令就能够批量的启动 / 停止这些容器了。 创建 ~/redis/redis-data/docker-compose.yml(这个文件名是固定的不能随意乱取)同时 cd 到 yml 所在目录中。其实也可以用一个 yml 文件同时启动所有容器包括数据节点和哨兵节点但这样做可能是哨兵先启动完成数据节点后启动完成哨兵可能就会认为是数据节点挂了虽然对于大局不影响但是会影响到观察执行日志的过程。 version: 3.7
services:master:image: redis:5.0.9container_name: redis-masterrestart: alwayscommand: redis-server --appendonly yesports: - 6379:6379slave1:image: redis:5.0.9container_name: redis-slave1restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- 6380:6379slave2:image: redis:5.0.9container_name: redis-slave2restart: alwayscommand: redis-server --appendonly yes --slaveof redis-master 6379ports:- 6381:6379 三个容器内部的端口号都是自成一派的不同容器之间的 6379 是不会有冲突的可以把它们当作是不同的主机。有的时候我们希望在容器外访问容器内部的端口此时需要进行端口映射把容器里的端口映射到宿主机中后续访问宿主机的这个端口就相当于在访问对应容器的对应端口了。 经典的配置文件格式xml和 html 很相似区别html 中的标签都是标准规定的xml 中的标签都是自定义的 由于 xml 写起来比较繁琐且占用空间后来又有了 json 格式而这里说的 yml 和 json 也有一些相似之处和 json 这种比较直观的键值对结构相比json 是使用 { } 来表示层级结构的yml 则是使用缩进来表示。 yum 相对于 json 的优势对于格式要求更加严格可读性会更好有助于其他人来理解。 注意docker 中可以通过容器名字作为 ip 地址进行相互之间的访问。 也可以直接在 windows 上使用 vscode 编辑好 yml然后在上传到 Linux 上。 2启动所有容器
新的写法是不带中间横杠如下 如果启动后发现前面的配置有误需要重新操作使用 docker-compose down 即可停止并删除刚才创建好的容器。 3查看运行日志 上述操作必须保证工作目录在 yml 的同级目录中才能工作。 4验证
A. 连接主节点 B. 连接从节点 3、编排 redis-sentinel 节点 也可以把 redis-sentinel 放到和上面的 redis 的同⼀个 yml 中进行容器编排此处选择分成两组主要是为了两方面 观察日志方便。确保 redis 主从节点启动之后才启动 redis-sentinel如果先启动 redis-sentinel 的话可能触发额外的选举过程混淆视听不是说先启动哨兵不行而是观察的结果可能存在一定随机性。 1编写 docker-compose.yml 创建 ~/redis/redis-sentinel/docker-compose.yml同时 cd 到 yml 所在目录中。 注意每个目录中只能存在⼀个 docker-compose.yml 文件。 哨兵节点会在运行过程中对配置文件进行自动的修改所以不能拿一个配置文件给三个容器分别映射。 version: 3.7
services:sentinel1:image: redis:5.0.9container_name: redis-sentinel-1restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel1.conf:/etc/redis/sentinel.confports:- 26379:26379sentinel2:image: redis:5.0.9container_name: redis-sentinel-2restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel2.conf:/etc/redis/sentinel.confports:- 26380:26379sentinel3:image: redis:5.0.9container_name: redis-sentinel-3restart: alwayscommand: redis-sentinel /etc/redis/sentinel.confvolumes:- ./sentinel3.conf:/etc/redis/sentinel.confports:- 26381:26379
networks:default:external:name: redis-data_default 也可以直接在 windows 上使用 vscode 编辑好 yml然后在上传到 linux 上。
如果没有加上最后这一段 那么 docker compose 一下子启动 N 个容器此时这 N 个容器都处于同一个 “局域网” 中可以让这 N 个容器之间相互访问。三个 redis-server 节点是一个局域网三个哨兵节点是另一个局域网默认情况下这两网络不是互通的。解决方案就是使用 docker compose 把此处的两组服务给放到同一个局域网中docker network ls 命令可以列出当前 docker 中的局域网此时再启动这三个节点就直接让他们加入到同一个局域网中而不是创建新的局域网。 2创建配置文件
创建 sentinel1.conf、sentinel2.conf、sentinel3.conf三份文件的初始内容是完全相同的都放到 /root/redis-sentinel/ 目录中。 bind 0.0.0.0
port 26379
sentinel monitor redis-master redis-master 6379 2
sentinel down-after-milliseconds redis-master 1000 A. 理解 sentinel monitor
sentinel monitor 主节点名 主节点ip 主节点端⼝ 法定票数
主节点名这个是哨兵内部自己起的名字。主节点 ip部署 redis-master 的设备 ip。此处由于是使用 docker可以直接写 docker 的容器名会被自动 DNS 成对应的容器 ip。主节点端口。法定票数。哨兵需要判定主节点是否挂了但是有的时候可能因为特殊情况比如主节点仍然工作正常但是哨兵节点自己网络出问题了无法访问到主节点了此时就可能会使该哨兵节点认为主节点下线出现误判。使用投票的方式来确定主节点是否真的挂了是更稳妥的做法需要多个哨兵都认为主节点挂了票数 法定票数 之后才会真的认为主节点是挂了。 B. 理解 sentinel down-after-milliseconds
主节点和哨兵之间通过心跳包来进行沟通如果心跳包在指定的时间内还没回来就视为是节点出现故障。
既然内容相同为什么要创建多份配置文件 redis-sentinel 在运行中可能会对配置进行 rewrite修改文件内容。如果用一份文件就可能出现修改混乱的情况。 3启动所有容器 如果启动后发现前面的配置有误需要重新操作使用 docker-compose down 即可停止并删除刚才创建好的容器。 4查看运行日志
上述操作必须保证工作目录在 yml 的同级目录中才能工作。可以看到哨兵节点已经通过主节点认识到了对应的从节点。 5观察 redis-sentinel 的配置 rewrite
再次打开哨兵的配置文件发现文件内容已经被自动修改了。 这里的内容就是自动修改的对比这三份文件, 可以看到配置内容是存在差异的。 三、重新选举
哨兵存在的意义能够在 Redis 主从结构出现问题比如主节点挂了时哨兵节点自动帮我们重新选出一个主节点来代替之前挂了的节点保证整个 Redis 仍然是可用状态。 1、redis-master 宕机之后
手动把 redis-master 干掉 当主节点挂了之后哨兵节点就开始工作了具体如何工作的来观察哨兵的日志 可以看到哨兵发现了主节点 sdown进一步的由于主节点宕机得票达到 3/2达到法定得票于是 master 被判定为 odown。
主观下线Subjectively DownSDown哨兵感知到主节点没心跳了判定为主观下线。客观下线Objectively DownODown多个哨兵达成一致意见才能认为 master 确实下线了。
接下来哨兵们挑选出了⼀个新的 master。在上图中是 172.18.0.3:6379 这个节点。此时对于 Redis 来说仍然是可以正常使用的。 2、redis-master 重启之后
手动把 redis-master 启动起来 观察哨兵日志可以看到刚才新启动的 redis-master 被当成了 slave 使用 redis-cli 也可以进⼀步的验证这⼀点 3、结论
Redis 主节点如果宕机哨兵会把其中的一个从节点提拔成主节点。当之前的 Redis 主节点重启之后这个主节点被加入到哨兵的监控中但是只会被作为从节点使用。 四、选举原理
假定当前环境如上方介绍三个哨兵sentenal1、sentenal2、sentenal3一个主节点redis-master两个从节点redis-slave1、redis-slave2。
当主节点出现故障就会触发重新一系列过程。 1、主观下线
哨兵节点通过心跳包来判断 Redis 服务器是否正常工作。当 redis-master 宕机此时 redis-master 和三个哨兵之间的心跳包就没有了。此时站在三个哨兵的角度来看redis-master 出现严重故障。此时还不能排除网络波动的影响因此三个哨兵均会把 redis-master 判定为主观这个 Redis 节点下线SDown。 2、客观下线
此时哨兵 sentenal1、sentenal2、sentenal3 均会对主节点故障这件事情进行投票。当故障得票数 配置的法定票数之后
sentinel monitor redis-master 172.22.0.4 6379 2
在这个地方配置的 2即为法定票数。此时意味着 redis-master 故障这个事情被做实了此时触发客观下线ODown。
是否可能出现非常严重的网络波动而导致所有的哨兵都联系不上 Redis 主节点而被误判为挂了呢 是有这个可能的。如果出现这个情况怕是用户的客户端也连不上 Redis 主节点了此时这个主节点基本也就无法正常工作了。 “挂了” 不一定是进程崩了只要是无法访问都可以被视为是挂了。 3、选举出哨兵的 leader
接下来需要哨兵把剩余的 slave 中挑选出一个新的 master这个工作不需要所有的哨兵都参与只需要选出个代表称为 leader由 leader 负责进行 slave 升级到 master 的提拔过程。这个选举的过程涉及到 Raft 算法。
假定一共三个哨兵节点S1、S2、S3
每个哨兵节点都给其他所有哨兵节点发起⼀个 “拉票请求”S1 - S2, S1 - S3, S2 - S1, S2 - S3S3 - S1S3 - S2。收到拉票请求的节点会回复一个 “投票响应”。响应的结果有两种可能投 / 不投。比如 S1 给 S2 发了个投票请求, S2 就会给 S1 返回投票响应。到底 S2 是否要投 S1 呢取决于 S2 是否给别⼈投过票了每个哨兵只有一票。如果 S2 没有给别⼈投过票换而言之S1 是第一个向 S2 拉票的那么 S2 就会投 S1否则则不投。⼀轮投票完成之后, 发现得票超过半数的节点自动成为 leader。如果出现平票的情况S1 投 S2S2 投 S3S3 投 S1每人一票就重新再投一次即可。这也是为啥建议哨兵节点设置成奇数个的原因。如果是偶数个则增大了平票的概率带来不必要的开销。leader 节点负责挑选一个 slave 成为新的 master当其他的 sentenal 发现新的 master 出现了就说明选举结束了。
简而言之Raft 算法的核心就是 “先下手为强”。谁率先发出了拉票请求谁就有更大的概率成为 leader。这里的决定因素成了 “网络延时”。网络延时本身就带有一定随机性。
具体选出的哪个节点是 leader这个并不重要重要的是能选出一个节点即可 。 4、leader 挑选出合适的 slave 成为新的 master
挑选规则
比较优先级。优先级高数值小的的上位优先级是配置文件中的配置项slave-priority 或者 replica-priority。比较 replication offset 谁复制的数据多高的上位。比较 run id谁的 id 小谁上位。
当某个 slave 节点被指定为 master 之后
leader 指定该节点执行 slave no one成为 master。leader 指定剩余的 slave 节点都依附于这个新 master。 五、小结
上述过程都是 “无人值守”Redis 自动完成的。这样做就解决了主节点宕机之后需要人工干预的问题提高了系统的稳定性和可用性。 注意事项 哨兵节点不能只有一个否则哨兵节点挂了也会影响系统可用性。哨兵节点最好是奇数个方便选举 leader得票更容易超过半数。哨兵节点不负责存储数据仍然是 redis 主从节点负责存储。哨兵 主从复制解决的问题是 “提高可用性”不能解决 “数据极端情况下写丢失” 的问题。哨兵 主从复制不能提高数据的存储容量。当我们需要存的数据接近或者超过机器的物理内存这样的结构就难以胜任了。 为了能存储更多的数据就引入了集群后面将会详细介绍。
