redis哨兵连接数设置（redis哨兵keepalive）



sentinel是redis高可用的解决方案，sentinel系统（N个sentinel实例，N >= 1，一般为单数）可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。

所谓主观下线，就是单个sentinel认为某个服务下线（有可能是接收不到订阅，之间的网络不通等等原因）。
sentinel会以每秒一次的频率向所有与其建立了命令连接的实例（master，从服务，其他sentinel）发ping命令，通过判断ping回复是有效回复，还是无效回复来判断实例时候在线（对该sentinel来说是“主观在线”）。
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，如果实例在down-after-milliseconds毫秒内，返回的都是无效回复，那么sentinel回认为该实例已（主观）下线，修改其flags状态为SRI_S_DOWN。如果多个sentinel监视一个服务，有可能存在多个sentinel的down-after-milliseconds配置不同，这个在实际生产中要注意。

当sentinel监视的某个服务主观下线后，sentinel会询问其它监视该服务的sentinel，看它们是否也认为该服务主观下线，接收到足够数量（这个值可以配置）的sentinel判断为主观下线，既任务该服务客观下线，并对其做故障转移操作。
sentinel通过发送 SENTINEL is-master-down-by-addr ip port current_epoch runid，（ip：主观下线的服务id，port：主观下线的服务端口，current_epoch：sentinel的纪元，runid：*表示检测服务下线状态，如果是sentinel 运行id，表示用来选举领头sentinel）来询问其它sentinel是否同意服务下线。
一个sentinel接收另一个sentinel发来的is-master-down-by-addr后，提取参数，根据ip和端口，检测该服务时候在该sentinel主观下线，并且回复is-master-down-by-addr，回复包含三个参数：down_state（1表示已下线，0表示未下线），leader_runid（领头sentinal id），leader_epoch（领头sentinel纪元）。
sentinel接收到回复后，根据配置设置的下线最小数量，达到这个值，既认为该服务客观下线

一个redis服务被判断为客观下线时，多个监视该服务的sentinel协商，选举一个领头sentinel，对该redis服务进行古战转移操作。选举领头sentinel遵循以下规则：

所有的sentinel都有公平被选举成领头的资格
所有的sentinel都有且只有一次将某个sentinel选举成领头的机会（在一轮选举中），一旦选举某个sentinel为领头，不能更改
sentinel设置领头sentinel是先到先得，一旦当前sentinel设置了领头sentinel，以后要求设置sentinel为领头请求都会被拒绝
每个发现服务客观下线的sentinel，都会要求其他sentinel将自己设置成领头
当一个sentinel（源sentinel）向另一个sentinel（目sentinel）发送is-master-down-by-addr ip port current_epoch runid命令的时候，runid参数不是*，而是sentinel运行id，就表示源sentinel要求目标sentinel选举其为领头
源sentinel会检查目标sentinel对其要求设置成领头的回复，如果回复的leader_runid和leader_epoch为源sentinel，表示目标sentinel同意将源sentinel设置成领头
如果某个sentinel被半数以上的sentinel设置成领头，那么该sentinel既为领头
如果在限定时间内，没有选举出领头sentinel，暂定一段时间，再选举

故障转移分为三个主要步骤

从下线的主服务的所有从服务里面挑选一个从服务，将其转成主服务
sentinel状态数据结构中保存了主服务的所有从服务信息，领头sentinel按照如下的规则从从服务列表中挑选出新的主服务：
删除列表中处于下线状态的从服务
删除最近5秒没有回复过领头sentinel info信息的从服务
删除与已下线的主服务断开连接时间超过 down-after-milliseconds*10毫秒的从服务，这样就能保留从的数据比较新（没有过早的与主断开连接）
领头sentinel从剩下的从列表中选择优先级高的，如果优先级一样，选择偏移量最大的（偏移量大说明复制的数据比较新），如果偏移量一样，选择运行id最小的从服务
已下线主服务的所有从服务改为复制新的主服务
挑选出新的主服务之后，领头sentinel 向原主服务的从服务发送 slaveof 新主服务 的命令，复制新master
将已下线的主服务设置成新的主服务的从服务，当其回复正常时，复制新的主服务，变成新的主服务的从服务
同理，当已下线的服务重新上线时，sentinel会向其发送slaveof命令，让其成为新主的从
配置步骤推荐先主从复制，后搭建哨兵模式

2.1 下载源码 https://github.com/antirez/redis 下载稳定版redis（使用3.0.7及以上版本）
2.2 解压安装包
2.3 在src下执行 make && make install （用风云诀已经准备好的压缩包 make install即可）
2.4 修改配置文件redis.conf（是否重命名根据个人习惯定）

公共配置

从节点需要在公共配置基础上添加以下配置

2.5 启动

2.6 验证
进入redis客户端

显示类似下图，代表此节点redis启动成功

个人理解：

3.1修改配置文件sentinel.conf（或新建配置文件 根据个人习惯而定），三个哨兵的配置文件一致即可

3.2启动sentinel

解决方法：修改配置文件指向已存在的文件夹或者去该路径下创建新文件夹

4.2 出现死循环报错(未复现)
原因：多半为节点的保护模式开启或者修改后的配置文件不生效（使用redis-server &启动）
解决方法：修改配置文件，使用推荐方式启动

4.3 第一次启动哨兵和所有redis节点，正常，第二次启动从节点找不到主节点，循环报错，但从节点的cli中通过 slaveof 192.168.1.83 6379指令，可以连接到主节点，并 info replication显示正常。

原因：从节点的配置文件被修改，不存在slaveof信息或有误，我遇到的是因为哨兵中 sentinel monitor mymaster xxx.xxx.xxx.xxx 6379 2为设置 解决方法：正确配置配置文件

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/rfx/80158.html