Redis Sentinel 文档说明

RedisSentinel文档说明RedisSentinel的设计目标是用来协助管理Redis实例的系统，它通常执行下面的4类任务：监控，Sentinel会持续的检测master和slave的实例是否像期望的方式工作。通知，Sentinel可以通过一个API，通知系统管理员，或计算机上的其他程序，它监控的redis实例中那些事情出错了。自动的错误恢复，如果一个master不能像期望的那样正常工作，Sentinel可以启动一个错误恢复的处理过程，将一个slave升级成为master，并使其他的slave成为新的master的slave，应用使用Redisserver获取新master位置的通知。配置信息的获取，Sentinel会作为面向客户端的服务的一个发现的源头：客户端会通过与Sentinels连接，来获取当前工作的Redismaster的位置。如果经历了错误恢复，Sentinels将会报告新的master的地址。Sentinel的分布式本质（DistributednatureofSentinel）RedisSentinel是一个可分布的系统，这意味着通常你会在你的基础规划中选择运行多个Sentinel进程，而这些进程会使用gossipprotocols来理解一个master是否下线，并使用agreementprotocols来获取执行错误恢复的授权，或赋予一个新配置新的版本。分布式系统具有安全（safety）和活动（liveness）的特性，如果想能使用好RedisSentinel，你应该理解Sentinel是如果作为一个分布式系统工作的。这些使Sentinel与单进程的程序相比，会更复杂并更具有优势，如：一个Sentinels的群集，即便其中一部分Sentinels失效，仍然可以完成一个master的故障恢复。如果一个Sentinel工作不正常，或连接不上，不会得到其它的Sentinels的授权，也就不可能做故障恢复的工作。客户端可以连接任意的Sentinel来获取master的配置信息。获取Sentinel（ObtainingSentinel）Sentinel当前是Redissourcecode的Github上的一个unstable的分支，不过自Redis2.8开始，会作为不定进入到Redis的发行版本。使用Sentinel最简单的方式是下载Redis2.8之后的最新版本，或编译Github上的最新的unstable的分支。注意：即便你是在使用Redis2.6，你也应该使用Redis2.8中的Sentinel。运行Sentinel（RunningSentinel）如果你使用的redis-sentinel可执行程序（或者是一个到redis-server可执行程序的符号链接)，你可以使用下面的命令运行Sentinel：redis-sentinel/path/to/sentinel.conf另外，你可以直接使用redis-server可执行程序使用Sentinel模式来启动：redis-server/path/to/sentinel.conf--sentinel这两种方式没什么区别。此外，运行Sentinel被强制要求使用配置文件，因为这个文件会被Sentinel用来保存它的当前状态，以便可以在Sentinel重新启动的情况下可以恢复Sentinel的状态。如果没有配置文件，或配置文件不能写入，Sentinel会拒绝启动。Sentinel默认监听在26379的TCP端口，所以你的服务器必须开放26379端口，这样Sentinel才能接收来自其他IP的Sentinel的实例的连接。否则Sentinels将无法会话，也无法赞同应该做的事情，当然也无法执行错误恢复。Sentinel的配置（ConfiguringSentinel）在Redis的发布的源代码中，包含一个sentinel.conf的文件，是一个自描述的Sentinel的配置文件的例子。一般，一个典型的最小化的配置看起来应该是下面这样子：sentinelmonitormymaster127.0.0.163792sentineldown-after-millisecondsmymaster60000sentinelfailover-timeoutmymaster180000sentinelparallel-syncsmymaster1sentinelmonitorresque192.168.1.363804sentineldown-after-millisecondsresque10000sentinelfailover-timeoutresque180000sentinelparallel-syncsresque5第一行用于告知监控的Redis的master，被命名为mymaster，位于IP127.0.0.1，端口6379，并且启动故障恢复的sentinels的同意的数量（agreement）是2（如果同意的数量没有达到，不会启动故障恢复的过程）。然而，无论Sentinel需要达成什么一致，Sentinel都要求所有群集中的知道的Sentinels的主体的投票，来开始一个故障恢复和获取一个新生代的配置用来描述故障恢复后的配置状态。在这个例子中，法定人数（quorum）被设置为2，因此需要两个sentinels赞同master已经无法联络，或处于一种可以触发故障恢复的错误状态（然而像下一个小节将看到的，触发故障恢复仅仅启动还是不够的，还需要授权）。其他的配置项基本是下面的形式：sentineloption_namemaster_nameoption_value他们被用于下面的场景：down-after-milliseconds是以毫秒计时的时间长度，当一个redis的实例不能联系上（或者是没有应答PINGs命令，或者是它返回了一个错误）的时候，Sentinel开始认为它已经down了。如果这持续了这个指定的时间，当前的Sentinel会标记这个redis的实例为SDOWN（subjectivelydown），这还不足以启动一个自动的故障恢复。然而，如果足够的Sentinel实例认为这个redis实例为SDOWN，这个redis实例会被标记为ODOWN（objectivelydown）。需要赞同的Sentinel实例数量依赖于这个master的配置的同意的数量（agreement）的配置。parallel-syncs设置经过故障恢复之后，可以同时被配置为新master的slaves的数量。这个数量配置的越小，执行故障恢复所需的时间就越长，然而如果slaves还用于提供数据服务，你可能不希望所有的slaves在同一时间都在和master同步。这样，当复制处理的过程中，一个slave大多会处于非阻塞的状态。你可以通过设置这个值为1，来确保一个时间之内，只有一个slave在同步。其他的选项在Redis的发布的源代码中的sentinel.conf文件中描述。所有的配置参数可以在运行期通过SENTINELSET命令来修改。看在运行期配置Sentinel（ReconfiguringSentinelatruntime）小节获取更多信息。法定人数（Quorum）前面的小节说明：每个被关联的Sentinel监控的master，会涉及到一个配置的法定人数（quorum）。它指定了判断一个maser无法联系或处于需要触发故障恢复的错误状态的所需的赞同的Sentinel的数量。然而，如果故障恢复的条件达到，如果确实需要执行故障恢复，至少还需要Sentinels的主体的授权。让我们把事情弄更清楚一些：法定人数（quorum）:是检测到一个master并标记为SDOWN的Sentinel实例的数量，目标是将一个master标记为ODOWN。故障恢复由ODOWN状态触发。一旦故障恢复被触发，这个试图执行故障恢复的Sentinel实例被强制获取Sentinels主体的授权（如果quorum被这种成大于主体的数字，会被要求多于主体的授权）译者注：主体理解成大多数吧，也就是多于一半就好。这种差别也许看起来很微妙，但是使用和理解上却是很简单。例如，如果你有5个Sentinel实例，并设置quorum为2，那么故障恢复在2个Sentinels认为masterdown的时候就会启动，然而需要至少3个Sentinels授权才会真正的开始故障恢复。如果把quorum配置成5，那么就需要所有的Sentinels认同masterdown的时候，故障恢复才会启动，并且需要所有的Sentinels授权，故障恢复才会执行。配置的代（Configurationepochs）Sentinels要求获取主体的授权来启动故障恢复是因为一些重要的原因：当一个Sentinel做出了授权，他就会获取到这个master故障恢复的唯一的配置的代（configurationepoch）。这是一个在故障恢复之后用来标记新配置的版本的数字。因为主体同意分配版本给一个Sentinel，没有其他的Sentinel可以使用它。这意味着每一个故障恢复的每次配置都会有一个唯一的版本号。我们将会看到为什么这个如此重要。此外Sentinels有一个规则：如果如果一个Sentinel给另外一个Sentinel的master的故障恢复投票，它会等待这个master的故障恢复一段的时间。这个时间就是在sentinel.conf中配置的failover-timeout。这表示在这个期间Sentinels不会再对相同的master再做故障恢复，然后尝试第一次的授权请求，如果失败再试，等等。RedisSentinel的存活的保证，来自Sentinels的主体的可交互性，最终体现在master的故障恢复的授权上。RedisSentinel的安全的保证，来自每个Sentinel做同一个master的故障恢复，会使用一个不同的、唯一的配置的代。配置的传播（Configurationpropagation）一旦一个Sentinel可以成功的对一个master做故障恢复，它会开始对广播这个新的配置，这样其它的Sentinels会根据广播的配置更新自己的信息。因为故障恢复被认为是成功的，它要求Sentinel可以发送SLAVEOFNOONE命令给选择的slave，并将其切换成为master。这可以通过在master上看INFO的命令的输出就能看到。在设个时间点，即使slaves的配置还在继续，但这个故障恢复的过程已经被看作是成功的，并且所有的Sentinels要求报告新的配置。新的配置的传播方式是为什么每个Sentinel被授权为一个不同版本号的原因（配置代）。每个Sentinel会不断的广播它的master的配置的版本，使用Redis的Pub/Sub命令，在所有的master和master的所有的slaves上。同时，所有的Sentinels也在等待其他的Sentinels广播的消息，来查看其他Sentinels广播的配置信息。配置信息通过__sentinel__:helloPub/Subchannel来广播。因为每个配置都有一个不同的版本号，因此更大的版本号总是会覆盖小的版本。因此，例如，开始的时候所有的Sentinels认为mymaster的配置中，master位于192.168.1.50:6379。这个配置具有版本1。过了一些时间，一个Sentinel获得了授权执行了故障恢复，切换到版本2。如果故障恢复成功，它开始广播新配置，假设是192.168.50:9000，带有版本2。所有其他Sentinel会看到这个配置，并将其更新到他们的配置之中，因为新的配置有更大的版本。这意味着Sentinel提供了另外一个存活性的特性：一个Sentinels的集合可以相互通讯，并聚集到有更高版本、相同的配置下。基本上，如果网络是分离的，每个部分都会聚集到更高的本地配置的版本下；在消除分区的特定情况下，所有Sentinel会成为一个分区，并会统一配置