Redis 深度历险: 核心原理和应用实践3
Sentinel 基本使用 集群 1:李代桃僵 —— Sentinel
目前我们讲的 Redis 还只是主从方案,最终一致性。读者们可思考过,如果主节点凌晨
3 点突发宕机怎么办?就坐等运维从床上爬起来,然后手工进行从主切换,再通知所有的程
序把地址统统改一遍重新上线么?毫无疑问,这样的人工运维效率太低,事故发生时估计得
至少 1 个小时才能缓过来。如果是一个大型公司,这样的事故足以上新闻了
所以我们必须有一个高可用方案来抵抗节点故障,当故障发生时可以自动进行从主切
换,程序可以不用重启,运维可以继续睡大觉,仿佛什么事也没发生一样。Redis 官方提供
了这样一种方案 —— Redis Sentinel(哨兵)。
我们可以将 Redis Sentinel 集群看成是一个 ZooKeeper 集群,它是集群高可用的心脏,
它一般是由 3~5 个节点组成,这样挂了个别节点集群还可以正常运转
它负责持续监控主从节点的健康,当主节点挂掉时,自动选择一个最优的从节点切换为
主节点。客户端来连接集群时,会首先连接 sentinel,通过 sentinel 来查询主节点的地址,
然后再去连接主节点进行数据交互。当主节点发生故障时,客户端会重新向 sentinel 要地
址,sentinel 会将最新的主节点地址告诉客户端。如此应用程序将无需重启即可自动完成节
点切换。比如上图的主节点挂掉后,集群将可能自动调整为下图所示结构。
从这张图中我们能看到主节点挂掉了,原先的主从复制也断开了,客户端和损坏的主节
点也断开了。从节点被提升为新的主节点,其它从节点开始和新的主节点建立复制关系。客
户端通过新的主节点继续进行交互。Sentinel 会持续监控已经挂掉了主节点,待它恢复后,
集群会调整为下面这张图。
此时原先挂掉的主节点现在变成了从节点,从新的主节点那里建立复制关系
消息丢失
Redis 主从采用异步复制,意味着当主节点挂掉时,从节点可能没有收到全部的同步消
息,这部分未同步的消息就丢失了。如果主从延迟特别大,那么丢失的数据就可能会特别
多。Sentinel 无法保证消息完全不丢失,但是也尽可能保证消息少丢失。它有两个选项可以
限制主从延迟过大。
min-slaves-to-write 1
min-slaves-max-lag 10
第一个参数表示主节点必须至少有一个从节点在进行正常复制,否则就停止对外写服
务,丧失可用性。
何为正常复制,何为异常复制?这个就是由第二个参数控制的,它的单位是秒,表示如
果 10s 没有收到从节点的反馈,就意味着从节点同步不正常,要么网络断开了,要么一直没
有给反馈。
Sentinel 基本使用
有个问题是,但 sentinel 进行主从切换时,客户端如何知道地址变更了 ? 通过分析源
码,我发现 redis-py 在建立连接的时候进行了主库地址变更判断。
连接池建立新连接时,会去查询主库地址,然后跟内存中的主库地址进行比对,如果变
更了,就断开所有连接,重新使用新地址建立新连接。如果是旧的主库挂掉了,那么所有正
在使用的连接都会被关闭,然后在重连时就会用上新地址
集群 2:分而治之 —— Codis
在大数据高并发场景下,单个 Redis 实例往往会显得捉襟见肘。首先体现在内存上,单
个 Redis 的内存不宜过大,内存太大会导致 rdb 文件过大,进一步导致主从同步时全量同
步时间过长,在实例重启恢复时也会消耗很长的数据加载时间,特别是在云环境下,单个实
例内存往往都是受限的。其次体现在 CPU 的利用率上,单个 Redis 实例只能利用单个核
心,这单个核心要完成海量数据的存取和管理工作压力会非常大
Codis 是 Redis 集群方案之一,令我们感到骄傲的是,它是中国人开发并开源的,来自
前豌豆荚中间件团队。有了
Codis 技术积累之后,项目「突头人」刘奇又开发出来中国人自己的开源分布式数据库 ——
TiDB,可以说 6 到飞起。????
Codis 使用 Go 语言开发,它是一个代理中间件,它和 Redis 一样也使用 Redis 协议
对外提供服务,当客户端向 Codis 发送指令时,Codis 负责将指令转发到后面的 Redis 实例
来执行,并将返回结果再转回给客户端。