吐血~~~ 踩了一天的坑,一直没能在Windows环境下搭建成功,正在准备放弃之时,灵感突现,换了一个redis版本,WC!!! 竟然一下成了。
一、Redis 哨兵
1.1 Redis Sentinel 主要功能
Redis Sentinel 为Redis 提供高可用。实际上,这意味着使用 Sentinel,您可以创建一个 Redis 部署,无需人工干预即可抵抗某些类型的故障。
Redis Sentinel 还提供其他附带任务,例如监控、通知,并充当客户端的配置程序。
这是宏观层面的 Sentinel 功能的完整列表:
- 监控: Sentinel 会不断检查您的主实例和副本实例是否按预期工作。
- 通知: Sentinel 可以通过 API 通知系统管理员或其他计算机程序,其中一个受监控的 Redis 实例出现问题。
- 自动故障转移: 如果 master 没有按预期工作,Sentinel 可以启动一个故障转移过程,其中一个副本被提升为 master,其他额外的副本被重新配置为使用新的 master,并且使用 Redis 服务器的应用程序会被告知要使用的新地址连接时。
- 配置提供程序: Sentinel 充当客户端服务发现的权威来源:客户端连接到 Sentinel 以请求负责给定服务的当前 Redis 主节点的地址。如果发生故障转移,Sentinels 将报告新地址。
Sentinel 的分布式特性
1.2 部署前需要了解的关于 Sentinel 的基本知识
- 您至少需要三个 Sentinel 实例才能进行稳健的部署。
- 应该将三个 Sentinel 实例放置在被认为以独立方式发生故障的计算机或虚拟机中。例如,在不同的可用区域上执行的不同物理服务器或虚拟机。
- Sentinel + Redis 分布式系统不保证在故障期间保留已确认的写入,因为 Redis 使用异步复制。然而,有一些方法可以部署 Sentinel,使丢失写入的窗口限于某些时刻,而还有其他不太安全的部署方法。
您的客户需要 Sentinel 支持。流行的客户端库有 Sentinel 支持,但不是全部。
注意:
为什么一个健硕的Redis主从复制结构至少需要三个sentinel?
一个框代表一台计算机或虚拟机,里面是它运行的内容一个master个sentinel±------------------+
| Redis master M1 |
| Redis Sentinel S1 |
±------------------+
只有两个 Sentinel,不要这样做:
如果M1运行的盒子停止工作,S1也停止工作。在另一个盒子 S2 中运行的 Sentinel 将无法授权故障转移,因此系统将变得不可用。
因为 Sentinel 总是需要与大多数sentinel交谈才能启动故障转移。
1.3 添加或删除哨兵
添加哨兵:
由于 Sentinel 实现了自动发现机制,因此将新 Sentinel 添加到您的部署中是一个简单的过程。您需要做的就是启动配置为监视当前活动主站的新 Sentinel。在 10 秒内,Sentinel 将获取其他 Sentinel 的列表以及附加到 master 的副本集。
如果需要一次添加多个Sentinel,建议一个接一个添加,等其他所有Sentinel都知道第一个,再添加下一个。这对于仍然保证多数只能在分区的一侧实现是很有用的,在添加新 Sentinel 的过程中可能会发生故障。
这可以通过在没有网络分区的情况下以 30 秒的延迟添加每个新 Sentinel 来轻松实现。
在该过程结束时,可以使用该命令 SENTINEL MASTER mastername来检查所有 Sentinel 是否同意监视 master 的 Sentinel 总数。
移除 Sentinel 有点复杂:
Sentinel 永远不会忘记已经看到的 Sentinel,即使它们很长时间无法访问,因为我们不想动态更改授权故障转移和创建新配置所需的多数数字。因此,为了删除 Sentinel,应在没有网络分区的情况下执行以下步骤:
停止要移除的 Sentinel 的 Sentinel 进程。
SENTINEL RESET *向所有其他 Sentinel 实例发送命令(*如果您只想重置一个主服务器,则可以使用确切的主服务器名称)。一个接一个,实例之间至少等待 30 秒。
通过检查SENTINEL MASTER mastername每个 Sentinel的输出,检查所有 Sentinel 是否同意当前活动的 Sentinel 数量。
1.4 删除旧的 master 或无法访问的副本
Sentinel 永远不会忘记给定 master 的副本,即使它们很长一段时间都无法访问。这很有用,因为哨兵应该能够在网络分区或故障事件后正确地重新配置返回的副本。
此外,在故障转移后,故障转移的主服务器实际上被添加为新主服务器的副本,这样一旦新主服务器再次可用,它将被重新配置为与新主服务器进行复制。
但是,有时您希望从 Sentinels 监视的副本列表中永远删除一个副本(可能是旧的 master)。
为此,您需要向SENTINEL RESET mastername所有 Sentinel发送一个命令:它们将在接下来的 10 秒内刷新副本列表,只添加从当前主INFO输出中列为正确复制的副本。
1.5 SDOWN和ODOWN故障状态
Redis Sentinel 有两种不同的停机概念,一种称为主观停机条件 (SDOWN),是给定 Sentinel 实例本地的停机条件。另一种称为客观关闭 条件(ODOWN),当足够多的 Sentinels(至少配置为quorum被监控主机的参数的数量)具有 SDOWN 条件时达到,并使用SENTINEL is-master-down-by-addr命令从其他 Sentinels 获取反馈。
从 Sentinel 的角度来看,当它在配置中作为is-master-down-after-milliseconds 参数指定的秒数内没有收到对 PING 请求的有效回复时,就会达到 SDOWN 条件。
对 PING 的可接受回复是以下之一:
- PING 回复 +PONG。
- PING 回复 -LOADING 错误。
- PING 回复 -MASTERDOWN 错误。
任何其他回复(或根本没有回复)都被视为无效。但是请注意,在 INFO 输出中将自己宣传为副本的逻辑主机被视为已关闭。
请注意,SDOWN 要求在配置的整个间隔内不会收到任何可接受的回复
例如: 如果间隔是 30000 毫秒(30 秒)我们在30秒内未收到任何PING回复,则就满足了SDOWN条件。
SDOWN 不足以触发故障转移: 它仅意味着单个 Sentinel 认为 Redis 实例不可用。要触发故障转移,必须达到 ODOWN 状态。
要从 SDOWN 切换到 ODOWN,没有使用强一致性算法,而只是一种八卦形式:如果给定的 Sentinel 收到报告说在给定的时间范围内没有足够的 Sentinel 工作,则 SDOWN 被提升为 ODOWN。如果此确认稍后丢失,则清除该标志。
需要使用实际多数的更严格的授权才能真正启动故障转移,但不达到 ODOWN 状态就不能触发故障转移。
**ODOWN 条件仅适用于 masters。**对于其他类型的实例,哨兵不需要采取行动,因此副本和其他哨兵永远不会达到 ODOWN 状态,但只有 SDOWN 是。
1.6 哨兵和副本自动发现
Sentinel 与其他 Sentinel 保持连接,以便相互检查彼此的可用性并交换消息。但是,您不需要在您运行的每个 Sentinel 实例中配置其他 Sentinel 地址的列表,因为 Sentinel 使用 Redis 实例的 Pub/Sub 功能来发现正在监视相同主节点和副本的其他 Sentinel。
类似地,您不需要配置附加到主服务器的副本列表是什么,因为 Sentinel 会通过查询 Redis 自动发现此列表。
每个 Sentinel__sentinel__:hello每两秒向每个受监控的主和副本 Pub/Sub 通道发布一条消息,通过 ip、端口、runid 宣布其存在。
每个 Sentinel 订阅__sentinel__:hello每个 master 和 replica的 Pub/Sub 通道,寻找未知的哨兵。当检测到新的哨兵时,将它们添加为该主站的哨兵。
Hello 消息还包括主站的完整当前配置。如果接收 Sentinel 的给定 master 的配置比收到的旧,它会立即更新为新配置。
在向主服务器添加新哨兵之前,哨兵总是检查是否已经存在具有相同 runid 或相同地址(IP 和端口对)的哨兵。在这种情况下,所有匹配的哨兵都会被删除,并添加新的哨兵。
二、WIndows下搭建reids主从复制
2.1 实现目标
![在这里插入图片描述](https://img-blog.csdnimg.cn/20210709140354825.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80NDIwNTA4Nw==,size_16,color_FFFFFF,t_70)
- 搭建一主二从三哨兵的结构
- salve会不断的从master从拉取最新的数据,进行数据同步
- 哨兵可以检测到master宕机后,在salve中经过选举重新选择一个可用的服务器作为master继续工作
- 当宕机后的redis服务器恢复正常时,sentinel可以监听的到,把他作为一个slave进行监听,并且它也可以与master进行数据同步
2.2 材料准备
友情提醒!!!!
踩坑1
windows版 redis 5.0版本的亲测部署不成功,可能由于本人过菜,哎!!!
windows版 redis3.0版本可以顺畅搭建,是真的顺畅!!!
redis下载链接:
因为Redis从不发行wWindows版本的,所以Redis官方获取不到资源,我们可以从Github上搞到,链接:Windows版Redis3.0下载
下载之后放到一个文件夹中
注意!!!
路径最好不要带中文字符,以免出现奇葩的问题。
效果如图所示:
2.3 修改配置文件
1、由于我们要搭建的是一主二从三哨兵的结构,所以我们需要复制2份reids.windows.conf文件,分别命名为redis.windows6380.conf和redis.windows6381.conf
2、修改reids.windows.conf的配置内容
密码,也可不设置(如果有,所有的redis密码设置都要一致)
requirepass 123456
reids.windows.conf配置文件修改如下:
port 6379
bind 127.0.0.1
redis.windows6380.conf配置文件修改如下:
port 6380
bind 127.0.0.1
slaveof 127.0.0.1 6379
# 6379的密码,如果没有可不设置(如果有,所有的redis密码设置都要一致)
masterauth 123456
redis.windows6381.conf配置文件修改如下:
port 6381
bind 127.0.0.1
slaveof 127.0.0.1 6379
# 6379的密码,如果没有可不设置(如果有,所有的redis密码设置都要一致)
masterauth 123456
3、创建并配置sentinel.conf文件
因为我们需要创建三个哨兵所以我们就需要创建三个sentinel.conf文件,配置内容如下:
- **port 😗*当前Sentinel服务运行的端口
- sentinel monitor mymaster 127.0.0.1 6379 2: Sentinel去监视一个名为mymaster的主redis实例,这个主实例的IP地址为本机地址127.0.0.1,端口号为6379,而将这个主实例判断为失效至少需要2个 Sentinel进程的同意,只要同意Sentinel的数量不达标,自动failover就不会执行
- sentinel down-after-milliseconds mymaster 5000: 指定了Sentinel认为Redis实例已经失效所需的毫秒数。当 实例超过该时间没有返回PING,或者直接返回错误,那么Sentinel将这个实例标记为主观下线。只有一个 Sentinel进程将实例标记为主观下线并不一定会引起实例的自动故障迁移:只有在足够数量的Sentinel都将一个实例标记为主观下线之后,实例才会被标记为客观下线,这时自动故障迁移才会执行
- sentinel parallel-syncs mymaster 1: 指定了在执行故障转移时,最多可以有多少个从Redis实例在同步新的主实例,在从Redis实例较多的情况下这个数字越小,同步的时间越长,完成故障转移所需的时间就越长
- sentinel failover-timeout mymaster 15000: 如果在该时间(ms)内未能完成failover操作,则认为该failover失败
sentinel01.conf内容:
port 26379
sentinel monitor mymaster 127.0.0.1 6381 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 15000
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码,没有的话不用设置
# sentinel auth-pass mymaster 123456
sentinel02.conf内容:
port 26380
sentinel monitor mymaster 127.0.0.1 6381 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 15000
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码,没有的话不用设置
# sentinel auth-pass mymaster 123456
sentinel03.conf内容:
port 26381
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 5000
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码,没有的话不用设置
# sentinel auth-pass mymaster 123456
效果图:
3、安装服务,设置名称
在reids文件根目录中,右键选择当前窗口进入命令窗口
或者用cmd cd到这个路径下(能懒咱们就懒!!!)
依次执行下方三条命令,显示successfully即为成功
redis-server --service-install redis.windows.conf --service-name redis6379
redis-server --service-install redis.windows6380.conf --service-name redis6380
redis-server --service-install redis.windows6381.conf --service-name redis6381
都执行成功后,就可以在服务管理器中看到,这三个服务了,现在还是未启动状态
4、启动Redis服务
1、分别启动master,slave1,slave2启动命令分别如下:
redis-server.exe redis.windows.conf
redis-server.exe redis.windows6380.conf
redis-server.exe redis.windows6381.conf
2、分别启动sentinel1,sentinel2,sentinel3启动命令分别如下:
redis-server.exe sentinel01.conf --sentinel
redis-server.exe sentinel02.conf --sentinel
redis-server.exe sentinel03.conf --sentinel
服务启动成功后,界面显示如下:
5、主从复制功能测试
测试一:slave是否可以拷贝master数据
在master中set一个key,在slave中看是否可以get到:
结论:可以
cd进入redis根目录,输入命令,进入master客户端:
redis-cli -h 127.0.0.1 -p 6381
set key1 hello1
测试二:主服务器是否可以拷贝从服务器数据
在slave中set一个key,在master中是否能get到
结论: 不能,slave仅可读,不可写
测试三:当master宕机后是否会选举新的master
关掉master服务器,观察是否有新的master产生
**结论:**成功
1、cd到redis根目录,在sentinel服务器中依次运行以下两条命令查看当前master信息
redis-cli.exe -h 127.0.0.1 -p 26379
sentinel master mymaster
关闭redis 6381 后再通过sentinel询问master的最新消息
此时master已经切换为6380的了
并且通过master 6380 查看配置信息发现,slave的个数变为了1
命令:
redis-cli -h 127.0.0.1 -p 6380
info replication
测试四:新启动一个slave服务器,观察是否自动能够加入集群中
将关闭的6381服务器,重新启动,然后查看master的配置信息观查
**结论:**可以
connected_slave:已经由1变成了2,并且下方也有salve的详细信息。
到此结束,谢谢您还在!!!
如有疑问,+V :17396355824 欢迎打扰!!!!
上一篇:四、redis之分区讲解
下一篇:六、Redis集群讲解与搭建(保姆式解析!!!)