按峰值预留容量的资源浪费：Redis集群从"一开始就撑住15万QPS"到按需自动扩容

容器化之前，业务方申请Redis容量的方式是提前报出一个预估的峰值QPS（比如15万QPS），运维团队据此按照Redis Cluster的性能曲线，提前开好足够多的实例来撑住这个预估峰值。但真实运行情况和预估之间往往存在巨大落差：即便是跨年演唱会这样公司全年最高峰的流量场景，真实峰值也没有超过9万QPS，这意味着大多数按15万QPS预留的Redis实例，在绝大部分时间里都处于闲置浪费的状态——业务方为了留出安全余量，天然倾向于把预估值报得偏高，而这份”安全余量”最终变成了系统性的资源浪费，且这种浪费很难在容器化之前被直观地衡量出来。容器化之后，团队采取的策略是不再一开始就按峰值预估配置足够撑住全部预估流量的集群，而是先给一个基础性能的集群，配合自动扩容机制，让集群规模跟随真实的实时负载动态伸缩，满足业务实际需求即可；被这种方式释放出来的多余资源，可以被重新分配给其他真正需要的业务使用。这个案例给出了一条容量规划的重要经验：容量规划领域普遍存在业务方”报高不报低”的天然倾向（多申请一些总比申请不够导致故障要安全），如果基础设施只能支持”一次性预留、事后很难调整”这种静态分配模式，这种倾向必然会系统性地放大整体资源浪费；而只有当基础设施真正具备了低成本、快速的动态扩缩容能力时，才能把资源分配的策略从”提前预留应对最坏情况”转变为”按需实时匹配真实负载”，从根本上化解”报高不报低”这个倾向带来的浪费问题，而不是靠事后审计或者要求业务方”精确预估”这种治标不治本的办法。