Redis低成本高可用方案设计

点击上方“全栈程序员社区”，星标公众号
html

重磅干货，第一时间送达

做者：蘑菇先生node

cnblogs.com/mushroom/p/4526912.htmlgit

关于Redis高可用方案，看到较多的是keepalived、zookeeper方案。keepalived是主备模式，意味着总有一台浪费着。zookeeper工做量成本偏高。程序员

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

阅读目录：web

Redis Sentinel面试
故障转移消息接收的3种方式redis
总体流程图算法
总结后端

Redis Sentinel

Sentinel介绍

Sentinel是Redis官方为集群提供的高可用解决方案。在实际项目中可使用sentinel去作redis自动故障转移，减小人工介入的工做量。另外sentinel也给客户端提供了监控消息的通知，这样客户端就可根据消息类型去判断服务器的状态，去作对应的适配操做。

下面是Sentinel主要功能列表：

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

Sentinel配置

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获取/订阅接收事件消息。

搜索Java知音公众号，回复“后端面试”，送你一份Java面试题宝典.pdf

脚本接收

当故障转移期间，能够指定一个“通知”脚本用来告知系统管理员，当前集群的状况。
脚本被容许执行的最大时间为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");

总体设计

推荐使用第三种，其总体流程图以下：

总结

各类sentinel通知消息类型见官方文档，项目中使用的redis客户端在github上

https://github.com/mushroomsir/HRedis

本文分享了楼主在项目中作Redis高可用的经验，但愿对你们有所帮助。在人力物力知足的状况下仍是推荐使用zookeeper方案的。只有三五杆枪的状况下也就退而求其次，利用最小成本知足需求并保留可扩展性。

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

http://redis.io/topics/sentinel

本文分享自微信公众号 - 全栈程序员社区（mush_it）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。