没有最好的架构，只有更合适的架构。Redis低成本、高可用设计

拼搏现实的明天。 2022-09-10 12:09 206阅读 0赞

![ad9e38b73ab949cabd31002a865d8707.png][]

作者：蘑菇先生  
出处：http://mushroom.cnblogs.com/

关于Redis高可用方案，看到较多的是keepalived、zookeeper方案。

keepalived是主备模式，意味着总有一台浪费着。

zookeeper工作量成本偏高。

本文主要介绍下使用官方sentinel做redis高可用方案的设计。

## Redis Sentinel ##

### Sentinel介绍 ###

[Sentinel是Redis官方为集群提供的高可用解决方案。在实际项目中可以使用sentinel去做redis自动故障转移，减少人工介入的工作量。][Sentinel_Redis_sentinel_redis]

[另外sentinel也给客户端提供了监控消息的通知，这样客户端就可根据消息类型去判断服务器的状态，去做对应的适配操作。][Sentinel_Redis_sentinel_redis]

下面是Sentinel主要功能列表：

*  [Monitoring：Sentinel持续检查集群中的master、slave状态，判断是否存活。][Sentinel_Redis_sentinel_redis]
 *  [Notification：在发现某个redis实例死的情况下，Sentinel能通过API通知系统管理员或其他程序脚本。][Sentinel_Redis_sentinel_redis]
 *  [Automatic failover：如果一个master挂掉后，sentinel立马启动故障转移，把某个slave提升为master。其他的slave重新配置指向新master。][Sentinel_Redis_sentinel_redis]
 *  [Configuration provider：对于客户端来说sentinel通知是有效可信赖的。客户端会连接sentinel去请求当前master的地址，一旦发生故障sentinel会提供新地址给客户端。][Sentinel_Redis_sentinel_redis]

### Sentinel配置 ###

Sentinel本质上只是一个运行在特殊模式下的redis服务器，通过不同配置来区分提供服务。

推荐阅读：[阿里开源的限流神器 Sentinel][Sentinel_Redis_sentinel_redis]。

sentinel.conf配置：

// [监控名称] [ip] [port] [多少sentinel同意才发生故障转移]
    sentinel monitor mymaster 127.0.0.1 6379 2
    // [监控名称] [Master多少毫秒后不回应ping命令，就认为master是主观下线状态]
    sentinel down-after-milliseconds mymaster 60000
    // [故障转移超时时间]
    sentinel failover-timeout mymaster 180000
    //[在执行故障转移时,最多可以有多少个从服务器同时对新的主服务器进行同步]
    sentinel parallel-syncs mymaster 1

sentinel需要使用redis2.8版本以上，启动如下：

redis-sentinel sentinel.conf

启动后Sentinel会：

*  以10秒一次的频率，向被监视的master发送info命令，根据回复获取master当前信息。
 *  以1秒一次的频率，向所有redis服务器、包含sentinel在内发送PING命令，通过回复判断服务器是否在线。
 *  以2秒一次的频率，通过向所有被监视的master，slave服务器发送包含当前sentinel，master信息的消息。

另外建议sentinel至少起3个实例以上，并配置2个实例同意即可发生转移。5个实例，配置3个实例同意以此类推。

## 故障转移消息接收的3种方式 ##

Redis服务器一旦发送故障后，sentinel通过raft算法投票选举新master。故障转移过程可以通过sentinel的API获取/订阅接收事件消息。Redis 系列面试题和答案我都整理完了，关注公众号Java技术栈回复：面试，可以免费获取哦。

### 脚本接收 ###

//当故障转移期间，可以指定一个“通知”脚本用来告知系统管理员，当前集群的情况。

//脚本被允许执行的最大时间为60秒，如果超时，脚本将会被终止(KILL)

sentinel notification-script mymaster /var/redis/notify.sh

//故障转移期之后，配置通知客户端的脚本.

