石材企业网站,蓝色风格的网站,网站制作的网站开发,建网站要钱吗目录
一、哨兵模式
1.1、为何引入哨兵模式
1.2、Redis Sentinel 分布式架构
1.2.1、概述
1.2.2、工作原理#xff08;redis 哨兵的核心功能#xff09;
1. 监控#xff1a;
2. 自动故障转移#xff1a;
3. 通知
1.2.3、问题#xff1a;哨兵结点只有一个可以么redis 哨兵的核心功能
1. 监控
2. 自动故障转移
3. 通知
1.2.3、问题哨兵结点只有一个可以么
1.3、使用 Docker 和 DockerCompose 模拟部署哨兵模式
1.3.1、前言
1.3.2、准备工作
a首先要安装好 docker 和 docker-compose.
b停止之前的 redis 服务器
c使用 docker 获取 redis 镜像
1.2.3、基于 docker 搭建 redis 哨兵环境
a分配文件目录结构
b编写 yml 配置文件
c编写哨兵结点的三个 conf 配置文件
d使用 docker-compose 启动 数据结点
e验证
f使用 docker-compose 启动 redis-sentinel 结点
日志里为什么全都是报错信息呢都是什么意思重
解决方案
1.2.4、展现哨兵机制
1.2.5、哨兵重新选取主节点的流程
1.2.6、缺陷 一、哨兵模式 1.1、为何引入哨兵模式
实际的开发中对于服务器后端开发监控程序是非常重要的服务器一般要有比较高的可用性7 * 24 小时运行服务器长期运行总会有一些 “意外” 具体啥时候出现意外也不能全靠人工来盯着服务器所以在早期的主从结构中会写一个程序来盯着服务器的运行状态.
这个程序需要干两件事
监控程序用来发现服务器运行时出现的异常状态.搭配 “报警程序” 通过 短信/电话/邮件/微信/钉钉... 等形式给程序员报警告诉程序员说这个服务器程序出问题了 Ps互联网公司的程序员尤其是大厂公司都会明确要求程序员手机要 24 小时开机并且随时关注报警不仅仅是给这一个程序员还会给程序员的领导还有领导的领导~ 关键时候错过领导的电话可能就会有比较负面的评价升职加薪就要往后了~ 程序员如何恢复的
先看看主节点还能不能抢救好不好抢救.如果主节点这边出事的原因很难解决就需要挑一个从节点设置为新的主节点 具体的把选中的从节点通过 slaveof no one自立山头.其他的从节点通过修改 slaveof将 ip 和 port 改为新上任的主节点.告知客户端修改客户端配置让客户端能够连接新的主节点用来完成修改数据的操作.最后如果之前挂了的主节点修好了就可以将其作为一个新的从节点加入到这个机器当中. Ps 1.只要是涉及到人工干预不说繁琐至少是很烦人的~ 2.另外这个操作过程一旦出错了就可能让问题更加严重。 3.通过人工干预的做法就算程序员第一时间看到了报警信息第一时间处理也至少需要半个小时以上的恢复时间也就是说这半个小时里整个 redis 就一直不能写显然不合适。 为了提高 “可用性” 引入以下架构模式~ 1.2、Redis Sentinel 分布式架构
1.2.1、概述
Redis Sentinel 是⼀个分布式架构其中包含若干个 Sentinel 节点哨兵和 Redis 数据节点这两种结点之间的哨兵机制是通过独立的进程来体现的和 redis-server 是不同进程redis-sentinel 不负责存储数据只是对其他的 redis-server 进程起到监控的效果. 1.2.2、工作原理redis 哨兵的核心功能 1. 监控
aredis sentinel 进程会监控现有的主从结点这里的监控就是指sentinel 进程会和 主从结构进程 之间建立 tcp 长连接通过这样的长连接定期发送心跳包看主节点是否挂了如果 心跳包 没有如果如约而至就说明 redis 主节点挂了.
b如果是从节点挂了其实没关系如果是主节点挂了哨兵就要发挥作用了此时一个哨兵发现了主节点挂了还不够需要多个哨兵来认同这件事主要防止出现误判网络抖动导致心跳包丢失.
c如果主节点确实挂了这些哨兵结点中就会选举出一个 leader由这个 leader 负责从现有的从节点中挑选出一个新的 主节点.
2. 自动故障转移
d 挑选出新的主节点之后哨兵结点就会自动控制被选中的结点执行 slaveof no one让他先自立山头然后再控制其他从节点修改 slaveof 到新的主节点上.
3. 通知
e哨兵结点会自动通知客户端程序告知新的主节点是谁后续客户端再进行写操作就会针对新的主节点进行操作了. Ps以上这三大点也是 redis 哨兵的核心功能.这里只是粗略的讲了以下 “哨兵重新选取主节点的流程” 后面会详细讲这是面试经常会问的问题 1.2.3、问题哨兵结点只有一个可以么
redis 哨兵结点只有一个也是可以的.
但值得注意的是再分布式系统中应该避免 “单点” 问题1.一个服务器挂了整个就服务就瘫痪了2.并发量有限.
在 redis 中可能会导致以下问题
一个哨兵结点自身也是容易出现问题的万一这一个哨兵结点挂了后续 redis 结点挂了就无法进行自动恢复了.出现误判的概率也比较高因为网络传输数据是容易出现抖动、延迟、丢包等问题的. Ps哨兵结点最好搞奇数个最少也要有 3 个 1.3、使用 Docker 和 DockerCompose 模拟部署哨兵模式
1.3.1、前言
这里我们将以下图为例通过 Docker 和 DockerCompose 部署和编排 3 个哨兵和 1 个主 2 个从结点. 案例说这 6 个结点是要部署到 6 个不同的服务器主机上的.
但我这里只有一个云服务器实际的工作中上述结点放在一个云服务器上事没有意义的这么做也是没办法经济有限 如果直接部署就需要小心避开这些冲突端口号、配置文件、数据文件.... 使用 docker 就可以有效解决上述问题~ 虚拟机就是在电脑上通过软件模拟出另外一些硬件构造了一个台虚拟电脑也就是说通过虚拟机这样的软件就可以使用一个计算机来模拟出多个电脑的情况.
但是虚拟机有个很大的问题很吃配置这个事情对于我的云服务器来说压力山大~
docker 可以认为是一个 “轻量级” 的虚拟机现在后端开发很流行这个组件既不吃很多的硬件资源又可以起到虚拟机这样的隔离环境的效果即使你云服务器配置很低也能构造出好几个这样的虚拟环境. 1.3.2、准备工作
a首先要安装好 docker 和 docker-compose.
这里我之前有出过专门的文章可以去翻翻.
b停止之前的 redis 服务器
如果是通过 redis-server 启动服务器就必须搭配 kill 命令来停止.如果是通过 service redis-server start 启动服务器必须搭配 service redis-server stop 来停止.如果使用 kill 命令停止 service redis-server start 这个 redis-server 进程会自动启动.
c使用 docker 获取 redis 镜像
通过以下命令就可以从 docker hb 上拉取 redis 5.0.9 的镜像
docker pull redis:5.0.9 1.2.3、基于 docker 搭建 redis 哨兵环境 Ps此处涉及到多个 redis server 和多个 redis 哨兵结点每一个 redis server 和每一个 redis 哨兵结点都是作为一个单独的容器按照案例这里总共要部署 6 个容器为了方便部署使用 docker-compose 进行容器编排. a分配文件目录结构 由于 redis 哨兵结点是单独的 redis 服务器进程因此之后对于哨兵和主从结点的 yml 配置文件要分开
虽然也可以使用一个 yml 文件 直接启动 6 个容器但是如果 6 个容器同时启动可能是 哨兵 先启动完成数据节点后启动完成哨兵可能就会先认为是数据结点挂了虽然从大体上来看不影响但是会影响到我们对执行日志的观察. b编写 yml 配置文件
这里分别在 redis-data 目录 和 redis-sentinel 目录下创建一个 yml 配置文件注意文件名必须是 docker-compose.yml 分别用来描述 3 个数据结点和 3 个哨兵结点 具体要创建哪些容器每个容器运行的各种参数描述清除。
后续通过一个简单的命令就可以批量进行 启动/停止 这些容器了. Ps下来讲到的配置文件不需要记只需要了解其中一些参数的意思即可实际工作中不可能让你去写只会让你去 copy 现有的对关键参数进行修改. 数据结点配置文件如下
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对一些关键参数的解释
image当前容器是基于哪个镜像创建的镜像就相当于模板启动镜像就可以构建出容器.container_name自定义容器的名字。docker 中可以通过容器名字, 作为 ip 地址, 进⾏相互之间的访问.restart容器遇到一些异常情况终止了是否重启always 表示一旦遇到异常情况立刻重启 .command用什么命令来启动服务.ports这里的规则是 [宿主机端口] [容器内部端口]。上述配置文件中要启动三个容器master、slave1、slave2这三个容器的内部端口号都是自成一个小天地也就是说容器 1 的 6379 和 容器 2 的 6379 之间是不会有冲突的两个容器可以视为两个主机有的时候希望容器外访问容器内部的端口需要进行端口映射把容器内吨端口映射到宿主机上后续访问宿主机这个端口就相当于在访问对应容器的对应端口了. Ps站在宿主的角度访问上述几个端口的时候也不知道这个端口是一个宿主机上的服务还是来自于容器内部的服务只要正常使用即可。这里的映射过程很像 NAT. 哨兵结点配置文件如下
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对一些关键参数的解释
volumes建立映射. 哨兵结点在运行的过程中会对配置文件进行自动修改因此就不能只拿 /etc/redis/sentinel.conf 这一个配置文件给三个容器分别进行映射. 以上 volumes 的内容就需要我们在当前目录下redis-sentinel目录下继续创建三个 conf 文件. c编写哨兵结点的三个 conf 配置文件
创建 sentinel1.conf、sentinel2.conf、sentinel2.conf 这三个配置文件内容可以是一样的容器启动后会自动对这三个 conf 文件进行修改. bind 0.0.0.0
port 26379
sentinel monitor redis-master redis-master 6379 2
sentinel down-after-milliseconds redis-master 1000
参数解释
bind 0.0.0.0表示让其他结点进行访问.port容器内部使用的端口.sentinel monitor redis-master 6379 2这里是告诉哨兵结点需要监控哪个 redis 服务器. redis-master 这里其实是 ip 地址是使用 docker 自动进行域名解析. 最后的 2 表示法定票数这里的票数就是为了更稳健的确认当前 redis-server 是否挂了不能只听一个哨兵的一面之词.sentinel down-after-milliseconds redis-master 1000这里表示心跳包的超时时间.此处是 1000ms.
d使用 docker-compose 启动 数据结点
使用 docker-compose up -d 命令-d 表示后天运行启动所有容器必须和 docker-compose.yml 同文件路径下 Ps如果启动后发现前面配置有误需要重新操作使用 docker-compose down 即可停止刚创建好的容器. 如果出现以下错误说明 yml 中配置的 version 不支持修改成报错信息中支持的版本即可以下报错中提示只支持 version 为 2.2 或者 3.3 的版本 如下信息为启动成功 通过 redis-compose logs 命令查看运行日志信息 e验证
通过连接 redis 验证主从结构
连接主节点redis-cli -p 6379 连接第一个从节点redis-cli -p 6380 连接第二个从节点redis-cli -p 6381 f使用 docker-compose 启动 redis-sentinel 结点
在 redis-sentine 目录下使用 docker-compose up -d 启动所有容器 通过 docker-compose logs 查看日志文件 日志里为什么全都是报错信息呢都是什么意思重 docker-compose 一下启动了 N 个容器此时 N 个容器都是处于同一个 “局域网” 中可以使这 N个容器之间可以互相访问~
但是 三个 redis-server 结点是一个局域网三个哨兵结点是另外一个局域网默认情况下这两网络是不互通的
解决方案
可以使用 docker-compose 把此处两组服务放到同一个局域网中.
具体的使用 docker network ls 列出当前 docker 中的局域网就可以拿到 redis-data 服务的 docker-compose 文件所在目录名用来修改配置文件 修改哨兵结点中配置文件在之前配置文件的基础上加上如下配置
networks:default:external:name: redisdata_default
然后再启动哨兵观察日志如下 打开 sentinel1.conf 文件就可以看到 哨兵结点启动之后自动进行修改的内容如下 1.2.4、展现哨兵机制
哨兵存在的意义就是在 redis 主从机构出现问题的时候主节点挂了此时哨兵结点能够自动帮我我们重新选出一个主节点来代替之前挂了的结点保证整个 redis 仍然是可用的状态.
这里我们可以通过 docker stop redis-master 命令手动把主节点干掉然后观察哨兵日志可以看到 sdown 主观下线本哨兵结点认为该主节点挂了.odown 客观下线好几个哨兵都认为该主节点挂了也就是达到了法定票数此时这个主节点挂了的事情就被实锤了.
此时就需要先选出一个 leader哨兵由这个 leader 哨兵结点选出一个从节点作为新的主节点.
接着往下看日志就可以看出 3 个哨兵的投票过程. 1.2.5、哨兵重新选取主节点的流程
1. 主观下线sdown哨兵节点通过心跳包判定 redis 服务器是否正常工作. 如果心跳包没有如约而至就说明 redis 服务器挂了. Ps此时还不能排除网络波动的影响因此就只能单方面的认为这个 redis 结点挂了. 比如是否可能出现非常严重的网络波动导致所有哨兵都联系不上 redis 主节点误判成挂了呢 当然可能是有的如果出现这个情况怕是用户的客户端也连接不上 redis 主节点此时这个主节点基本上也就无法正常工作了. “挂了” 不一定是进程崩了只要无法正常访问都可以视为挂了. 2. 客观下线odown多个哨兵都认为主节点挂了认为挂了的哨兵数目到达 “法定票数”哨兵们就认为这个主节点是 客观下线.
3. 多个哨兵结点会通过投票的方式选出一个 leader 哨兵结点有这个 leader 负责选出一个 从节点 作为新的主节点.
具体的每个哨兵手里只有一票接下来的投票过程就是看谁反应快网络延迟小
1 号哨兵 第一个发现当前是客观下线之后就立即给自己投了一票推举自己成为 leader并且告诉 2 3 我来负责这个事情2 3 当他们没有投出这一票的时候拉票请求就会投出去如果有多个拉票请求就投给最先到达的 如下 2 号哨兵不乐意认为自己和 1 号同时发现也给自己投了一票3 号哨兵慢了半拍才发现是客观下线就把这一票投给了 1 号哨兵如下 如果总的票数到达了哨兵总数的一半选举就完成了.把哨兵个数设置成奇数个结点就是为了方便投票.
4. 此时 leader 选举完毕leader 需要挑选出一个从节点作为新的主节点.
具体的挑选从节点的规则如下
a优先级每个 redis 数据结点都会在配置文件中有一个优先级的设置slave-priority优先级高的从节点就会胜出如果没有设置默认优先级都是一样的. 如果当前优先级一样就看下一个规则.
boffset offset 就是从节点从主节点这边同步数据的进度数值越大说明从结点的数据和主节点的数据越接近因此最大的胜出. 如果当前优先级一样就看下一个规则.
crun id每个 redis 结点启动的时候随机生成一串数字大小全随机这时候就是相当于是随机了.
这就像是大学的学生如果和辅导员有亲戚关系那么班长就是钦定的如果没有关系那么就看谁更听她的话如果都是刺头那就只能看谁名字好听了~
5. 新的主节点指定好了之后leader 就会控制这个结点执行 slave no one让其独立山头成为 master然后再控制其他节点执行 slave of让其他节点以新的 master 作为主节点.
6. 最后如果之前挂掉的主节点修复了就直接让这个节点变为从节点加入到机器中为什么不在成为主节点因为成为主节点还需要通过 slave of 修改正在运行的主节点这个过程可能会丢失数据.
使用 docker start redis-master 命令启动恢复之前挂掉的主节点后会发现已经变为从节点 1.2.6、缺陷
哨兵 主从解决的问题是 “提高可用性”不能解决极端情况下写丢失的问题~
最关键的一点就是在数量十分庞大的情况下这种模式就难以胜任了
因此redis 集群就是解决存储容量问题的有效方案.
