Redis Sentinel

Redis Sentinel为Redis提供了高可用性。 实际上，这意味着使用Sentinel可以创建一个Redis部署，在没有人为干预的情况下抵抗某些类型的故障。

Redis Sentinel还为客户提供其他附属任务，如监视、通知和充当配置提供者。

这是宏观级别的标记功能的完整列表 :

• Monitoring. Sentinel会不断检查master和slave实例是否按预期工作。
• Notification. Sentinel可以通过API通知系统管理员(另一个计算机程序)，所监视的一个Redis实例出了问题。
• Automatic failover. 如果主服务器没有按照预期工作，Sentinel可以启动故障转移进程，其中从服务器升级为主服务器，其他附加的从服务器将重新配置为使用新主服务器，使用Redis服务器的应用程序将在连接时得到要使用的新地址的通知。
• Configuration provider. Sentinel充当客户端服务发现的授权源:客户端连接到sentinels，以请求当前负责给定服务的redis的master地址。 如果发生故障转移， Sentinels将报告新地址。

Sentinel的分布性质

Redis Sentinel是一个分布式系统: Sentinel本身的设计是在一个配置中运行，可以有多个Sentinel进程协同工作。

多个 Sentinel进程协作的优势如下：

1. 当多个 Sentinels一致认为某个master不再可用时，就会执行故障检测。 这降低了误报的概率。
2. 即使不是所有的Sentinel进程都在工作，Sentinel也能工作，这使得系统对故障具有健壮性。 毕竟，拥有一个本身就是单点故障的故障转移系统是没有多大意义的。

Sentinels 、Redis实例(主实例和从实例)以及连接到Sentinel和Redis的客户端的总和也是一个更大的分布式系统，具有特定的属性。

Sentinel概述

当前版本的Sentinel称为Sentinel 2。 它是对最初的Sentinel实现的重写，使用更强大和更简单的算法进行预测。

自Redis 2.8以来，发布了一个稳定的Redis Sentinel版本。

新的开发会在不稳定的分支中执行，并且新特性有时会在被认为是稳定的时候被重新移植到最新的稳定分支中。

Redis Sentinel版本1(随Redis 2.6一起发布)是不推荐的，不应该使用。

运行Sentinel

如果正在使用redis-sentinel可执行文件 ，执行如下命令：

redis-sentinel /path/to/sentinel.conf

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

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

两种方法的效果是一样的。

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

Sentinels默认情况下运行监听到TCP端口26379的连接，因此要让 Sentinels正常工作，服务器的端口26379必须打开以接收来自其他 Sentinel实例的IP地址的连接。 否则Sentinels就不能通信，也不能就该做什么达成一致，因此永远不会执行故障转移。

部署Sentinel之前需要了解的基本知识

1. 要进行健壮的部署，至少需要三个Sentinel实例。
2. 这三个Sentinel实例应该被放置到计算机或虚拟机中，这些计算机或虚拟机被认为以独立的方式失败。 例如，在不同的可用性区域上执行不同的物理服务器或虚拟机。
3. 由于Redis使用异步复制，Sentinel + Redis分布式系统不能保证在故障期间已确认的写会被保留。 然而，有一些部署Sentinel的方法可以使窗口的写操作丢失限制在某些时刻，也有其它不太安全的方式来部署它。
4. 需要你的客户端支持Sentinel。 流行的客户端库有支持Sentinel，但不是全部。
5. 如果不经常在开发环境中进行测试，就没有HA设置是安全的;如果可以的话在生产环境中进行测试，那就更好了。
6. 应该谨慎地混合Sentinel、Docker或其他形式的网络地址转换或端口映射: Docker执行端口重映射，中断Sentinel自动发现其他Sentinel进程和 master 的slaves列表。

配置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 1

sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

 你只需要指定要监视的masters，为每个分开的master(可能有任意数量的slaves)提供一个不同的名称。 没有必要指定slaves,slaves会被自动发现。 Sentinel将自动更新配置，并提供关于slaves的附加信息。 在故障转移过程中，每当从服务器升级为主服务器时，以及每次发现新的Sentinel时，都要重写配置。

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

sentinel monitor语句的参数的含义如下:

sentinel monitor <master-group-name> <ip> <port> <quorum>

为了清楚起见，让我们逐行检查配置选项的含义:

第一行用于告诉Redis监视一个名为mymaster的master，该master地址为127.0.0.1和端口6379，仲裁为2。除了quorum参数, 一切都很明显：

1. quorum是Sentinels的数量，这些Sentinels需要就无法访问主节点的事实达成一致，以便真正将从节点标记为失败，并最终在可能的情况下启动故障转移过程。
2. 然而，仲裁仅用于检测故障。 为了实际执行故障转移，其中一个Sentinel需要被选为故障转移的领导者，并被授权继续执行。

例如，如果你有5个Sentinel进程，并且指定 master的quorum值为2，就会发生如下的情况:

• 如果两个Sentinels同时同意master无法到达，其中一个将尝试启动故障转移。
• 如果至少有三个 Sentinels可用，则故障转移会被授权并实际启动。

在实际应用中，这意味着在故障期间，如果大多数 Sentinel进程无法通信，那么 Sentinel将永远不会启动故障转移

其他Sentinel选项

其他选项的形式几乎都是如下所示：

sentinel <option_name> <master_name> <option_value>

用于以下目的:

• down-after-milliseconds 是以毫秒为单位的实例不可到达的时间(要么不响应ping，要么响应错误)，这是一个Sentinel开始认为它已经关闭的时间。
• parallel-syncs 设置slaves数量，这些slaves在故障转移后可以在相同时间里被重新配置为使用新的master。 数字越低，故障转移完成所需的时间就越多， 但是，如果从服务器被配置为提供旧数据，则可能不会希望所有从服务器同时与主服务器重新同步。 虽然复制过程对slave来说基本上是非阻塞的，但有时它会停止从master加载大量数据。  你能希望将此选项设置为1，以确保一次只能访问一个slave。

所有配置参数都可以在运行时使用SENTINEL SET命令进行修改。

 

 

 

 

 

转载于:https://my.oschina.net/jennerlo/blog/3073056