Redis 扩容先做最小方案，再谈复杂架构
后端架构先看边界和失败路径，再看吞吐数字。这篇只讨论一个问题：Redis 扩容先做最小方案，再谈复杂架构。
写作边界：围绕“Redis 扩容先做最小方案，再谈复杂架构”出现的数字、事故场景和性能结果均用于演示分析方法，不是特定项目的实测结论。落地时请记录版本、输入、资源、统计窗口和失败路径，再用自己的测试数据复核。
扩容信号来自容量，不来自阶段编号
最小方案可以是主从加 Sentinel，但是否够用取决于数据量、写入比例、恢复时间目标和允许的数据丢失范围。本地缓存能减轻热点读取，也会引入一致性与失效问题，需要单独评估。
读压力先到瓶颈时，可增加副本并检查客户端读策略；写入、内存或故障域成为瓶颈时，再评估 Cluster。单节点多少内存需要迁移没有通用答案，关键是 fork、持久化、复制和故障转移是否仍能在目标时间内完成。
迁移前先盘点大 Key、热点 Key、Lua 脚本和多 Key 操作。Redis-Shake 等工具能搬数据，不能自动解决跨 Slot 语义。先在副本数据上演练校验与回滚，再安排正式切换。
落地检查
- 固定“Redis 扩容先做最小方案，再谈复杂架构”涉及的输入、版本、流量模型与统计窗口，再比较变更前后。
- 对自动化动作设置权限、超时和熔断；失败时回到可解释的确定性路径。
- 把结论连同原始日志、指标截图和回滚条件一起归档，避免只留下口头判断。
