集群、安全与运维：从单机走向生产

这一课你将能做到

1. 说清楚主从复制、哨兵、Cluster 三种高可用/扩展方案的分工
2. 完成密码与 ACL 配置、内存淘汰策略选择、慢查询排查
3. 看懂 INFO、SLOWLOG 等运维输出，建立日常巡检清单

为什么要学

学习阶段一个 redis-server 裸跑足够，但生产环境有两道绕不过去的坎：

• 可用性：Redis 宕了，判题限流、排行榜、验证码全挂，网站半残。一台机器不够，需要有「备胎」自动接管。
• 容量与安全：数据多到单机内存装不下要能横向扩展；实例裸奔在网络上会被扫到并勒索；内存写满后服务直接拒绝写入。

本课不要求你亲手搭一套完整集群（那需要 6+ 个节点），但你必须理解每种方案解决什么问题、客户端会遇到什么现象，否则进公司第一天就会懵。

先建立图像

主从复制（Replication）
  主节点(读写) ──同步──> 从节点(只读副本)   主挂了？要人工/哨兵介入

哨兵（Sentinel）
  主 + 从 + 若干哨兵进程：哨兵监控并投票，主挂自动提升一个从为主

集群（Cluster）
  多个主节点各管一部分槽(0-16383)，每个主再有自己的从
  解决：容量分片 + 分片内自动故障转移

跟着做

步骤 1：理解并（可选）演示主从复制

一个节点成为另一个节点的从库：

127.0.0.1:6380> REPLICAOF 127.0.0.1 6379
OK
127.0.0.1:6380> INFO replication
role:slave
master_link_status:up

在主节点写入，从节点立刻能读到；默认从节点只读。断开复制用 REPLICAOF NO ONE。Redis 7 的复制用 psync 增量同步，断线重连只补缺失部分。

步骤 2：哨兵做了什么

哨兵是独立进程（至少 3 个一起部署才可靠），它做三件事：监控（持续 PING 主从）、通知、自动故障转移——主节点失联达到阈值，哨兵投票达成多数后，选一个从节点提升为主，并通知客户端新地址。你不需要记全部配置，但要记住两个数字现象：down-after-milliseconds（主观下线时间）和「多数哨兵同意」（客观下线）。

步骤 3：Cluster 的槽与重定向

Cluster 把 16384 个哈希槽分给各主节点，键用 CRC16(key) mod 16384 决定落在哪个槽：

127.0.0.1:7000> SET rank:alltime 100
(error) MOVED 3999 127.0.0.1:7001

MOVED 不是错误，是「这个键归另一个节点管，以后也归它」，成熟客户端会自动跟随；ASK 表示迁移中的临时重定向，只本次跟随。查看分片信息（Redis 7 推荐 CLUSTER SHARDS）：

127.0.0.1:7000> CLUSTER SHARDS
127.0.0.1:7000> CLUSTER INFO

多键事务/ Lua 在集群里要求相关键同槽，用 hash tag 强制：rank:{course:7}:weekly、rank:{course:7}:monthly 中只有花括号内部分参与槽计算，两键必同槽。

步骤 4：设置密码与 ACL

最简单的密码方式：

127.0.0.1:6379> CONFIG SET requirepass "S3cret-2026"
OK

之后客户端先 AUTH S3cret-2026 才能操作。Redis 7 更推荐 ACL 多账号，按最小权限授权：

127.0.0.1:6379> ACL SETUSER judgeapp on >app-pass ~ratelimit:* ~rank:* +get +set +incr +zadd +zrange
OK
127.0.0.1:6379> ACL WHOAMI
"default"
127.0.0.1:6379> ACL LIST

~模式 限定能访问的键，+命令 限定能执行的命令。判题服务账号就不该能碰 FLUSHALL 和其他业务键。配置写进配置文件或 ACLFILE 才能重启保留。同时确保 Redis 只监听内网、有防火墙/安全组。

步骤 5：内存上限与淘汰策略

127.0.0.1:6379> CONFIG SET maxmemory 1gb
OK
127.0.0.1:6379> CONFIG SET maxmemory-policy allkeys-lru
OK
127.0.0.1:6379> CONFIG GET maxmemory-policy

常用策略速记：

noeviction        写满直接拒绝写入（默认）
allkeys-lru       所有键里优先淘汰最久没用的（纯缓存常用）
volatile-lru      只在带 TTL 的键里淘汰最久没用的
allkeys-random    所有键里随机淘汰
volatile-ttl      带 TTL 的键里优先淘汰快过期的

本站混合场景（排行榜不能被淘汰、验证码可以）适合 volatile-lru/ttl，并保证临时数据都带 TTL；纯缓存实例才用 allkeys-lru。

步骤 6：慢查询与在线诊断

设置慢日志阈值（微秒，10000 = 10ms）和保留条数：

127.0.0.1:6379> CONFIG SET slowlog-log-slower-than 10000
OK
127.0.0.1:6379> SLOWLOG GET 5
127.0.0.1:6379> SLOWLOG LEN