sentinel client-reconfig-script mymaster /var/redis/notifyReconfig.sh

### 客户端直接接收 ###

Sentinel的故障转移消息通知使用的是redis发布订阅，就是说在故障转移期间所有产生的事件信息，都通过频道(channel)发布出去。

比如我们加台slave服务器，sentinel监听到后会发布加slave的消息到"+slave"频道上，客户端只需要订阅"+slave"频道即可接收到对应消息。

其消息格式如下：\[实例类型\] \[事件服务器名称\] \[服务器ip\] \[服务器端口\] @\[master名称\] \[ip\] \[端口\]

<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port>

通知消息格式示例：

*          //订阅类型， *即订阅所有事件消息。
    -sdown     //消息类型
    slave 127.0.0.1:6379 127.0.0.1 6379 @ mymaster 127.0.0.1 6381

订阅消息示例：

using (RedisSentinel rs = new RedisSentinel(CurrentNode.Host, CurrentNode.Port))
    {
        var redisPubSub = new RedisPubSub(node.Host, node.Port);
        redisPubSub.OnMessage += OnMessage;
        redisPubSub.OnSuccess += (msg) =>{};
        redisPubSub.OnUnSubscribe += (obj) =>{};
        redisPubSub.OnError = (exception) =>{ };
        redisPubSub.PSubscribe("*");
    }

### 服务间接接收 ###

这种方式在第二种基础上扩展了一层，即应用端不直接订阅sentinel。单独做服务去干这件事情，然后应用端提供API供这个服务回调通知。

这样做的好处在于：

*  减少应用端监听失败出错的可能性。
 *  应用端由主动方变成被动方，降低耦合。
 *  性能提高，轮询变回调。
 *  独立成服务可扩展性更高。

比如：

1：以后换掉sentinel，我们只需要动服务即可，应用端无需更改。

2：可以在服务内多增加一层守护线程去主动拉取redis状态，这样可确保即使sentinel不生效，也能及时察觉redis状态，并通知到应用端。当然这种情况很极端，因为sentinel配的也是多节点，同时挂的几率非常小。示例：应用端提供回调API，在这个API逻辑下去刷新内存中的Redis连接。

http://127.0.0.1/redis/notify.api

独立服务监控到状况后，调用API通知应用端：

httprequest.post("http://127.0.0/redis/notify.api");

## 整体设计 ##

推荐使用第三种，其整体流程图如下：

![5b9b9081408e8f9b95cb59b17fc32110.png][]

## 总结 ##

各种sentinel通知消息类型见官方文档，项目中使用的redis客户端在github上。本文分享了楼主在项目中做Redis高可用的经验，希望对大家有所帮助。

[在人力物力满足的情况下还是推荐使用zookeeper方案的。只有三五杆枪的情况下也就退而求其次，利用最小成本满足需求并保留可扩展性。][zookeeper]

**相信没有最好的架构，只有更合适的架构。**

参考：http://redis.io/topics/sentinel

[ad9e38b73ab949cabd31002a865d8707.png]: /images/20220829/da6e6d5deb674e509c38e1ff92ca5f5d.png
[Sentinel_Redis_sentinel_redis]: http://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw%3D%3D&chksm=eb503e76dc27b760ce081fe94229c54f534e170700affebe6ebdc22157b963d859d35a6a96b4&idx=1&mid=2247514944&scene=21&sn=d41a7c7bd284e09165540fdaf968cd32#wechat_redirect
[5b9b9081408e8f9b95cb59b17fc32110.png]: /images/20220829/3b37575aeb7b42dfa3ca34820c995125.png
[zookeeper]: http://mp.weixin.qq.com/s?__biz=MzI3ODcxMzQzMw%3D%3D&chksm=eb53979fdc241e8957a82741c5bed23137daf8726b88f237c771831fbbd362dead4399070de2&idx=1&mid=2247488169&scene=21&sn=248b75817e4a6c8e65c40a6b17603196#wechat_redirect