Redis(三)-Redis Sentinel和Redis Cluster

Redis Sentinel

Redis-Sentinel(哨兵模式)是Redis官方推荐的高可用性(HA)解决方案,当用Redis做Master-slave的高可用方案时,假如master宕机了,Redis本身(包括它的很多客户端)都没有实现自动进行主备切换,而Redis-sentinel本身也是一个独立运行的进程,它能监控多个master-slave集群,发现master宕机后能进行自动切换。它的主要功能有以下几点:

  • 不时地监控redis是否按照预期良好地运行;
  • 如果发现某个redis节点运行出现状况,能够通知另外一个进程(例如它的客户端);
  • 能够进行自动切换。当一个master节点不可用时,能够选举出master的多个slave(如果有超过一个slave的话)中的一个来作为新的master,其它的slave节点会将它所追随的master的地址改为被提升为master的slave的新地址。

从上图中可以得出Sentinel其实就是Client和Redis之间的桥梁,所有的客户端都通过Sentinel程序获取Redis的Master服务。首先Sentinel是集群部署的,Client可以链接任何一个Sentinel服务所获的结果都是一致的。其次,所有的Sentinel服务都会对Redis的主从服务进行监控,当监控到Master服务无响应的时候,Sentinel内部进行仲裁,从所有的 Slave选举出一个做为新的Master。并且把其他的slave作为新的Master的Slave。最后通知所有的客户端新的Master服务地址。如果旧的Master服务地址重新启动,这个时候,它将被设置为Slave服务。

Sentinel 可以管理master-slave节点,看似Redis的稳定性得到一个比较好的保障。但是如果Sentinel是单节点的话,如果Sentinel宕机了,那master-slave这种模式就不能发挥其作用了。幸好Sentinel也支持集群模式,Sentinel的集群模式主要有以下几个好处:

  1. 即使有一些sentinel进程宕掉了,依然可以进行redis集群的主备切换;
  2. 如果只有一个sentinel进程,如果这个进程运行出错,或者是网络堵塞,那么将无法实现redis集群的主备切换(单点问题);
  3. 如果有多个sentinel,redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。

Redis Sentinel 集群模式可以增强整个Redis集群的稳定性与可靠性,但是当某个节点的master节点挂了要重新选取出新的master节点时,Redis Sentinel的集群模式选取的复杂度显然高于单点的Redis Sentinel 模式,此时需要一个比较靠谱的选取算法,即Redis Sentinel 集群模式的 “仲裁会”。

Redis Sentinel 集群模式的 “仲裁会”

当一个master被sentinel集群监控时,需要为它指定一个参数,这个参数指定了当需要判决master为不可用,并且进行failover时,所需要的sentinel数量,本文中我们暂时称这个参数为票数,不过,当failover主备切换真正被触发后,failover并不会马上进行,还需要sentinel中的大多数sentinel授权后才可以进行failover。当ODOWN时,failover被触发。failover一旦被触发,尝试去进行failover的sentinel会去获得“大多数”sentinel的授权(如果票数比大多数还要大的时候,则询问更多的sentinel)这个区别看起来很微妙,但是很容易理解和使用。例如,集群中有5个sentinel,票数被设置为2,当2个sentinel认为一个master已经不可用了以后,将会触发failover,但是,进行failover的那个sentinel必须先获得至少3个sentinel的授权才可以实行failover。如果票数被设置为5,要达到ODOWN状态,必须所有5个sentinel都主观认为master为不可用,要进行failover,那么得获得所有5个sentinel的授权。

Redis Cluster

数据分布

哈希分布

  • 节点取余分区

    hash(key)%nodes,这种分区方式的主要问题是节点伸缩。
    推荐采用翻倍扩容方式,即增加节点数至原来的2倍,这种扩容方式需要迁移的数据约是50%。

  • 一致性哈希分区

    客户端分片:哈希+顺时针(优化取余)
    节点伸缩:只影响临近节点,但是还是有数据迁移
    翻倍伸缩(推荐使用):能保证最小迁移数据和负载均衡

  • 虚拟槽分区

    预设虚拟槽:每个槽映射一个数据子集,一般比节点数大
    良好的哈希函数:例如CRC16
    服务端管理节点、槽、数据:例如Redis Cluster


在对一个key进行hash并取余后,会发送给任意一个节点,节点知道自己负责的槽范围并且节点之间共享消息,当该节点负责这个key就对直接进行操作,否则该节点就通知应该去哪个节点。(在智能客户端模式下,客户端直到每个节点负责的槽范围,就不需要上面的发送给任意一个节点)

posted @ 2020-07-05 21:36  tianqibucuo  阅读(281)  评论(0编辑  收藏  举报