MONITOR 能实时看到所有命令，调试利器，但生产慎用——它会明显降低吞吐，看完马上退出。延迟异常先看 INFO stats（total_commands_processed、instantaneous_ops_per_sec）和 INFO memory（used_memory、mem_fragmentation_ratio）。

步骤 7：日常巡检清单

INFO replication   主从链路是否 up、复制延迟
INFO memory        used_memory / maxmemory、碎片率
INFO persistence   最近 RDB/AOF 是否成功
SLOWLOG GET 10     有无变慢命令
CLIENT LIST        异常连接数
PUBSUB CHANNELS    订阅是否符合预期

再配合两条纪律：配置变更要落到配置文件（CONFIG REWRITE 或改文件），危险命令（FLUSHALL、KEYS、CONFIG）通过 rename-command 或 ACL 收紧。

讲清楚要点

1. 复制解决读扩展与数据冗余，哨兵解决自动故障转移，Cluster 同时解决容量分片与高可用——三者不是竞品，是递进关系。
2. 哨兵和 Cluster 都依赖多数派：节点数应为奇数，至少 3 个哨兵/3 个主节点，避免脑裂时无法决策。
3. MOVED 是永久重定向，ASK 是临时的：集群扩缩容迁移槽期间会看到 ASK。
4. hash tag 是集群多键操作的前提：但别滥用，过多键挤同槽会制造热点。
5. 安全三板斧：不暴露公网、强认证（密码或 ACL）、最小权限（键模式 + 命令白名单）。
6. maxmemory-policy 必须按业务选：选错可能把不能丢的键淘汰掉。碎片率持续偏高（>1.5）关注 MEMORY PURGE 或重启整理。
7. 客户端要配好连接池、超时和重连：哨兵/集群切换通常是秒级，应用必须能重试。

你可能会懵的地方

• 哨兵本身挂了怎么办？ 所以哨兵要部署多个（通常 3 或 5 个）且分布在不同机器，它们之间互相发现、投票，少数哨兵挂掉不影响决策。

• Cluster 里每个键都能读到吗？从节点呢？ 键按槽分散在各主节点，客户端连任一节点都会被重定向到正确节点。默认读主；开 READONLY 后从节点可分担读，但有复制延迟。

• 为什么集群要求至少 3 主 3 从？ 3 个主保证多数派（2/3）在单节点故障时仍能投票；每个主有从节点才能在主挂时接管槽，否则该槽永久不可用。

• 内存碎片率多少算正常？ used_memory_rss / used_memory，1.0-1.5 一般正常；持续高于 1.5 说明回收不充分，低于 1 说明在使用交换分区，更危险。

• CONFIG SET 改的配置重启还有吗？ 默认没有。执行 CONFIG REWRITE 写回配置文件，或直接修改文件，才能持久保留。

错法对照

错法	问题	正解
6379 直接挂公网且无密码	分分钟被扫描、植入勒索	内网部署 + 防火墙 + 强认证
把哨兵只部署 1 个	哨兵自己挂了无人切换	至少 3 个，奇数分布
集群里多键操作不用 hash tag	CROSSSLOT 报错	相关键用 {tag} 对齐槽
有持久键却选 allkeys-lru	排行榜等可能被淘汰	混合场景选 volatile-*
生产长期开着 MONITOR	吞吐显著下降	仅短时调试
看到 MOVED 不处理反复重试	命令一直失败	用支持集群的客户端或跟随重定向

卡点急救

1. 写入报 OOM command not allowed：内存到 maxmemory 了。先确认淘汰策略是否符合预期，临时可清理大键/临时数据，根治靠扩容或调整策略。
2. 主从数据不一致：检查 master_link_status 和复制延迟（INFO replication 的 master_last_io_seconds_ago），断链严重会触发全量重同步，关注网络。
3. 客户端在故障切换期间报错：切换是秒级过程，确认客户端有重试；持续报错检查哨兵/集群的 quorum 和节点存活。

面试常问

• 主从、哨兵、Cluster 的区别？ 主从提供数据副本和读扩展但需人工切换；哨兵在主从基础上自动监控与故障转移，仍受单机容量限制；Cluster 按 16384 槽分片，多主多从，同时解决容量与高可用。

• Redis 集群的 MOVED 和 ASK？ MOVED：键已确定归另一个槽/节点，客户端应更新本地映射；ASK：槽迁移中的临时重定向，只本次跟随，不更新映射。

• Redis 内存满了怎么办？ 取决于 maxmemory-policy：noeviction 会拒绝写入；LRU/TTL/random 策略会先淘汰符合条件的键。加内存、设 TTL、清理大键是常用手段，混合业务务必保护持久键。

自测三问

1. 三种方案分别解决什么问题？本站数据量到什么阶段才需要 Cluster？
2. hash tag 解决什么问题？写出一对能保证同槽的键。
3. 生产安全要做哪三件事？allkeys-lru 为什么不适合本站排行榜数据？

小结一句话

复制、哨兵、集群构成 Redis 的可用性三级阶梯，再配上认证、权限、淘汰和巡检四件武器，Redis 才算从练习环境走进生产环境。

延伸

• 复制文档
• Sentinel 文档
• Cluster 规范
• ACL 文档
• 下一课：综合练习——把五大场景串成一次完整实战。