简介
Sentinel提供了一种高可用方案来抵抗节点故障,当故障发生时Redis集群可以自动进行主从切换,程序可以不用重启。
Redis Sentinel集群可以看成是一个Zookeeper集群,他是Redis集群高可用的心脏,一般由3-5个节点组成,这样即使挂了个别节点集群还可以正常运转。
他负责持续监控主从节点的健康,当主节点挂掉时,自动选择一个最优的从节点切换为主节点。具体流程如下
- 客户端连接集群时,首先连接sentinel,通过sentinel查询主节点的地址
- 客户端再去连接主节点进行数据交互。
- 当主节点发生故障时,客户端重新向sentinel查询地址
- sentinel将最新的主节点地址告诉客户端。
从上图可以看出当主节点挂掉后,原先的主从复制也断开了,客户端和损坏的主节点也断开连接,从节点被提升为新的主节点,其他从节点开始和新的主节点建立复制关系
。客户端通过新的主节点继续进行交互。Sentinel会持续监控已经挂掉了的主节点,待他恢复后,集群会重新调整成下图
此时,原先挂掉的主节点现在变成了从节点,从新的主节点那里复制关系。
消息丢失
Redis主从采用异步复制(同步复制可以采用wait指令,但是在网络分区时会丧失可用性)
,意味着当主节点挂掉时,从节点可能没有收到全部的同步消息,这部分未同步的消息就丢失了。如果主从延迟特别大,那么丢失的数据就可能特别多。Sentinel无法保证消息完全不丢失,但是也尽可能保证消息 少丢失,他有两个选项可以限制主从延迟过大。
min-salves-to-write 1
## 主节点必须至少有一个从节点在进行正常复制
min-salves-max-lag 10
## 如果10s没有收到从节点的反馈,意味着从节点同步不正常
Sentinel基本使用
示例
>>> from redis.sentinel import Sentinel
>>> sentinel = Sentinel([('localhost', 26379)], socket_timeout=0.1)
>>> sentinel.discover_master('mymaster')
('127.0.0.1', 6379)
>>> sentinel.discover_slaves('mymaster')
[('127.0.0.1', 6380)]
>>> master = sentinel.master_for('mymaster', socket_timeout=0.1)
>>> slave = sentinel.slave_for('mymaster', socket_timeout=0.1)
>>> master.set('foo', 'bar')
>>> slave.get('foo')
'bar'
通过xxx_for可以从连接池中拿出一个连接来使用,因为从地址有多个,redis客户端对从地址采用轮询方案,也就是RoundRobin。
sentine进行主从切换时,客户端如何感知变化
通常采用如下几种方案
- Sentinel作为服务发现:客户端不直接连接到Redis主服务器,而是连接到Sentinel,客户端通过向sentinel发送命令来获取当前主服务器的地址和端口
- sentinel发送订阅消息:sentinel支持发布/订阅模式,当主服务器发生变化时,sentinel向特定频道发布消息,客户端可以订阅这些频道来感知主服务器地址的更新。
- 客户端库支持:Jedis、Lettuce内置了对Redis Sentinel的支持,能够自动发现和重新连接到新的主服务器,应用程序无感知。
- 配置重写:在某些情况下,Sentinel可以在执行故障转移后,重写客户端的配置文件,使其指向新的主服务器。这种方式更适用于那些直接配置了Redis服务器地址的客户端,但需要手动重启或重新加载配置才能生效,因此不如前两种方法灵活。