容量规划

副标题 / 摘要 纵向扩展更简单但有天花板，横向扩展更弹性但更复杂。本文给出清晰对比与决策路径。 目标读者 负责容量与架构规划的工程师 需要评估扩展策略的团队 做云架构选型的技术负责人 背景 / 动机 系统增长不可避免，选择合适扩展策略决定了成本与风险。 错误的扩展方式会导致性能上限或复杂度爆炸。 核心概念 Scale Up：增加单机资源（CPU/内存/磁盘） Scale Out：增加实例数量 共享瓶颈：数据库、存储、网络 状态管理：无状态易横向扩展 实践指南 / 步骤 判断瓶颈类型（CPU/IO/网络） 评估系统是否无状态 估算成本曲线（单机 vs 多机） 设计数据层扩展策略 准备自动化扩缩容 可运行示例 # 粗略成本模型示意 def cost_scale_up(base, factor): return base * (1 + factor * 1.5) def cost_scale_out(base, n): return base * n if __name__ == "__main__": print(cost_scale_up(100, 2)) print(cost_scale_out(100, 3)) 解释与原理 纵向扩展成本增长通常是非线性的，而横向扩展需要解决一致性、路由、状态同步等复杂度。 常见问题与注意事项 纵向扩展一定更便宜吗？ 小规模可能更便宜，大规模会有成本上限。 横向扩展一定需要分布式系统吗？ 是的，需要处理数据与状态分布。 无状态服务如何实现？ 把状态放到外部存储（DB/缓存）。 最佳实践与建议 早期可先 scale up，后期逐步 scale out 设计无状态服务以便横向扩展 关注数据层瓶颈 小结 / 结论 scale up 更简单，scale out 更有弹性。 选择取决于规模、成本与复杂度承受能力。 ...

副标题 / 摘要 性能关注“当前快不快”，可扩展性关注“增长后还能否保持”。本文拆解两者关系与常见误区。 目标读者 负责性能与扩展性决策的工程师 做容量规划与架构设计的团队 经常被“性能优化”困扰的开发者 背景 / 动机 很多系统在小规模很快，但规模一上来就崩。 因为性能优化和可扩展性是不同维度，需要不同策略。 核心概念 性能：单点/单实例的响应与吞吐 可扩展性：负载增加后系统维持服务能力 瓶颈：CPU / IO / 网络 / 数据库 规模曲线：负载增加时性能曲线是否线性 实践指南 / 步骤 先测基线性能（单机极限） 观察扩展曲线（1x -> 2x -> 4x） 定位瓶颈组件 区分纵向与横向扩展策略 用容量规划指导架构 可运行示例 # 伪负载模型：用简单函数模拟扩展曲线 def capacity(instances, single_qps, overhead=0.1): return instances * single_qps * (1 - overhead) if __name__ == "__main__": for n in [1, 2, 4, 8]: print(n, capacity(n, 1000)) 解释与原理 性能是“单位资源的效率”，可扩展性是“资源增加后效率是否保持”。 如果瓶颈在共享组件（如数据库），扩容应用实例并不会线性提升整体性能。 常见问题与注意事项 性能好就代表可扩展吗？ 不一定，可能只是单点强。 扩展性差就需要重构吗？ 不一定，先定位瓶颈。 缓存能解决扩展性问题吗？ 只能缓解部分读压力。 最佳实践与建议 用压测画出扩展曲线 关注共享瓶颈（DB、锁、网络） 设计可扩展性优先的系统边界 小结 / 结论 性能解决“当前快”，可扩展性解决“增长后还能快”。 两者相关但不等价，必须分别优化。 ...

副标题 / 摘要 缓存大小不是拍脑袋，而是命中率、成本与稳定性之间的平衡。本文给出确定缓存大小的工程方法。 目标读者 负责缓存系统和性能优化的工程师 做容量规划与成本控制的团队 需要提升命中率与稳定性的开发者 背景 / 动机 缓存太小会导致频繁穿透，太大则成本高且失效风险增加。 正确做法是用数据驱动的方式确定缓存大小。 核心概念 命中率（Hit Rate）：缓存命中 / 总请求 工作集（Working Set）：短期内频繁访问的数据集合 淘汰策略：LRU/LFU 等 成本曲线：边际命中率收益逐渐降低 实践指南 / 步骤 采集访问分布（热度、访问频率） 估算工作集大小 用不同容量做离线回放 评估命中率与成本曲线 预留安全余量（波峰期、突发流量） 可运行示例 下面模拟不同缓存容量的命中率： from collections import OrderedDict def lru_hit_rate(requests, capacity): cache = OrderedDict() hits = 0 for key in requests: if key in cache: hits += 1 cache.move_to_end(key) else: if len(cache) >= capacity: cache.popitem(last=False) cache[key] = True return hits / len(requests) if __name__ == "__main__": reqs = [1,2,3,1,2,4,1,2,3,5,1,2,3,4] for cap in [1, 2, 3, 4]: print(cap, lru_hit_rate(reqs, cap)) 解释与原理 缓存大小的收益是递减的：容量越大，新增命中率提升越小。 因此需要找到“边际收益开始下降”的拐点，而不是盲目扩容。 ...