上一个步骤的主从架构无法实现master囷slave角色的自动切换即当master出现redis服务异常、主机断电、磁盘损坏等问题导致master无法使用,而redis高可用无法实现自故障转移(将slave提升为master)需要手动改環境配置才能切换到slave redis服务器,另外也无法横向扩展Redis服务的并行写入性能当单台Redis服务器性能无法满足业务写入需求的时候就必须需要一种方式解决以上的两个核心问题,即:1.master和slave角色的无缝切换让业务无感知从而不影响业务使用 2.可以横向动态扩展Redis服务器,从而实现多台服务器并行写入以实现更高并发的目的
需要手动先指定某一台Redis服务器为master然后将其他slave服务器使用命令配置为master服务器的slave,哨兵的前提是已经手动实现了一个redis master-slave的运行環境
实现一个主两从基于哨兵的高可用redis架构
应用程序客户端连接到redis
而Redis为了保障高可用,服务一般都是Sentinel部署方式,当Redis服务中的主服务挂掉之后,會仲裁出另外一台Slaves服务充当Master这个时候,我们的应用即使使用了Jedis 连接池,Master服务挂了,我们的应用将还是无法连接新的Master服务,为了解决这个问题, Jedis也提供了相应的Sentinel实现,能够在Redis Sentinel主从切换时候,通知我们的应用,把我们的应用连接到新的Master服务
Sentinel底层基于Redis订阅实现Redis主从服务的切换通知,当Reids发生主從切换时Sentinel会发送通知主动通知Jedis进行连接的切换,JedisSentinelPool在每次从连接池中获取链接对象的时候,都要对连接对象进行检测,如果此链接和Sentinel的Master服务连接参数不一致,则会关闭此连接,重新获取新的Jedis连接对象
哨兵可以不和redis服务器部署在一起
在sentinel状态中尤其是最后一行,涉及到masterIP是多少有几个slave,有几个sentinels必须是符合全部服务器数量的。
查看故障转移时的sentine信息
故障转移后的redis配置文件
查看sentine日誌:不会随着原maser主机重新上线而回归