{"msg":"操作成功","code":200,"data":{"createBy":"admin","createTime":"2020-10-19 12:41:16","updateBy":"admin","updateTime":"2025-08-23 15:31:44","remark":null,"id":38,"articleTitle":"Redis（五）之哨兵","articleUrl":"redis_sentinel","articleThumbnail":"https://www.asumimoe.com/imgfiles/20220908/828bf19b43f2452d8540393410257d30.png","articleFlag":"1","draftStatus":"1","reprintStatement":"0","articleSummary":"Redis Sentinel，即Redis哨兵，在Redis 2.8版本开始引入。哨兵的核心功能是主节点的自动故障转移。","articleContent":"## 一、作用和架构\n\n### 1.作用\n\n在介绍哨兵之前，首先从宏观角度回顾一下Redis实现高可用相关的技术。它们包括：持久化、复制、哨兵和集群，其主要作用和解决的问题是：\n\n- 持久化：持久化是最简单的高可用方法(有时甚至不被归为高可用的手段)，主要作用是数据备份，即将数据存储在硬盘，保证数据不会因进程退出而丢失。\n- 复制：复制是高可用Redis的基础，哨兵和集群都是在复制基础上实现高可用的。复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复。缺陷：故障恢复无法自动化；写操作无法负载均衡；存储能力受到单机的限制。\n- 哨兵：在复制的基础上，哨兵实现了自动化的故障恢复。缺陷：写操作无法负载均衡；存储能力受到单机的限制。\n- 集群：通过集群，Redis解决了写操作无法负载均衡，以及存储能力受到单机限制的问题，实现了较为完善的高可用方案。\n\nRedis Sentinel，即Redis哨兵，在Redis 2.8版本开始引入。**哨兵的核心功能是主节点的自动故障转移。**下面是Redis官方文档对于哨兵功能的描述：\n\n- 监控（Monitoring）：哨兵会不断地检查主节点和从节点是否运作正常。\n- 自动故障转移（Automatic failover）：当主节点不能正常工作时，哨兵会开始自动故障转移操作，它会将失效主节点的其中一个从节点升级为新的主节点，并让其他从节点改为复制新的主节点。\n- 配置提供者（Configuration provider）：客户端在初始化时，通过连接哨兵来获得当前Redis服务的主节点地址。\n- 通知（Notification）：哨兵可以将故障转移的结果发送给客户端。\n\n其中，监控和自动故障转移功能，使得哨兵可以及时发现主节点故障并完成转移；而配置提供者和通知功能，则需要在与客户端的交互中才能体现。\n\n这里对“客户端”一词在文章中的用法做一个说明：在前面的文章中，只要通过API访问redis服务器，都会称作客户端，包括redis-cli、Java客户端Jedis等；为了便于区分说明，本文中的客户端并不包括redis-cli，而是比redis-cli更加复杂：redis-cli使用的是redis提供的底层接口，而客户端则对这些接口、功能进行了封装，以便充分利用哨兵的配置提供者和通知功能。\n\n### 2.架构\n\n![img](https://www.asumimoe.com/imgfiles/20221107/54e1d5b6d6ff4185b9a9d0de85d7905d.png)\n\n它由两部分组成，哨兵节点和数据节点：\n\n- 哨兵节点：哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的redis节点，不存储数据。\n- 数据节点：主节点和从节点都是数据节点。\n\n## 二、部署\n\n我们将部署一个简单的哨兵系统，包含1个主节点、2个从节点和3个哨兵节点。方便起见：所有的节点都部署在一台机器上，使用端口号进行区分。\n\n### 1.部署主从节点\n\n哨兵系统中的主从节点与普通的主从节点配置是一样的，下面是主节点与2个从节点的配置文件。\n\n```shell\n#redis-6379.conf\nport 6379\ndaemonize yes\nlogfile \"6379.log\"\ndbfilename \"dump-6379.rdb\"\nrequirepass 123456\n \n#redis-6380.conf\nport 6380\ndaemonize yes\nlogfile \"6380.log\"\ndbfilename \"dump-6380.rdb\"\nslaveof 127.0.0.1 6379\nrequirepass 123456\nmasterauth 123456\n \n#redis-6381.conf\nport 6381\ndaemonize yes\nlogfile \"6381.log\"\ndbfilename \"dump-6381.rdb\"\nslaveof 127.0.0.1 6379\nrequirepass 123456\nmasterauth 123456\n```\n\n配置完成后依次启动主节点和从节点，节点启动成功后，连接主节点查看主从状态是否正常：\n\n```shell\nredis-cli -p 6379 info Replication\n# Replication\nrole:master\nconnected_slaves:2\nslave0:ip=127.0.0.1,port=6380,state=online,offset=224,lag=1\nslave1:ip=127.0.0.1,port=6381,state=online,offset=224,lag=1\n```\n\n### 2.部署哨兵节点\n\n3个哨兵节点的配置几乎相同，区别为端口号（哨兵节点实际为特殊的redis节点）。\n\n```shell\n#sentinel-26379.conf\nport 26379\ndaemonize yes\nlogfile \"26379.log\"\nsentinel monitor mymaster 127.0.0.1 6379 2 #该哨兵节点监控127.0.0.1:6379这个主节点，该主节点的名称是mymaster，2的含义与主节点的故障判定有关：至少2个哨兵节点同意，才能判定主节点故障并进行故障转移。\n```\n\n哨兵节点有两种启动方式，其作用是完全相同的：\n\n```bash\nredis-sentinel sentinel-26379.conf\nredis-server sentinel-26379.conf --sentinel\n```\n\n按照上述方式配置和启动之后，整个哨兵系统就启动完毕了。可以通过redis-cli连接哨兵节点进行验证，如下图所示：可以看出26379哨兵节点已经在监控mymaster主节点(即192.168.92.128:6379)，并发现了其2个从节点和另外2个哨兵节点。\n\n```bash\nredis-cli -p 26379 info Sentinel\n# Sentinel\nsentinel_masters:1\nsentinel_tilt:0\nsentinel_running_scripts:0\nsentinel_scripts_queue_length:0\nsentinel_simulate_failure_flags:0\nmaster0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3\n```\n\n此时，查看哨兵节点的配置文件会有一些变化：\n\n```shell\ncat sentinel-26379.conf \nport 26379\nbind 127.0.0.1\ndaemonize yes\nlogfile \"26379.log\"\nsentinel myid c5dcc8ce2023ff527a99844b29ae56322505b284\n# Generated by CONFIG REWRITE\ndir \"/opt/redisms\"\nprotected-mode no\nsentinel deny-scripts-reconfig yes\nsentinel monitor mymaster 127.0.0.1 6379 2\nsentinel config-epoch mymaster 0\nsentinel leader-epoch mymaster 0\nsentinel known-replica mymaster 127.0.0.1 6381\nsentinel known-replica mymaster 127.0.0.1 6380\nsentinel known-sentinel mymaster 127.0.0.1 26381 68a02901ffede9408cc8d8121dbca531f4f9cbed\nsentinel known-sentinel mymaster 127.0.0.1 26380 c3b31437e272d4e81f5ae677de23d88f1de494bb\nsentinel current-epoch 0\n```\n\n其中，dir只是显式声明了数据和日志所在的目录（在哨兵模式下只有日志）；known-slave和known-sentinel显示哨兵已经发现了从节点和其他哨兵；带有epoch的参数与配置纪元有关（配置纪元是一个从0开始的计数器，每进行一次领导者哨兵选举，都会+1）。\n\n### 3.演示故障转移\n\n（1）使用kill命令杀掉主节点。\n\n（2）主节点宕机后并不会立即进行切换，因为哨兵发现主节点故障并进行转移需要一段时间。一段时间后，在哨兵节点中执行命令查看主节点已经切换为了6380节点。\n\n```bash\nredis-cli -p 26379 info Sentinel\n# Sentinel\nsentinel_masters:1\nsentinel_tilt:0\nsentinel_running_scripts:0\nsentinel_scripts_queue_length:0\nsentinel_simulate_failure_flags:0\nmaster0:name=mymaster,status=ok,address=127.0.0.1:6380,slaves=2,sentinels=3\n```\n\n但是同时可以发现，哨兵节点认为新的主节点仍然有2个从节点，这是因为哨兵在将6380切换成主节点的同时，将6379节点置为其从节点；虽然6379从节点已经挂掉，但是由于哨兵并不会对从节点进行客观下线（其含义将在原理部分介绍），因此认为该从节点一直存在。当6379节点重新启动后，会自动变成6380节点的从节点。\n\n（3）重启6379节点，可以看到6379节点成为了6380的从节点。\n\n```bash\nredis-cli -p 6380 info Replication     \n# Replication\nrole:master\nconnected_slaves:2\nslave0:ip=127.0.0.1,port=6381,state=online,offset=165598,lag=0\nslave1:ip=127.0.0.1,port=6379,state=online,offset=165598,lag=0\n```\n\n（4）在故障转移阶段，哨兵和主从节点的配置文件都会被改写。\n\n对于主从节点，主要是slaveof配置的变化：新的主节点没有了slaveof的配置，其他从节点都slaveof新的主节点。\n\n```shell\ncat redis-6379.conf \nport 6379\nbind 127.0.0.1\ndatabases 16\nsave 900 1\nlogfile \"log-6379.log\"\ndbfilename \"dump-6379.rdb\"\ndaemonize yes\n# Generated by CONFIG REWRITE\ndir \"/opt/redisms\"\nreplicaof 127.0.0.1 6380 #根据redis的版本不同会有replicaof/slaveof的区别\n```\n\n对于哨兵节点，除了主从节点的信息变化，纪元（epoch）也会变化，下面可以看到纪元相关的参数都+1了\n\n```shell\ncat sentinel-26379.conf \nport 26379\nbind 127.0.0.1\ndaemonize yes\nlogfile \"26379.log\"\nsentinel myid c5dcc8ce2023ff527a99844b29ae56322505b284\n# Generated by CONFIG REWRITE\ndir \"/opt/redisms\"\nprotected-mode no\nsentinel deny-scripts-reconfig yes\nsentinel monitor mymaster 127.0.0.1 6380 2\nsentinel config-epoch mymaster 1\nsentinel leader-epoch mymaster 1\nsentinel known-replica mymaster 127.0.0.1 6379\nsentinel known-replica mymaster 127.0.0.1 6381\nsentinel known-sentinel mymaster 127.0.0.1 26381 68a02901ffede9408cc8d8121dbca531f4f9cbed\nsentinel known-sentinel mymaster 127.0.0.1 26380 c3b31437e272d4e81f5ae677de23d88f1de494bb\nsentinel current-epoch 1\n```\n\n## 三、基本原理\n\n### 1.哨兵节点支持的命令\n\n哨兵节点作为运行在特殊模式下的redis节点，其支持的命令与普通的redis节点不同。在运维中，我们可以通过这些命令查询或修改哨兵系统；不过更重要的是，哨兵系统要实现故障发现、故障转移等各种功能，离不开哨兵节点之间的通信，而通信的很大一部分是通过哨兵节点支持的命令来实现的。下面介绍哨兵节点支持的主要命令。\n\n（1）基础查询：通过这些命令，可以查询哨兵系统的拓扑结构、节点信息、配置信息等。\n\n- info sentinel：获取监控的所有主节点的基本信息\n- sentinel masters：获取监控的所有主节点的详细信息\n- sentinel master mymaster：获取监控的主节点mymaster的详细信息\n- sentinel slaves mymaster：获取监控的主节点mymaster的从节点的详细信息\n- sentinel sentinels mymaster：获取监控的主节点mymaster的哨兵节点的详细信息\n- sentinel get-master-addr-by-name mymaster：获取监控的主节点mymaster的地址信息，前文已有介绍\n- sentinel is-master-down-by-addr：哨兵节点之间可以通过该命令询问主节点是否下线，从而对是否客观下线做出判断\n\n（2）增加/移除对主节点的监控\n\nsentinel monitor mymaster2 192.168.92.128 16379 2：与部署哨兵节点时配置文件中的sentinel monitor功能完全一样，不再详述\n\nsentinel remove mymaster2：取消当前哨兵节点对主节点mymaster2的监控\n\n（3）强制故障转移\n\nsentinel failover mymaster：该命令可以**强制对mymaster执行故障转移**，即便当前的主节点运行完好；例如，如果当前主节点所在机器即将报废，便可以提前通过failover命令进行故障转移。\n\n### 2.基本原理\n\n关于哨兵的原理，关键是了解以下几个概念。\n\n（1）定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：通过向主从节点发送info命令获取最新的主从结构；通过发布订阅功能获取其他哨兵节点的信息；通过向其他节点发送ping命令进行心跳检测，判断是否下线。\n\n（2）主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。\n\n（3）客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。\n\n**需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。**\n\n（4）选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。\n\n监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。\n\n（5）故障转移：选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：\n\n- 在从节点中选择新的主节点：选择的原则是，首先过滤掉不健康的从节点；然后选择优先级最高的从节点(由slave-priority指定)；如果优先级无法区分，则选择复制偏移量最大的从节点；如果仍无法区分，则选择runid最小的从节点。\n- 更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。\n- 将已经下线的主节点(即6379)设置为新的主节点的从节点，当6379重新上线后，它会成为新的主节点的从节点。\n\n### 3.核心关键字（按切换顺序）：\n\n（1）**`+sdown`**\n\n- **主观下线**（Subjectively Down）：某个Sentinel认为主节点不可用（但未达成集群共识）。\n\n（2）**`+odown`**\n\n- **客观下线**（Objectively Down）：多个Sentinel达成共识，确认主节点真正失效（满足`quorum`配置）。\n\n（3）**`+try-failover`**\n\n- 开始尝试故障切换，Sentinel领导者选举启动。\n\n（4）**`+vote-for-leader`**\n\n- Sentinel节点投票选举领导者（负责执行故障切换的Sentinel）。\n\n（5）**`+elected-leader`**\n\n- 成功选举出Sentinel领导者，将执行后续切换操作。\n\n（6）**`+selected-slave`**\n\n- 选定一个从节点（Slave）作为新主节点的候选者。\n\n（7）**`+failover-state-send-slaveof-noone`**\n\n- 向候选从节点发送 `slaveof no one` 命令，将其提升为新主节点。\n\n（8）**`+slave-reconf-sent`**\n\n- 向其他从节点发送命令，让它们复制**新主节点**（`SLAVEOF` 新主节点地址）。\n\n（9）**`+slave-reconf-inprog`**\n\n- 从节点正在重新配置（同步新主节点数据）。\n\n（10）**`+slave-reconf-done`**\n\n- 从节点完成重新配置，已正常复制新主节点。\n\n（11）**`+switch-master`**\n\n- **最关键的日志**！标志主节点正式切换完成。格式：\n\n  ```bash\n  +switch-master <master-name> <old-ip> <old-port> <new-ip> <new-port>\n  ```\n\n  示例：\n  `+switch-master mymaster 192.168.1.10 6379 192.168.1.11 6380`\n\n```shell\n# cat 26379.log \n29841:X 19 Oct 2020 15:04:02.757 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo\n29841:X 19 Oct 2020 15:04:02.757 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=29841, just started\n29841:X 19 Oct 2020 15:04:02.757 # Configuration loaded\n29842:X 19 Oct 2020 15:04:02.813 * Increased maximum number of open files to 10032 (it was originally set to 1024).\n29842:X 19 Oct 2020 15:04:02.813 * Running mode=sentinel, port=26379.\n29842:X 19 Oct 2020 15:04:02.813 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.\n29842:X 19 Oct 2020 15:04:02.815 # Sentinel ID is c5dcc8ce2023ff527a99844b29ae56322505b284\n#哨兵节点启动，监控主节点，并发现了从节点和其他哨兵节点\n29842:X 19 Oct 2020 15:04:02.815 # +monitor master mymaster 127.0.0.1 6379 quorum 2\n29842:X 19 Oct 2020 15:04:02.815 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:04:02.816 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:04:08.805 * +sentinel sentinel c3b31437e272d4e81f5ae677de23d88f1de494bb 127.0.0.1 26380 @ mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:04:11.834 * +sentinel sentinel 68a02901ffede9408cc8d8121dbca531f4f9cbed 127.0.0.1 26381 @ mymaster 127.0.0.1 6379\n# 主节点主观下线\n29842:X 19 Oct 2020 15:16:00.550 # +sdown master mymaster 127.0.0.1 6379\n# 主节点客观下线\n29842:X 19 Oct 2020 15:16:00.634 # +odown master mymaster 127.0.0.1 6379 #quorum 2/2\n#进入新的纪元1，并在领导者选举过程中被选为领导者\n29842:X 19 Oct 2020 15:16:00.634 # +new-epoch 1\n# 开始故障切换\n29842:X 19 Oct 2020 15:16:00.634 # +try-failover master mymaster 127.0.0.1 6379\n# 选举Sentinel领导者\n29842:X 19 Oct 2020 15:16:00.635 # +vote-for-leader c5dcc8ce2023ff527a99844b29ae56322505b284 1\n29842:X 19 Oct 2020 15:16:00.637 # c3b31437e272d4e81f5ae677de23d88f1de494bb voted for c5dcc8ce2023ff527a99844b29ae56322505b284 1\n29842:X 19 Oct 2020 15:16:00.637 # 68a02901ffede9408cc8d8121dbca531f4f9cbed voted for c5dcc8ce2023ff527a99844b29ae56322505b284 1\n29842:X 19 Oct 2020 15:16:00.693 # +elected-leader master mymaster 127.0.0.1 6379\n#完成故障转移\n29842:X 19 Oct 2020 15:16:00.693 # +failover-state-select-slave master mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:16:00.760 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:16:00.760 * +failover-state-send-slaveof-noone slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:16:00.819 * +failover-state-wait-promotion slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:16:01.496 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:16:01.496 # +failover-state-reconf-slaves master mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:16:01.565 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:16:01.759 # -odown master mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:16:02.554 * +slave-reconf-inprog slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:16:02.554 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6379\n29842:X 19 Oct 2020 15:16:02.644 # +failover-end master mymaster 127.0.0.1 6379\n# 主节点切换完成\n29842:X 19 Oct 2020 15:16:02.644 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 6380\n29842:X 19 Oct 2020 15:16:02.644 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ mymaster 127.0.0.1 6380\n29842:X 19 Oct 2020 15:16:02.644 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380\n29842:X 19 Oct 2020 15:16:32.715 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380\n#6379节点重启后，成为从节点\n29842:X 19 Oct 2020 15:18:15.377 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6380\n```\n\n## 四、配置与建议\n\n### 1.配置\n\n下面介绍与哨兵相关的几个配置。\n\n（1） sentinel monitor {masterName} {masterIp} {masterPort} {quorum}\n\nsentinel  monitor是哨兵最核心的配置，在前文讲述部署哨兵节点时已说明，其中：masterName指定了主节点名称，masterIp和masterPort指定了主节点地址，quorum是判断主节点客观下线的哨兵数量阈值：当判定主节点下线的哨兵数量达到quorum时，对主节点进行客观下线。建议取值为哨兵数量的一半加1。\n\n（2） sentinel down-after-milliseconds {masterName} {time}\n\nsentinel  down-after-milliseconds与主观下线的判断有关：哨兵使用ping命令对其他节点进行心跳检测，如果其他节点超过down-after-milliseconds配置的时间没有回复，哨兵就会将其进行主观下线。该配置对主节点、从节点和哨兵节点的主观下线判定都有效。\n\ndown-after-milliseconds的默认值是30000，即30s；可以根据不同的网络环境和应用要求来调整：值越大，对主观下线的判定会越宽松，好处是误判的可能性小，坏处是故障发现和故障转移的时间变长，客户端等待的时间也会变长。例如，如果应用对可用性要求较高，则可以将值适当调小，当故障发生时尽快完成转移；如果网络环境相对较差，可以适当提高该阈值，避免频繁误判。\n\n（3） sentinel parallel-syncs {masterName} {number}\n\nsentinel  parallel-syncs与故障转移之后从节点的复制有关：它规定了每次向新的主节点发起复制操作的从节点个数。例如，假设主节点切换完成之后，有3个从节点要向新的主节点发起复制；如果parallel-syncs=1，则从节点会一个一个开始复制；如果parallel-syncs=3，则3个从节点会一起开始复制。\n\nparallel-syncs取值越大，从节点完成复制的时间越快，但是对主节点的网络负载、硬盘负载造成的压力也越大；应根据实际情况设置。例如，如果主节点的负载较低，而从节点对服务可用的要求较高，可以适量增加parallel-syncs取值。parallel-syncs的默认值是1。\n\n（4） sentinel failover-timeout {masterName} {time}\n\nsentinel  failover-timeout与故障转移超时的判断有关，但是该参数不是用来判断整个故障转移阶段的超时，而是其几个子阶段的超时，例如如果主节点晋升从节点时间超过timeout，或从节点向新的主节点发起复制操作的时间(不包括复制数据的时间)超过timeout，都会导致故障转移超时失败。\n\nfailover-timeout的默认值是180000，即180s；如果超时，则下一次该值会变为原来的2倍。\n\n（5）除上述几个参数外，还有一些其他参数，如安全验证相关的参数，这里不做介绍。\n\n### 2.实践建议\n\n（1）哨兵节点的数量应不止一个，一方面增加哨兵节点的冗余，避免哨兵本身成为高可用的瓶颈；另一方面减少对下线的误判。此外，这些不同的哨兵节点应部署在不同的物理机上。\n\n（2）哨兵节点的数量应该是奇数，便于哨兵通过投票做出“决策”：领导者选举的决策、客观下线的决策等。\n\n（3）各个哨兵节点的配置应一致，包括硬件、参数等；此外，所有节点都应该使用ntp或类似服务，保证时间准确、一致。\n\n（4）哨兵的配置提供者和通知客户端功能，需要客户端的支持才能实现，如前文所说的Jedis；如果开发者使用的库未提供相应支持，则可能需要开发者自己实现。\n\n（5）当哨兵系统中的节点在docker（或其他可能进行端口映射的软件）中部署时，应特别注意端口映射可能会导致哨兵系统无法正常工作，因为哨兵的工作基于与其他节点的通信，而docker的端口映射可能导致哨兵无法连接到其他节点。例如，哨兵之间互相发现，依赖于它们对外宣称的IP和port，如果某个哨兵A部署在做了端口映射的docker中，那么其他哨兵使用A宣称的port无法连接到A。\n\n转载自：[https://www.cnblogs.com/kismetv/p/9609938.html](https://www.cnblogs.com/kismetv/p/9609938.html)\n\n","categoryId":2,"viewCount":1090,"categoryName":"中间件","author":"球接子","authorAvatar":null,"tagIds":[1,14,17],"tagNames":["Redis","中间件","数据库"]}}