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的节点信息

SENTINEL get-master-addr-by-name <masterName>  //获取当前masterName标识的当前master节点信息，哨兵可监控多个 mater ha，所以要用<masterName>区分
SENTINEL slaves <masterName> //获取可用的slaves列表信息

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

2. 动态failover、扩容

初始化完毕后，在运行期间master节点，和slaves还是可能变化的， 如

(1) master故障、网络分区，sentinel 提升一个slave为新的master

(2) 新增slave节点应对突增流量

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

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

参考： https://redis.io/topics/sentinel#pubsub-messages

2.1 failover切换 master

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

2.2 扩容slave

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

总结

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