关于java:Redis-低成本高可用设计牛逼

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

对于Redis高可用计划，看到较多的是keepalived、zookeeper计划。

keepalived是主备模式，意味着总有一台节约着。

zookeeper工作量老本偏高。

本文次要介绍下应用官网sentinel做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获取/订阅接管事件音讯。

脚本接管

//当故障转移期间，能够指定一个“告诉”脚本用来告知系统管理员，以后集群的状况。
//脚本被容许执行的最大工夫为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告诉音讯类型见官网来源gao.dai.ma.com搞@代*码网文档，我的项目中应用的redis客户端在github上。本文分享了楼主在我的项目中做Redis高可用的教训，心愿对大家有所帮忙。

在人力物力满足的状况下还是举荐应用zookeeper计划的。 只有三五杆枪的状况下也就退而求其次，利用最小老本满足需要并保留可扩展性。

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

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

近期热文举荐：

1.600+ 道 Java面试题及答案整顿(2021最新版)

2.终于靠开源我的项目弄到 IntelliJ IDEA 激活码了，真香！

3.阿里 Mock 工具正式开源，干掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式公布，全新颠覆性版本！

5.《Java开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞+转发哦！

喜欢 (0)赏

[搞代码]

分享 (0)