redis客户端实现高可用读写分离的方式详解

背景

(1) redis单机的读写性能轻松上大几万，不过线上环境不会只部署光秃秃的一个节点，或者会配合 sentinel 再部署一个 slave作为高可用节点的；
但是standby的slave节点是不对外提供服务真个，一定程度上造成了浪费资源

(2) 当业务不断发展，原来单节点缓存的数据（如，商品信息缓存、配置信息等）的查询qps不断升高（写qps增长不多），突破十几万、几十万的的时候，此时一个节点就扛不住了，我们就需要增加几个redis slaves节点来分担这些查询的压力 也就是读写分离

但是，经常使用的 redis 客户端jedis其实不支持读写分离能力

实现方式

(1) 从配置中心获得 master 和 slaves 的连接信息，分别初始化好一个连接master的写连接池和一组slave的读连接池
(2) 将命令进行分类：履行写命令则从 master的连接池取连接然后履行，如果是读命令则从slave的连接池中取出连接履行
可能有多个slave节点，可以依照一定的策略进行负载均衡(权重、随机、轮询…etc) 从其中一个 slave节点的连接池获得连接

大概长这样：

高可用版本

前面的实现方式正常情况下是可以的

但是:
(1) 如果运行期间 master挂了怎样办？ 如何自动 failover 切换？
(2) 如果流量突增，需要动态扩容一个或多个 slave节点，如何动态生效？

那就不能从配置文件取master和slaves的 ip+port 了，得从redis ha的组件去动态获得 当前master 和可用slave列表的节点信息 => sentinel

1.初始化

向 sentinel 发送命令获得master和slaves的节点信息

拿到连接后，继续用开头的方式去创建连接池就好了

2. 动态failover、扩容

初始化终了后，在运行期间master节点，和slaves或者可能变化的， 如
(1) master故障、网络分区，sentinel 提升一个slave为新的master
(2) 新增slave节点应对突增流量

我们如何能不重启客户真个情况下，动态切换？

sentinel 在进行master切换、slave变更等操作的时候都会向对应的 channel 发布事件，我们可以基于这些事件感知到相应的变化
参考： https://redis.io/topics/sentinel

2.1 failover切换 master

当 sentinel 进行master failover切换的时候，它会向channel： switch-master 发送通知，我们在客户端定阅这个channel，收到事件后，重新进行初始化的步骤便可

2.2 扩容slave

当新的 slave 节点加入， sentinel 感知到则会向channel: +slave 发布事件，我们监听到后，重新获得slaves节点信息重建slaves的连接池就能够了（这边不触及master的变化）

总结

基于 sentienl 获得和动态感知 master、slaves节点信息的变化，我们的读写分离客户端就可以具有高可用+动态扩容感知能力了；

到此这篇关于redis客户端实现高可用读写分离的文章就介绍到这了,更多相关redis读写分离内容请搜索之前的文章或继续浏览下面的相关文章希望大家以后多多支持！