1. Redis自动化运维与集群治理导论

Redis 在多数团队里的引入路径都很相似：先作为缓存顶住热点读，再逐步承载会话、排行榜、分布式锁、消息队列甚至部分业务主数据。当实例从 1 个变成几十个、从单机变成主从加哨兵、再演进到 Redis Cluster 分片集群时，运维工作的性质就发生了变化——不再是"连上去敲几条命令"，而是要面对一批会漂移、会扩容、会故障切换、会因大 key 而抖动的分布式数据节点。本课程的目标，就是把这件"越来越难手工完成"的事情，拆解成可自动化、可观测、可治理的工程体系。

一、课程要解决的核心问题

先明确边界。本课程讨论两件相互关联但不等同的事：自动化运维与集群治理。

自动化运维关注"把重复动作交给程序"：实例的批量部署与配置下发、版本升级与重启编排、备份与恢复、慢查询与大 key 的周期性巡检、故障后的自动拉起与主从切换后的拓扑修正。它的衡量标准是人工介入次数和操作一致性——同一批 50 个实例，配置漂移是否为零，扩容一次需要几个人小时。

集群治理关注"让集群长期处于可控状态"：槽位（slot）分布是否均衡、节点是否健康、内存水位与淘汰策略是否合理、热点分片是否需要拆分、访问权限与命名空间是否被滥用、容量增长是否有可预测的规划。它的衡量标准是稳定性与可预期性——不是"这次没出事"，而是"我们知道它为什么不会出事"。

两者的关系可以用一句话概括：自动化运维是手段，集群治理是目标；没有治理目标的自动化，只是把混乱执行得更快。

二、为什么"能跑"不等于"可治理"

很多团队的第一个 Redis 集群是"能跑"的：三主三从，槽位平均分配，业务读写正常。但半年后问题开始出现——某个分片内存涨到 12 GB 而其他分片只有 4 GB，原因是某个业务把用户维度的 Hash 全塞进了一个 key；一次主节点宕机触发了故障转移，但客户端连接池没有刷新拓扑，导致部分请求持续打到旧主节点；备份脚本一直在跑，但从未做过恢复演练，真出事时发现 RDB 文件是空的。

这些问题的共同点是：它们不会在"能跑"的验收标准里暴露，只会在"可治理"的标准里暴露。可治理意味着三件事：状态可见（知道每个节点、每个分片、每个 key 模式在发生什么）、变化可控（扩容、升级、故障切换都有预案和回滚路径）、责任可追溯（谁在什么时候改了什么配置，为什么改）。

三、一个具体的判断示例：分片倾斜

以 Redis Cluster 为例，判断是否需要治理，不能只看"集群状态 ok"。假设一个 6 分片集群，通过 CLUSTER INFO 看到 cluster_state:ok，但进一步采集各节点内存与 key 数量，得到如下示例数据（以下为教学假设数据，非实测）：

shard-3 的 key 数量并不最多，但内存是其他分片的近 3 倍，说明存在大 key 或大 Hash/List。此时"集群状态 ok"是真的，但治理已经失败：该分片一旦触发内存淘汰，会优先淘汰掉其他正常业务的 key；一旦该主节点故障，从节点全量同步需要传输 11.6 GB 数据，恢复时间远超其他分片。正确的治理动作不是"扩容加机器"，而是先用 redis-cli --bigkeys 或 MEMORY USAGE 定位大 key，推动业务侧拆分，再评估是否需要调整槽位分布。

四、本课程的组织方式

后续章节会沿着"能力建设"的路径展开：先建立可观测基础（指标采集、慢查询与大 key 巡检、延迟分位监控），再构建自动化执行能力（配置管理、批量操作、备份恢复、故障自愈），然后进入集群治理的核心议题（槽位均衡、扩缩容、热点治理、ACL 与安全边界），最后落到工程化实践（变更流程、演练机制、容量规划与复盘）。每一部分都会给出可执行的命令、配置片段、判断阈值和示例数据，而不是停留在概念层面。

需要强调的是，自动化工具本身不是目的。一个用 Ansible 批量重启 50 个 Redis 实例的脚本，如果没有配套的健康检查、流量摘除和回滚逻辑，它带来的风险可能比手工操作更大——因为它执行得更快、影响面更广。本课程反复强调的原则是：每一次自动化动作，都必须有明确的输入条件、可观测的中间状态和可判断的成功/失败标准。这也是"治理"区别于"运维脚本"的根本所在。