目录

Sentinel 基本使用 集群 1：李代桃僵 —— Sentinel 

集群 2：分而治之 —— Codis 

集群 3：众志成城 —— Cluster 

拓展 1：耳听八方 —— Stream 

拓展 2：无所不知 —— Info 指令

拓展 3：拾遗漏补 —— 再谈分布式锁

拓展 4：朝生暮死 —— 过期策略

拓展 5：优胜劣汰 —— LRU 

拓展 6：平波缓进 —— 懒惰删除 

拓展 7：妙手仁心 —— 优雅地使用 Jedis

拓展 8：居安思危 —— 保护 Redis 

极度深寒 几节放弃!!!

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 到飞起。