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

42次阅读

共计 3102 个字符,预计需要花费 8 分钟才能阅读完成。

作者:蘑菇学生 \
出处: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 告诉音讯类型见官网文档,我的项目中应用的 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