容量规划关键在于识别瓶颈类型和业务阶段，垂直扩展补短板、水平扩展破天花板，二者是演进而非替代关系；需依内存、CPU、磁盘I/O、网络等具体瓶颈选择策略，并分层组合使用。
容量规划解决瓶颈，关键不在“选哪种扩展”，而在于看清瓶颈类型和业务阶段。垂直扩展适合快速补短板，水平扩展用于突破天花板——两者不是替代关系，而是演进关系。
先判断瓶颈在哪
盲目扩容会浪费资源。真实瓶颈常藏在表象之下：
- 内存打满但CPU空闲：Redis或Java应用常见，优先垂直扩展（加RAM）；
- CPU持续超70%且请求排队：可能是单线程瓶颈（如Redis主进程）或计算密集型任务，垂直扩展效果有限，需转向水平分担；
- 磁盘I/O等待高、响应延迟突增：检查是否用了HDD、AOF重写频繁或RDB保存阻塞，升级到NVMe SSD+调优持久化策略可立竿见影；
- 网络带宽跑满、连接数接近系统上限：单机再强也无用，必须水平扩展+接入层分流（如Nginx或云LB）。
垂直扩展：快、稳、有边界
它解决的是“当前节点撑不住”的问题，操作直接，但不能无限延续：
- 给Redis实例加内存是最常用动作，尤其当
used_memory接近物理上限时； - 升级CPU对后台任务（AOF rewrite、RDB save、Lua脚本）有帮助，但不提升主命令吞吐——这点常被误判；
- 云上升级实例规格（如从8GB→32GB内存型）通常5分钟内完成，部分平台支持热升级，业务几乎无感；
- 必须同步调优参数：比如
maxmemory-policy设为allkeys-lru，tcp-keepalive开启防连接中断。
水平扩展：破限、容错、要设计
它不是简单多起几个Redis，而是重构数据与流量的分布逻辑：
- 读多写少场景：用主从复制+Sentinel，读请求打到多个从节点，写仍走主节点；
- 读写都大、数据可分区：上Redis Cluster，16384个slot自动分片，客户端直连，无需代理；
- 微服务间隔离要求高：按业务域拆独立Redis实例（如user-cache、order-cache），比共用集群更易定位和扩缩；
- 注意数据倾斜：热点key（如活动商品ID）会导致某节点负载飙升，需用二级缓存或本地缓存兜底。
组合用才真正扛压
成熟系统往往分层使用两种扩展：
- 单个Redis Cluster分片节点先垂直扩展到32GB内存+NVMe，榨干单节点性能；
- 再通过增加分片数（如从6节点扩到12节点）实现整体容量线性增长；
- 关键业务链路（如登录态）额外部署独立小集群，避免被其他模块拖垮；
- 所有节点前置统一缓存网关（如Twemproxy或Codis），隐藏后端拓扑变化，应用零改造。
容量规划不是一次性动作，而是持续观测→识别瓶颈→小步验证→灰度上线的过程。垂直扩展是起点，水平扩展是归宿，中间那条路，得靠监控指标说话。
