【Redis / 缓存内核】选型与阅读地图：standalone · Sentinel · Cluster · Valkey

十六篇走到这里，问题不应是「Redis 好不好」，而是 你的失效代价、数据结构需求、团队运维半径 落在哪一格。本篇不重复 缓存架构 的五种读写模式全文，也不替代官方托管 SLA；只做 部署形态决策树、生态分叉一句、模块与争论边界，并把读者送回系列内外的下一步。

本文是「Redis / 缓存内核」系列第 16 篇（共 16 篇）。→ 系列目录

版本锚定：Redis OSS 7.4 / 8.x；Valkey 以 Linux Foundation 托管的 OSS 分叉为语境（具体发行版以你方镜像为准）。

一、选型决策树

flowchart TD
  Start["Need in-memory KV?"] --> Q1{"Values rebuildable from DB?"}
  Q1 -->|yes, blob only| MC["Consider Memcached / pure cache"]
  Q1 -->|no or rich types| Q2{"Need structures / Lua / modules?"}
  Q2 -->|yes| RD["Redis family"]
  Q2 -->|no| MC
  RD --> Q3{"Write QPS fits one primary?"}
  Q3 -->|yes| Q4{"Need auto failover?"}
  Q4 -->|no| SA["Standalone + manual DR"]
  Q4 -->|yes| SEN["Sentinel"]
  Q3 -->|no| CL["Cluster"]
  RD --> Q5{"Durability RPO?"}
  Q5 -->|zero loss| AOF["AOF always + WAIT / managed sync"]
  Q5 -->|seconds| MIX["RDB + AOF everysec / hybrid"]
  Q5 -->|cache only| NOP["no persistence"]

二、与 architecture/17 的分工

architecture/17 回答 应用侧 缓存模式（Cache-Aside、击穿雪崩、多级缓存）；本系列回答 服务器内核（事件循环、编码、淘汰、持久化、复制、slot）。衔接关系：

若已读完 architecture/17 而 未 读本系列：建议按 index 推荐阅读路径 补 2 → 8 → 11 → 12 → 13 → 16 最小链。

三、Valkey 与 Redis 生态（一段）

2024 年起，Redis Ltd. 调整 Redis OSS 许可证（RSAL/SSPL 路线，以官方公告为准），Linux Foundation 托管 Valkey 作为 OSS 社区分叉，目标保持 协议与 API 兼容（RESP、主要命令、RDB/AOF 格式在分叉早期仍对齐，具体差异需查各 release note）。对工程团队含义是：客户端驱动、运维脚本、监控指标 大多可复用，但 法务合规、长期 roadmap、企业功能 需分别跟踪 Redis 商业产品与 Valkey 社区版。本篇不展开许可证全文；选型时把 合规审查 与 技术审查 并列，勿假设二者永远字节级一致。

四、模块边界与 Redis Stack

Redis 模块 API 允许在服务器进程内加载 自定义命令与数据类型（JSON、Search、TimeSeries、Bloom 等 Stack 组件）。边界：

模块 不 改变 第 2 篇 的主线程执行默认：重模块仍可能抢占主线程时间，排障时用 INFO modules 与 SLOWLOG 同看。

# 查看已加载模块（名称依安装而定）
redis-cli INFO modules
redis-cli MODULE LIST

五、开放争论（有文献或官方讨论锚点）

1. 多线程执行 vs 多线程 IO：Redis 7/8 持续扩大 IO threads 与部分路径并行；是否与 Memcached 式 多线程命令执行 收敛，社区仍有性能与锁粒度争论（见 Redis release blog，B 级）。工程判断：CPU 饱和前先分清 网络、命令、持久化 谁占主线程。
2. AOF always vs everysec：丢失窗口与 fsync 延迟的交换（第 10–11 篇、fsyncgate）；无 universal 最优，只有 RPO/RTO。
3. 读副本 vs 扩展主库：复制滞后 vs 读己之写（第 12 篇）；PACELC 式延迟—一致性权衡。
4. Redlock 与分布式锁：Martin Kleppmann 批评与 Antirez 回应是经典争论；锁语义 不应默认由单线程 Redis 命令保证，需应用层建模。
5. Cluster vs Proxy：Twemproxy、Envoy、自研 sidecar 在 CROSSSLOT 上的不同拆法；proxy 不自动获得跨槽事务。

六、何时不该用 Redis

与 第 14 篇 互补，明确 退出条件：

• 值永远可重建且只需 get/set → 纯缓存更简单。
• 需要 SQL、JOIN、跨行事务 → 关系库或 HTAP，不是 Redis 主战场。
• 数据量远大于内存、访问以扫描为主 → RocksDB 等磁盘 LSM / 列存路径。
• 强一致多副本写 → 共识数据库（etcd、TiKV），而非默认异步复制 Redis。

七、全系列阅读地图

7.1 本系列 16 篇（按主题）

7.2 站外相邻系列

7.3 三条延伸路径

1. 可靠性深化：11 → fsyncgate → storage/12 数据完整性。
2. 分布式深化：13 → algorithms/11 → distributed 系列（共识与复制对比）。
3. 存储栈下沉：01 → RocksDB index → 磁盘容量与缓存协同。

八、常见误解

九、系列收束

本系列从 事件循环 与 对象编码 出发，经 淘汰 与 持久化，到 复制、Cluster、Memcached 对照 与 排障，构成 Redis 7.4/8.x 内核层 的一条可读路径。更上层的 Cache-Aside 与多级缓存，请回到 architecture/17；更下层的磁盘嵌入 KV，请进入 RocksDB。

三句话小结：

1. Standalone / Sentinel / Cluster 按写扩展、failover、slot 复杂度递增；纯 blob Cache-Aside 仍应认真考虑 Memcached。
2. Valkey 是许可证驱动下的 OSS 分叉路线，技术上短期接近 Redis，合规与 roadmap 需独立跟踪；模块 扩展命令但不改变单进程故障域与主线程代价模型。
3. 全系列 16 篇与 architecture/17、RocksDB、算法篇形成 应用—内存服务器—磁盘存储 三角；按本篇地图选下一条边即可。

参考资料

文档（A 级）

1. Redis Documentation, High availability、Cluster tutorial、Sentinel、Modules API。
2. Redis OSS 7.4 redis.conf 与 release notes（IO threads、许可证变更前的 OSS 行为）。

辅助（B 级）

3. Linux Foundation, Valkey project announcements（分叉动机与兼容声明）。
4. Kleppmann, M., How to do distributed locking（与 Redlock 争论）；Antirez 回应文（B 级博客）。
5. 系列 index、PLAN.md（规划文档，非发布页）。

返回 系列目录 ｜ 上一篇：生产排障 ｜ 缓存架构 ｜ RocksDB