Redis低成本高可用方案设计

关于Redis高可用方案，经常看到的有keepalived和zookeeper方案。keepalived是主备模式，也就是说总有一个被浪费。Zookeeper工作负载成本高。本文主要介绍使用官方sentinel作为redis高可用方案的设计。Sentinel简介Sentinel是Redis官方为集群提供的高可用解决方案。在实际项目中，可以使用sentinel做redis的自动故障转移，减少人工干预的工作量。此外，sentinel还为客户端提供监听消息的通知，以便客户端根据消息类型判断服务端的状态，并进行相应的适配操作。以下是Sentinel的主要功能列表：监控：Sentinel不断检查集群中master和slave的状态，判断是否存活。通知：当发现一个redis实例挂掉时，Sentinel可以通过API通知系统管理员或者其他程序脚本。自动故障转移：如果一个master挂掉了，sentinel会立即启动一个failover并将一个slave提升为master。其他从站被重新配置为指向新的主站。配置提供者：Sentinel通知对客户端有效且可靠。客户端会连接到sentinel请求当前master的地址。一旦发生故障，哨兵会提供一个新的地址给客户端。Sentinel配置Sentinel本质上只是一个运行在特殊模式下的redis服务器，通过不同的配置提供服务。sentinel.conf配置：//[监控名称][ip][端口][故障转移前同意多少个sentinel]sentinelmonitormymaster127.0.0.163792//[监控名称][Master不响应ping命令后多少毫秒，认为master处于主观下线状态]sentineldown-after-millisecondsmymaster60000//[failovertimeouttime]sentinelfailover-timeoutmymaster180000//[执行failover时，有多少从服务器可以同时连接到新的服务器与主服务器同步]sentinelparallel-syncsmymaster1sentinel需要使用redis2.8以上版本，启动如下：redis-sentinelsentinel.conf启动Sentinel后会：发送信息命令以10秒的频率给被监控的master，根据回复获取master的当前信息。每秒向包括sentinel在内的所有redis服务器发送一次PING命令，通过回复判断服务器是否在线。以2秒的频率，向所有被监控的主从服务器发送包含当前sentinel和master信息的消息。另外，建议sentinel至少有3个实例，配置2个实例同意转移。5个实例，配置3个实例同意等等。学会这15点，让你分分钟赢取Redis数据库故障转移消息的3种接收方式一旦Redis服务器发送故障，sentinel通过raft算法投票选出新的master。failover进程可以通过sentinel的API获取/订阅接收事件消息。ScriptReceive当发生故障转移时，可以指定一个“notify”脚本来通知系统管理员当前的集群状态。允许脚本执行的最长时间为60秒。如果超时则终止脚本（KILL）/notifyReconfig.sh客户端使用redis发布订阅直接接收Sentinel的故障转移消息通知。也就是说，故障转移过程中产生的所有事件信息都通过通道发布。比如我们添加一个slave服务器，sentinel监听后会将添加slave的消息发布到“+slave”频道。客户端只需要订阅“+slave”频道就可以接收相应的消息。消息格式如下：[实例类型][事件服务器名称][服务器ip][服务器端口]@[主服务器名称][ip][端口]<实例类型><名称><端口>@通知消息格式示例：*//订阅类型，*表示订阅所有事件消息。-sdown//消息消息从第127.0.0.0.0.1：6379127.0.0.0.0.16379@mymaster127.0.0.0.16381.16381订阅订阅订阅消息消息：use（redissentinelrs=redissentInelrs=newredissentInel（newredissentinel）节点主机、节点端口）；redisPubSub.OnMessage+=OnMessage;redisPubSub.OnSuccess+=(msg)=>{};redisPubSub.OnUnSubscribe+=(obj)=>{};redisPubSub.OnError=（异常）=>{};redisPubSub.PSubscribe("*");服务间接接收的方式是第二种方式的扩展，即应用端不直接订阅sentinel。做一个单独的服务来做这件事，然后应用端提供API给服务回调通知。这样做的好处是减少了应用端监控失败出错的可能性。应用端由主动端变为被动端，以降低耦合。性能提高，轮询更改为回调。独立服务更具可扩展性。例如：1：以后要更换sentinel，我们只需要开通服务即可，应用端不需要改动。2：可以在服务中多加一层daemon线程，主动拉取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");总体设计建议采用第三种，总体流程图如下：哨兵通知消息的类型总结见官方文档。项目中使用的redis客户端在github上https://github.com/mushroomsi...本文分享楼主在项目中做Redis高可用的经验，希望对大家有所帮助。在人力物力满足的情况下，推荐使用zookeeper方案。当只有三五把枪时，用最少的成本来满足需求并保持可扩展性是退而求其次的。我相信没有最好的架构，只有更合适的架构。http://redis.io/topics/sentinel作者：蘑菇先生来源：https://www.cnblogs.com/mushr...