㈠ redis哨兵连接报EOF
redis哨兵技术主要作用和解决的问题是：
持久化：是最简单的高可用方法，主要作用是数据备份，即将数据存储在硬盘，保证数据辩敬不会因进程退出而丢失。
复制：是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。
哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷是写携游慎操作无法负载均衡；存储能力磨山受到单机的限制。
集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。
㈡ Redis哨兵（Sentinel）模式
主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。 这不是一种推荐的方式，更多时候，我们优先考虑 哨兵模式 。
哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是 哨兵通过发送命令，等待Redis服务器响应，从而监控运行的多个Redis实例。
这里的哨兵有两个作用
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
用文字描述一下 故障切换（failover） 的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为 主观下线 。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为 客观下线 。这样对于客户端而言，一切都是透明的。
配置3个哨兵和1主2从的Redis服务器来演示这个过程。
首先配置Redis的主从服务器，修改redis.conf文件如下
上述内容主要是配置Redis服务器，从服务器比主服务器多一个slaveof的配置和密码。
配置3个哨兵，每个哨兵的配置都是一样的。在Redis安装目录下有一个sentinel.conf文件，一份进行修改
上述关闭了保护模式，便于测试。
有了上述的修改，我们可以进入Redis的安装目录的src目录，通过下面的命令启动服务器和哨兵
注意启动的顺序。 首先是主机（192.168.11.128）的Redis服务进程，然后启动从机的服务进程，最后启动3个哨兵的服务进程。
上面是通过Jedis进行使用的，同样也可以使用Spring进行配置RedisTemplate使用。
sentinel down-after-milliseconds配置项只是一个哨兵在超过规定时间依旧没有得到响应后，会自己认为主机不可用。对于其他哨兵而言，并不是这样认为。哨兵会记录这个消息，当拥有认为主观下线的哨兵达到sentinel monitor所配置的数量时，就会发起一次投票，进行failover，此时哨兵会重写Redis的哨兵配置文件，以适应新场景的需要。
㈢ 访问redis哨兵读数据
你好，Redis哨兵
Redis的主从复制模式下,一旦主节点由于故障不能提供服务,需要人工将从节点晋升为主节点,同时还要通知应用方更新主节点地址,对于很多应用场景这种故障处理的方式是无法接受的。可喜的是Redis从2.8开始正式提供了Redis Sentinel (哨兵)架构来解决这个问题,本章会对Redis Sentinel进行详细分析。
基本概念
名词 逻辑结构 物理结构 主节点 Redis主服务 一个独立的Redis进程 从节点 Redis从服务 一个独立的Redis进程Redis数据节点 主节点和从节点 主节点和从节点的进程 Sentinel节点 监控Redis数据节点 一个独立的Sentinel进程 Sentinel节点集合 若干个Sentinel节点的抽象组合 若干个Sentinel节点进程 Redis Sentinel Redis高可用方案Sentinel节点集合和Redis数据及诶单进程
主从复制的问题
Redis的主从复制模式可以将主节点的数据改变同步给从节点,这样从节点就可以起到两个作用:第一,作为主节点的一个备份,一旦主节点出了故障不可达的情况,从节点可以作为后备“顶”上来,并且保证数据尽量不丢失(主从复制是最终一致性)。 第二,从节点可以扩展主节点的读能力,一旦主节点不能支撑住大并发量的读操作,从节点可以在一定程度上帮助主节点分担读压力。 但是主从复制也带来了以下问题: （1）一旦主节点出现故障,需要手动将一个从节点晋升为主节点,同时需要修改应用方的主节点地址,还需要命令其他从节点去复制新的主节点,整个过程都需要人工干预。 （2）主节点的写能力受到单机的限制。 （3）主节点的存储能力受到单机的限制。
高可用
Redis主从复制模式下,一旦主节点出现了故障不可达,需要人工干预进行故障转移.无论对于Redis的应用方还是运维方都带来了很大的不便。对于应用方来说无法及时感知到主节点的变化,必然会造成一定的写数据丢失和读数据错误,甚至可能造成应用方服务不可用。对于Redis的运维方来说,整个故障转移的过程是需要人工来介入的,故障转移实时性和准确性上都无法得到保障，一个1主2从的Redis主从复制模式下的主节点出现故障后,是如何进行故障转移的。 1)主节点发生故障后,客户端(client)连接主节点失败,两个从节点与主节点连接失败造成复制亩让帆中断。 2)如果主节点无法正常启动,需要选出一个从节点(slave-1),对其执行slaveof no one命令使其成为新的主节点。 3)原来的从节点（slave-1）成为新的主节点后，更新应用方的主节点信息，重新启动应用方 4)客户端命令另一个从节点（slave-2）去复制新的主节点（new-master） 5)待原来的主节点恢复后，让它去复制新的主节点。上述滑春处理过程就可以认为整个服务或者架构的设计不是高可用的,因为整个故障转移的过程需要人为介入。考虑到这点,有些公司把上述流程自动化了,但是仍然存在如下问题:第一，断节点不可达的机制是否健全和标准。第二,如果有多个从节点,怎样保证只有一个被晋升为主节点。第三，通知客户端新的主节点机制是否足够强壮。Redis Sentinel正是用于解决这个问题。
Redis Sentinel的高迅雹可用性当主节点出现故障时, Redis Sentinel能自动完成故障发现和故障转移,并通知应用方,从而实现真正的高可用。Redis Sentinel是一个分布式架构,其中包含若干个Sentinel节点和Redis数据节点,每个Sentinel节点会对数据节点和其余Sentinel节点进行监控,当它发现节点不可达时,会对节点做下线标识。如果被标识的是主节点,它还会和其他Sentinel节点进行“协商”,当大多数Sentinel节点都认为主节点不可达时,它们会选举出一个Sentinel节点来完成第六章sentinel.md2020/3/132 / 4自动故障转移的工作,同时会将这个变化实时通知给Redis应用方。整个过程完全是自动的,不需要人工来介入,所以这套方案很有效地解决了Redis的高可用问题。Redis Sentinel与Redis主从复制模式只是多了若于Sentinel节点,所以Redis Sentinel并没有针对Redis节点做了特殊处理,这里是很多开发和运维人员容易混淆的。从逻辑架构上看, Sentinel节点集合会定期对所有节点进行监控,特别是对主节点的故障实现自动转移。假设我们现在有一个主节点，两个从节点和三个Sentinel节点组成的Redis Sentinel的例。 整个故障转移的处理逻辑有下面4个步骤: 1)主节点出现故障,此时两个从节点与主节点失去连接,主从复制失败 2)每个Sentinel节点通过定期监控发现主节点出现了故障。 3)多个Sentinel节点对主节点的故障达成一致,选举出其中一个sentinel节点作为领导者负责故障转移。 4)Sentinel领导者节点执行了故障转移。通过上面介绍的Redis Sentinel逻辑架构以及故障转移的处理,可以看出Redis Sentinl具有以下几个功能: （1）监控: Sentinel节点会定期检测Redis数据节点、其余Sentinel节点是否可达。 （2）通知: Sentinel节点会将故障转移的结果通知给应用方。 （3）主节点故障转移:实现从节点晋升为主节点并维护后续正确的主从关系。 （4）配置提供者:在Redis Sentinel结构中,客户端在初始化的时候连接的是Sentinel节占 集合,从中获取主节点信息。同时看到, Redis Sentinel包含了若干个Sentinel节点,这样做也带来了两个好处: （1）对于节点的故障判断是由多个Sentinel节点共同完成,这样可以有效地防止误判。 （2）Sentinel节点集合是由若干个Sentinel节点组成的,这样即使个别Sentinel节点不可用,整个Sentinel节点集合依然是健壮的。 但是Sentinel节点本身就是独立的Redis节点,只不过它们有一些特殊,它们不存储数据,只支持部分命令。
㈣ SpringBoot连接redis哨兵模式
设置 sentinel-26377.conf 的 protected-mode no ；默认是该字段值是yes
修改问题[1]中为redis集群master节点的真实地址；
修改问题[2]中为 bind 0.0.0.0
【注】redisTemplate实际上是对其他哗颂咐框架的的封装，springboot2.x以上底层实现由jedis变为了lettuce。而且lettuce会根据樱亩配置自动选择是否用单机或者哨兵模式。
【1】 Redis 哨兵模式 设置密码
【2】 sentinel搭建redis集群经验总结
【3】SpringBoot2.x使用乱纯Lettuce连接redis哨兵报错：RedisConnectionException: Unable to connect to 127.0.0.1:16379]： https://blog.csdn.net/repAgell/article/details/106600960
【4】解决使用jedis连接是报DENIED Redis is running in protected mode错误： https://www.cnblogs.com/lonecloud/p/9084761.html
㈤ 已解决：客户端无法登录Redis服务器报错，解除保护模式
一：问题如下
[sql] view plain
在192.168.56.57客户端登录192.168.56.56的redis服务器时，报错如下：
[root@localhost src]# ./redis-cli -h 192.168.56.56 -p 6379 -a"aabbcc"
192.168.56.56:6379> ping
Error:Connection reset by peer
再喊行telnet一下192.168.56.56的redis服务器的6379端口,提示redis服务有保护模式,需要解除
[root@localhost src]# telnet 192.168.56.56 6379
Trying 192.168.56.56...
Connectedto 192.168.56.56.
Escape character is '^]'.
DENIED 蚂渗差Redisis running in protected modebecause protected mode is enabled, no bind address was specified, noauthentication password is requested to clients.
In this mode connections areonly accepted from the loopback interface. If you want to connect from externalcomputers to Redis you may adopt one of the following
solutions: 1) Justdisable protected mode sending the command'CONFIG SET protected-mode no' fromthe loopback interface by connecting to Redis from the same host
the server isrunning, however MAKE SURE Redisis not publicly accessible from internet ifyou do so. Use CONFIG REWRITE to make this change permanent.
2) Alternativelyyou can just disable the protected modeby editing the Redis configurationfile, and setting the protected mode option to 'no', and then restarting theserver.
3) If you started the server manually justfor testing, restart it withthe '--protected-mode no' option.
4) Setup a bind addressor an authenticationpassword. NOTE: You only need to do one of the above things in order for theserver to start accepting connections from the outside.
Connection closed by 闷皮foreign host.
二：解决方案
[sql] view plain
1、修改redis服务器的配置文件
vi redis.conf
注释以下绑定的主机地址
# bind 127.0.0.1
2、修改redis服务器的参数配置
修改redis的守护进程为no ，不启用
127.0.0.1:6379> configset daemonize "no"
OK
修改redis的保护模式为no，不启用
127.0.0.1:6379> configset protected-mode "no"
OK
三：问题解决
[sql] view plain
再次telnet一下192.168.56.56的redis服务器的6379端口，无问题
[root@localhost Packages]# telnet 192.168.56.56 6379
Trying 192.168.56.56...
Connectedto 192.168.56.56.
Escape character is '^]'.
再次在192.168.56.57客户端登录192.168.56.56的redis服务器，无问题
[root@localhost src]# ./redis-cli -h 192.168.56.56 -p 6379 -a"aabbcc"
192.168.56.56:6379> ping
PONG
㈥ Redis哨兵模式（故障转移测试）
哨兵模式是在主备模式的基础上，加上哨兵，实现redis集群的故障转移。哨兵负责监控集群状态，当redis主节点发生故障，哨兵通过选举，选出替代的master节点。一般需要单数的哨兵进行选举，大多数达成一致。
问题：如果哨兵集群也有部分实例down了，出现偶数哨兵，或者只剩下一个哨兵会如何，还能进行故障转移吗。
为什么会出现这个问题：哨兵其实也是redis实例，一般情况下，哨兵是为了保证redis集群的故障转移。由于资源，以及网络通信的性能考虑，一般哨兵和redis会部署在同一物历唤游理机。如果一台物理机出现了物理故障，哨兵实例和redis服务实例会一起down掉。
本文章针对这个问题做一下实验。
使用3+3模式，3redis+3sentinel。
三台虚拟机，每台虚拟机运行1个redis+1个sentinel
ip、角色规划
192.168.237.101：master，sentinel
192.168.237.100：slave，sentinel
192.168.237.103：slave，sentinel
安装redis、redis sentinel
apt-get install redis-server
apt-get install redis-sentinel
redis-server配置修改(/etc/redis/redis.conf)
redis-server slave配置修改
启动redis-server
/etc/init.d/redis-server restart
查看redis-server主从集群情况
修改sentinel配置(/etc/redis/sentinel.conf)
sentinel monitor mymaster 192.168.237.101 6379 2
sentinel known-slave mymaster 192.168.237.100 6379
protected-mode no
启动sentinel
/etc/init.d/redis-sentinel start
查看redis-sentinel情况
预期：故障转移，哨兵选举出新的master
关掉redis-server（192.168.237.101）
查看sentinel日志（/链者var/log/redis/redis-sentinel.log）
可以看到，+odown master，哨兵检测master客观下线
然后进行投票：vote-for-leader
选出新的master：switch-master mymaster 192.168.237.101 6379 192.168.237.103 6379
192.168.237.101的sentinel日志：
查看redis和sentinel集群状态，确认master变成了192.168.237.103（master host）
恢复192.168.237.101的redis-server，查看日志，192.168.237.101转换成slave
预期：有两个sentinel，可能会出现，剩下两个slave各得一票的情况，按照哨兵原理，会等待一段时间进行再选举，直到某个slave有两票，完肢销成故障转移。
经过3.1实验，master转换到了192.168.237.103，现在先后关掉103上的sentinel和redis-server
查看两台sentinel的redis-sentinel日志，可以选出master，进行故障转移：
查看redis集群状态，确认master（192.168.237.100）
预期：无法切换
依次关掉两个sentinel，一个redis-server master。3.2节master转移到了100，恢复环境后，依次关掉103,100的sentinel，100的redis-server master
查看101上的sentinel日志，由于只有一个sentinel，只有101上的sentinel投票
恢复一个redis-sentinel，现有两个redis-sentinel
查看sentinel日志，选出101为master
有两个sentinel或以上可以进行故障切换。单数sentinel更容易选出master，进行故障转移。
+sdown：主观down机
+odown：客观down机
+new-epoch：集群递增版本号
+vote-for-leader：在哨兵集群中投票选举出一个哨兵，作为本次执行故障转移操作的leader
+try-failover：开始对某ip进行故障转移
voted for：另一个哨兵进行投票
+elected-leader：在哨兵集群中再次确认进行即将执行故障转移的leader是哪一个哨兵。
+selected-slave slave：选出leader
+failover-state-send-slaveof-noone slaveLeader：向目标slave发送"slaveof-noone"指令，令其不要再做其它任何节点的slave了，从现在开始，它就是老大，完成从slave到master的转换。
+failover-state-wait-promotion slave：等待其它的sentinel确认slave
+promoted-slave slave：其它的sentinel全部确认成功
+failover-state-reconf-slaves：开始对集群中的所有slave做reconf操作(更新配置信息)
+slave-reconf-sent：向指定的slave发送"slaveof"指令，令其跟随新的master
+switch-master：故障转移完毕后，各个sentinel开始监控新的master
㈦ redis哨兵模式从节点挂了应用报错
换了返喊节点报错说明漏察野应用节点不稳定与节点的兼容性较没链差。需要重新更换节点进行操作尝试重新连接，以便恢复正常使用，仍然不能使用，请重装redis即可
㈧ redis哨兵故障转移及实现
sentinel 是一个特殊的 redis 节点，它有自己专属的 api ：
sentinel masters
展示所有被监控的主节点状态及相关信息：
sentinel master <master name>
展示指定 <master name> 状态以及相关的信猜梁息：
sentinel slaves <master name>
展示指定 <master name> 的从节点状态以及相关的统计信息：
sentinel sentinels <master name>
展示指定 <master name> 的 sentinel 节点集合（不包含当前 sentinel 节点）：
sentinel get-master-addr-by-name <master name>
获取主节点信息：
sentinel failover <master name>
对 <master name> 进行强制故障转移：
修改配置：
Master 可能会因为某些情况宕机了，如果客户端是固定一个地址去访问，肯定是不合理的，所以客户端请求是请求哨兵，从哨兵获取主机地址的信息，或者是从机的信息。可以实现一个例子：
执行 docker-composer up 之后 sentinel.conf 发生了变化，每个配置文件变化如下：
sentinelconfsentinel.conf
sentine2confsentinel.conf
sentine3confsentinel.conf
从变化中可以看出每台 Sentinel 分别记录了 slave 的节点信息和其它 Sentinel 节点信息。
在宿主机中随便进入一台 Sentinel ：
可以观察到监听的所有 master ，将 192.168.3.2 这台 master 进行宕机
docker stop redis-master
宕机完之后等待 Sentinel 检测周期过了之后再对 sentinel.conf 和 redis.conf 进行观察。
3台氏银 Sentinel 的 sentinel monitor mymaster 192.168.3.2 6379 2 变成了 sentinel monitor mymaster 192.168.3.4 6379 2
其次master对应的slave节点信息也进行更改。
而 192.168.3.3 的 redis.conf 中 replicaof 192.168.3.2 6379 也变成了 replicaof 192.168.3.4 6379 。
192.168.3.2 的 redis.conf 中 replicaof 192.168.3.2 6379 这行配置被删除掉了。
再次启动 192.168.3.2 的 redis 节点，而这台节点的 redis.conf 中增加了一行 replicaof 192.168.3.4 6379 。
其实就是将我们的操作自动化了。
Sentinel 的实现原理，穗核运主要分为三个步骤：
回顾上一篇文章中 Sentinel 的配置。
主观下线：每个 Sentinel 节点对 Redis 失败的“偏见”。之所以是偏见，只是因为某一台机器30s内没有得到回复。
客观下线：这个时候需要所以 Sentinel 节点都发现它30s内无回复，才会达到共识。
Redis 内部其实是有一个优先级配置的，在配置文件中 replica-priority ，这个参数是 slave 节点的优先级配置，如果存在则返回，如果不存在则继续。当上面这个优先级不满足的时候， Redis 还会选择复制偏移量最大的 Slave 节点，如果存在则返回，如果不存在则继续。之所以选择偏移量最大，这是因为偏移量越小，和 Master 的数据越不接近，现在 Master 挂掉了，说明这个偏移量小的机器数据可能存在问题，这就是为什么选择偏移量最大的 Slave 的原因。如果发现偏移量都一样，这个时候 Redis 会默认选择 runid 最小的节点。
生产环境部署技巧：
哨兵集群在发现 master node 挂掉后会进行故障转移，也就是启动其中一个 slave node 为 master node 。在这过程中，可能会导致数据丢失的情况。
造成的问题：
此时哨兵可能就会认为 master 宕机了，然后开始选举，将其它 slave 切换成 master 。这时候集群里就会有2个 master ，也就是所谓的脑裂。此时虽然某个 slave 被切换成 master ，但是可能 client 还没来得及切换成新的 master ，还继续写向旧的 master 的数据可能就丢失了。因此旧 master 再次被恢复的时候，会被作为一个 slave 挂到新的 master 上去，自己的数据会被清空，重新从新的 master 复制数据。
怎么解决：
要求至少有一个 slave ，数据复制和同步的延迟不能超过10s。
如果说一旦所有的 slave ，数据复制和同步的延迟都超过了10s，这个时候， master 就不会再接收任何请求了。
上面两个配置可以减少异步复制和脑裂导致的数据丢失。
异步复制导致的数据丢失：
在异步复制的过程当中，通过 min-slaves-max-lag 这个配置，就可以确保的说，一旦 slave 复制数据和 ack 延迟时间太长，就认为可能 master 宕机后损失的数据太多了，那么就拒绝写请求，这样就可以把 master 宕机时由于部分数据未同步到 slave 导致的数据丢失降低到可控范围内。
集群脑裂导致的数据丢失：
集群脑裂因为 client 还没来得及切换成新的 master ，还继续写向旧的master的数据可能就丢失了通过 min-slaves-to-write 确保必须是有多少个从节点连接，并且延迟时间小于 min-slaves-max-lag 多少秒。
客户端需要怎么做：
对于 client 来讲，就需要做些处理，比如先将数据缓存到内存当中，然后过一段时间处理，或者连接失败，接收到错误切换新的 master 处理。
㈨ 5.Redis的哨兵服务
0.Redis主从架构的问题
1.哨兵服务介绍
2.架构图
3.主从服务搭建
4.配置哨兵服务
5.启动哨兵服务吵肢
6.验证哨兵服务
对于Redis的主从架构而言，无法实现 master 和 slave 角色的自动切换， 即当 master 出现 redis 服务异常、主机断电、磁盘损坏等问题导致 master 无法使用，而 redis 高可用无法实现自故障转移(将 slave 提升为 master)，需要手动改环境配置才能切换到 slave redis 服务器。另外无法横向扩展 Redis 服务的并行写入性能， 当单台 Redis 服早派务器性能无法满足业务写入需求的时候就必须需要一种方式解决此问题。
1.master和slave角色的无缝切换，让业务无感知从而不影响业务使用
2.可以横向动态扩展Redis服务器, 从而实现多台服务器并行写入以实现更高并发的目的。
Sentinel进程是用于监控redis集群中Master主服务器工作的状态，在Master主服务器发生故障的时候，可以实现Master和Slave服务器的切换，保证系统的高可用，其已经被集成在 redis2.6+的版本中，Redis的哨兵模式到了2.8版本之后就稳定了下来。一般在生产环境也建议使用Redis2.8以后版本。哨兵(Sentinel)是一个分布式系统，你可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossipprotocols)来接收关于Master主服务器是否下线的信息，并使用投票协议(Agreement Protocols)来决定是否执行自动故障迁移,以及选择哪个 Slave 作为新的 Master。每个哨兵(Sentinel)进程会向其它哨兵(Sentinel)、Master、Slave定时发陆碰贺送消息，以确认对方是否”活”着，如果发现对方在指定配置时间(可配置的)内未得到回应，则暂时认为对方已掉线，也就是所谓的”主观认为宕机” ，英文名称：Subjective Down，简称SDOWN。有主观宕机，肯定就有客观宕机。当“哨兵群”中的多数 Sentinel 进程在对 Master 主服务器做出 SDOWN 的判断，并且通过SENTINEL is-master-down-by-addr 命令互相交流之后，得出的Master Server下线判断，这种方式就是“客观宕机”，英文名称是： Objectively Down， 简称 ODOWN。通过一定的 vote 算法，从剩下的 slave 从服务器节点中，选一台提升为 Master 服务器节点，然后自动修改相关配置，并开启故障转移（failover）。Sentinel 机制可以解决 master 和 slave 角色的切换问题。
安装
修改配置文件
启动服务
192.168.177.139
192.168.177.140
其他地方配置和主服务器一致
启动服务
查看主从状态
MASTER
SLAVE1
SLAVE2
MASTER
SLAVE1
SLAVE2
主服务器
SLAVE1：升级为主服务器
SLAVE2：主服务器变为node10
主服务器
从服务器
㈩ redis sentinel(哨兵)模式
本文使用docker启动的sentinel，启动脚本如下
发现最后的sentinels=3，说明有3个哨兵服务正在监控
报错、此时sentinel可以获取到主节点信息，但是获取的ip为docker内部配置的地址
配置完毕