一、概述

Redis Sentinel 在不使用 Redis 集群时为 Redis 提供高可用性。

Redis Sentinel还提供其他附带任务，例如监控， 通知并充当客户端的配置提供程序。

这是宏观层面（即大局）的哨兵功能的完整列表：

• 监控。Sentinel 会不断检查您的主实例和副本实例是否按预期工作。

• 通知。Sentinel 可以通过 API 通知系统管理员或其他计算机程序，其中一个受监控的 Redis 实例出现问题。

• 自动故障转移。如果主节点未按预期工作，Sentinel 可以启动故障转移过程，其中副本将提升为主副本，将其他其他副本重新配置为使用新的主副本，并且使用 Redis 服务器的应用程序将被告知连接时要使用的新地址。

• 配置提供程序。Sentinel 充当客户端服务发现的权威来源：客户端连接到 Sentinels，以请求负责给定服务的当前 Redis 主服务器的地址。如果发生故障转移，Sentinels将报告新地址。

二、Sentinel作为一个分布式系统

Redis Sentinel是一个分布式系统：

Sentinel 本身设计为在有多个 Sentinel 进程协同的配置中运行。让多个 Sentinel 流程协作的优势如下：

1. 当多个哨兵同意给定主节点不再可用时，将执行故障检测。这降低了误报的可能性。

2. 即使不是所有的 Sentinel 进程都在工作，Sentinel 也能正常工作，使系统能够抵御故障。毕竟，拥有一个本身就是单点故障的故障转移系统没有任何乐趣。

哨兵、Redis 实例（主实例和副本实例）和客户端的总和 连接到Sentinel和Redis，也是一个更大的分布式系统，具有 特定属性。在本文档中，概念将逐步介绍 从基本信息开始，了解基本信息 Sentinel 的属性，到更复杂的信息（可选）在 以了解哨兵究竟是如何工作的。

三、快速入门

1、获取Sentinel

Sentinel的当前版本称为Sentinel 2。这是对 最初的 Sentinel 实现使用更强、更易于预测的方法 算法（在本文档中进行了说明）。

Redis Sentinel 的稳定版本从 Redis 2.8 开始发布。

在不稳定的分支中进行新的开发，并具有新功能 有时一到最新的稳定分支就被回移植到最新的稳定分支中 被认为是稳定的。

2、运行Sentinel

如果您使用的是redis sentinel可执行文件（或者如果您具有指向redis服务器可执行文件的具有该名称的符号链接），则可以使用以下命令行运行sentinel：

redis-sentinel /path/to/sentinel.conf

否则，您可以直接使用redis服务器可执行文件以Sentinel模式启动它：

redis-server /path/to/sentinel.conf --sentinel

但是，在运行 Sentinel 时必须使用配置文件，因为系统将使用该文件来保存重新启动时将重新加载的当前状态。如果没有提供配置文件或配置文件路径不可写，Sentinel 将简单地拒绝启动。

默认情况下，哨兵会侦听与 TCP 端口 26379 的连接，因此 要使 Sentinels 正常工作，服务器的端口 26379 必须打开才能接收 来自其他 Sentinel 实例的 IP 地址的连接。 否则哨兵无法交谈，也无法就该怎么做达成一致，因此故障转移 永远不会执行。

3、部署前需要了解的有关 Sentinel 的基本事项

1. 您至少需要三个 Sentinel 实例才能进行可靠的部署。

2. 应将三个 Sentinel 实例放置在被认为以独立方式发生故障的计算机或虚拟机中。例如，在不同的可用性区域上执行不同的物理服务器或虚拟机。

3. Sentinel + Redis 分布式系统不保证在故障期间保留已确认的写入，因为 Redis 使用异步复制。但是，有一些方法可以部署 Sentinel，使窗口丢失写入仅限于某些时刻，而还有其他不太安全的方法来部署它。

4. 您需要圣天诺为客户提供支持。常用的客户端库具有 Sentinel 支持，但不是全部。

5. 如果您不在开发环境中不时进行测试，则没有安全的 HA 设置，如果可以的话，如果它们可以工作，则甚至更好。您可能有一个配置错误，只有在为时已晚（凌晨 3 点您的主站停止工作时）才会变得明显。

6. Sentinel、Docker 或其他形式的网络地址转换或端口映射应小心混合使用：Docker 执行端口重新映射，破坏 Sentinel 自动发现其他 Sentinel 进程和主进程的副本列表。有关详细信息，请查看本文档后面有关 Sentinel 和 Docker 的部分。

4、配置Sentinel

Redis源发行版包含一个名为sentinel.conf的文件，该文件是一个可用于配置sentinel的自我记录示例配置文件，但典型的最小配置文件如下所示：

sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

您只需要指定要监视的主机，为每个单独的主机（可能有任意数量的副本）指定不同的名称。无需指定自动发现的副本。Sentinel将使用有关副本的附加信息自动更新配置（以便在重新启动时保留信息）。在故障切换期间，每当复制副本升级为主副本时，以及每当发现新的Sentinel时，也会重写配置。

上面的示例配置基本上监视两组Redis实例，每个实例由一个主实例和未定义数量的副本组成。一组实例称为mymaster，另一组称为resque。

sentinel监控器语句参数的含义如下：

sentinel monitor    

第一行是用来告诉Redis监视一个叫mymaster的主控， 即地址 127.0.0.1 和端口 6379，仲裁为 2。万事 很明显，但法定人数参数：

• 仲裁是需要就无法访问主服务器的事实达成一致的哨兵数量，以便真正将主服务器标记为失败，并最终启动故障转移过程（如果可能）。

• 但是，仲裁仅用于检测故障。为了实际执行故障转移，需要选择其中一个哨兵进行故障转移的领导者并被授权继续。这只有在大多数哨兵进程投票的情况下才会发生。

因此，例如，如果您有 5 个 Sentinel 进程，以及给定的仲裁 master 设置为值 2，这就是发生的情况：

• 如果两个哨兵同时同意无法访问主服务器，则其中一个将尝试启动故障转移。

• 如果总共至少有三个哨兵可访问，则故障转移将被授权并实际启动。

实际上，这意味着在故障期间，如果大多数 Sentinel 进程无法通信（即少数分区中没有故障转移），则 Sentinel 永远不会启动故障转移。

六、其他Sentinel选项

其他选项几乎总是以下形式：

sentinel