说明：本文由早期存档重新编写。旧正文及旧图片已移除，以下内容为重新整理后的独立版本。
高可用 Redis 平台不能用一个巨大 QPS 数字概括，容量、延迟和故障恢复同样重要。
重新整理后的要点
- 根据数据结构、命令复杂度和热点分布进行压测。
- 选择复制、哨兵或集群前先明确可接受的数据丢失和恢复时间。
- 验证扩缩容、节点故障、备份恢复和客户端行为。
我的处理原则
这类问题需要结合业务规模、版本、预算和风险承受能力判断。本文保留的是可复核的思考框架；涉及具体实施时，应先在测试环境验证，并记录变更与回退方案。