2. Redis部署模式与选型

Redis 的部署模式决定了系统的可用性上限、扩展方式以及后续自动化治理的复杂度。很多线上事故并非源于命令用错，而是部署模式与业务需求不匹配：用单机承载核心缓存、用主从代替高可用、在 Cluster 上执行跨槽事务。理解四种模式的本质差异，是选型与自动化建设的第一步。

四种模式的核心机制

单机模式只有一个 Redis 进程，所有数据与读写压力集中在一个实例上。它没有复制、没有故障转移，进程退出或宿主机宕机即服务中断。优点是部署简单、无额外网络开销、支持全部命令与多 DB。适合本地开发、单元测试、非关键缓存、以及可容忍分钟级重建的临时数据。

主从模式（Replication）通过 replicaof 建立一主多从的复制关系。主节点处理写与读，从节点异步接收主节点的数据变更，可承担只读查询、备份、离线分析等流量。复制是异步的，主节点故障时从节点数据可能滞后，且主从本身不具备自动故障转移能力，主挂了需要人工把某个从提升为主。因此主从解决的是读扩展与数据冗余，不是高可用。

哨兵模式（Sentinel）在主从基础上引入一组 Sentinel 进程，负责监控、主观/客观下线判定、领导者选举与自动故障转移。当多数 Sentinel 认为主节点客观下线后，会选出一个 Sentinel 执行故障转移：挑选数据最新的从节点提升为主，并通知其余从节点复制新主，同时向客户端推送新拓扑。哨兵把“人工切换”变成“自动切换”，但数据仍是单主写入，容量与写性能受单机限制。

Cluster 模式采用分片（sharding）架构，把整个键空间划分为 16384 个哈希槽，每个主节点负责一部分槽，槽内数据由该主及其从节点管理。客户端根据 CRC16(key) mod 16384 计算槽位并路由请求，遇到 MOVED/ASK 重定向时更新本地槽映射。Cluster 支持在线扩缩容（迁移槽）、自动故障转移，写能力与容量可水平扩展。代价是：只支持 DB 0、多键操作要求同槽（可用 hash tag 强制同槽）、事务与 Lua 脚本不能跨槽、运维复杂度显著上升。

选型的三个收敛维度

选型不应凭经验拍板，建议按三个维度依次收敛。第一是数据量与写吞吐：若数据集能稳定放入单实例内存（例如 20GB 以内）且写 QPS 未触顶，单机、主从或哨兵即可；若数据量持续增长或写 QPS 超过单实例能力，必须考虑 Cluster。第二是可用性要求：可容忍分钟级中断的场景用单机或主从；要求自动切换、RTO 在秒级到十几秒的场景用哨兵或 Cluster。第三是命令与事务约束：需要多 DB、跨键事务、跨槽 Lua 的业务，应避免 Cluster，或通过 hash tag 把相关键强制到同一槽。

一个常见的误判是“上了哨兵就等于高可用”。哨兵只解决主节点故障转移，不解决容量与写瓶颈；当写 QPS 已经打满单主时，哨兵切换后新主依然会被打满。另一个误判是“Cluster 一定比哨兵强”。Cluster 的运维成本、客户端改造、跨槽限制都是真实代价，中小规模业务用哨兵往往更划算。

自动化部署需求的差异

不同模式对自动化的诉求完全不同。单机几乎不需要编排，一条 redis-server 加配置文件即可，自动化重点在配置模板与进程守护。主从需要自动化建立复制关系、校验复制偏移量、在扩容时把新从节点挂到正确的主上。哨兵需要自动化部署奇数个 Sentinel、统一监控配置、验证仲裁多数派，并确保客户端能感知拓扑变化。Cluster 的自动化最重：节点发现与握手、槽分配、主从配对、在线迁移、故障后槽归属校验，任何一步手工操作都容易留下不一致状态。

# 主从建立复制的关键配置（示例）
# 在从节点 redis.conf 中
replicaof 10.0.1.11 6379
replica-read-only yes
repl-backlog-size 64mb

# 哨兵监控配置（示例，sentinel.conf）
sentinel monitor mymaster 10.0.1.11 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

# Cluster 创建与槽检查（示例）
redis-cli --cluster create 10.0.2.11:6379 10.0.2.12:6379 \
  10.0.2.13:6379 10.0.2.14:6379 10.0.2.15:6379 10.0.2.16:6379 \
  --cluster-replicas 1
redis-cli --cluster check 10.0.2.11:6379

注意哨兵的 quorum 参数（示例中为 2）表示判定客观下线所需的最少 Sentinel 票数，它不等于故障转移所需的多数派票数。故障转移还需要 Sentinel 总数过半的授权，因此 Sentinel 数量必须是奇数且至少 3 个。这是哨兵部署中最容易被忽略的约束。

治理差异与日常关注点

治理层面，四种模式的关注点逐级增加。单机关注内存使用率、慢查询、持久化是否正常；主从额外关注复制延迟（master_repl_offset 与从节点偏移的差值）、全量同步频率、从节点只读是否被误改；哨兵额外关注 Sentinel 之间的通信、主观下线误判、切换后客户端是否及时更新连接；Cluster 则要持续关注槽覆盖是否完整、节点是否全部握手、迁移任务是否卡住、以及 cluster_state 是否为 ok。

选型参考表

实际落地时，很多团队采用混合策略：核心交易缓存用哨兵保证高可用，海量会话或商品缓存用 Cluster 承载容量，离线分析走主从只读副本。选型不是一次性决策，随着数据量与并发增长，从主从演进到哨兵、再演进到 Cluster 是常见路径，关键是每一步都保留可回退的迁移方案与数据校验手段。