Redis Sentinel环境下的Key过期事件消息订阅

版权声明：本文为ByfordLee原创文章，未经博主允许不得转载，违者请吃饭即可。

一．Redis Sentinel

       Sentinel是Redis 2.8之后官方发布的HA解决方案，通过Sentinel可以保障整个Redis系统的高可用性。当Redis系统中的Master在异常情况下停止服务后，若干Sentinel会及时察觉并主观判断Master down（Subjectively Down），并且随后由一定数量的Sentinel共同确定Master确实客观已down（Objectively Down），这个时候Sentinel们会选举出一个新的Master继续提供服务。Redis Sentinel的这种Failover机制是基于流言协议（Gossip Protocols）实现的（我猜你一定想到了Gossip Girl：）。

       Sentinel的主要功能如下：

• 监控：Sentinel可以持续地检查Master和Slave实例是否工作正常

• 通知：当被监控的Redis实例发生异常时，Sentinel可以通过API接口通知系统管理员或是其他的应用程序

• 自动Failover：如果Master工作发生异常，Sentinel会启动Failover，选定一个Slave升级为Master，其它的Slave会对自己重新配置来使用新的Master，而应用程序也会通过Sentinel自动连接到新的Master

• 配置提供者：对于客户端而言，Sentinel扮演了发现Redis服务的提供者，客户端连接到Sentinel以获得当前Master的地址并进行访问，如果发生了Failover，Sentinel会返回新的Master地址     

    假设我们有三台服务器：192.168.112.81、192.168.112.82、192.168.112.83。首先分别安装好Redis 3.0.7，其中192.168.112.81作为Master，其它两台为Slave。      

​    给三个Redis分别配置Sentinel，在sentinel.conf中的主要配置项如下：

• logfile"/usr/local/redis/log/sentinel.log" 

logfile段在sentinel.conf中没有，加上即可，方便查看Sentinel运行情况。

• sentinel monitor mymaster 192.168.112.816379 2

其中mymaster是主节点的别名，可以随意配置，但是一定要全局一致；2表示至少有两个Sentinel同意认为Master停止服务了，才会判决Master客观Down（Objectively Down）并开始Failover。

• sentinel down-after-millisecondsmymaster 10000

设置判断Master主观Down的时间期限，默认为30秒，这里设为10秒。

• sentinel parallel-syncs mymaster 1

设置在Failover期间，同时允许多少个Slave与Master进行同步，由于同步期间服务会被挂起，所以如果你用Slave提供查询服务的话，最好把这个数值设置低一些，以保证在Failover期间有更多的Slave可以提供正常的查询服务。      

• sentinel failover-timeout mymaster 90000

    设置开始执行Failover之前的时间期限，默认为3分钟，这里设为90秒。

    配置完成之后，分别启动三个Redis和三个Sentinel：

                     ./redis-serverconf/redis.conf &

                     ./redis-sentinelconf/sentinel.conf &

其中三个Sentinel的日志分别输出如下：

    Sentinel们都已经开始监控192.168.112.81:6379上的Master。

        接下来，我们shutdown掉Master，再来看看Sentinel执行的Failover过程：

       可以看到Sentinel们从主观Down（+sdown）、客观Down（+odown）、一个时代大幕落下新时代来临（+new-epoch）到投票选举新的Master（+vote-for-leader）、192.168.112.82被选为新的Master并走马上任（+switch-master mymaster）、互相重新确认谁是Slave（+slave slave），整个过程一目了然。

二．Key过期事件消息订阅

        在软件开发中经常会遇到需要给一个事务或事物设定过期时间的场景，比如有效期为一个月的优惠券、限制支付时间为24小时之内等等。在Redis中，给Key设定过期（Expire）时间来可以实现这类时效性需求，并通过发布/订阅（Pub/Sub）机制来接收Key过期失效的消息以做后续处理，结合Redis的HA – Sentinel，可以保障此类业务的不间断性。

    默认情况下Redis是不开启Key以及对Key操作事件的消息发布的，需要手动配置开启。另外需要注意的是，Redis只在database 0上支持这个特性。

        修改redis.conf里的 notify-keyspace-events ""为notify-keyspace-events"Ex"便启用了”keyspace events notification”（在发生Failover之后，这里会被自动变为”xE”，有点儿意思）。让我们通过程序测试一下，在一个key过期之后，会收到什么消息。

    用注解的方式构造所需要的Bean：       

       

    接收订阅消息的监听器：

    程序入口：

    执行程序，可以看到如下输出：

    我们的程序已经通过Sentinel连接到了Redis Master - 192.168.112.82，并且正在等待某个Key过期之后发布出来的消息。

进入Redis客户端：

              ./redis-cli -h 192.168.112.82 -p 6379

写入一个Key并给这个Key设置过期时间，比如5秒：

        5秒钟过后，Console输出：

其中__keyevent@0__:expired正是我们订阅的Channel，mykey是过期的key。

OK，这是正常情况下的Key过期消息Pub/Sub。让我们再来看一下当Sentinel监控的Master挂掉并Failover以后，程序是否能无缝地连接到新的Master并接收到Old Master时代Key的过期消息。

    保持程序继续运行。

    再次写入mykey（之前的mykey已经在过期之后被自动删除，这有点像ZooKepper的EPHEMERAL节点），并设置过期时间为120秒，因为我们要观察在Sentinel的Failover期间程序的输出，所以设置稍长一些。

       

     然后shutdown目前的Master– 192.168.112.82，观察Console的输出：

     在短暂的报错之后，程序通过Sentinel连接上了新的Master - 192.168.112.81——这是又一次执行Failover之后的Master——并在120秒的Key过期时间到期之时，接收到了订阅消息。