扩容两条路：先把单机榨干，再谈横向
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 1 · 接入层扩展 · 第 4/49 篇 · 🚧 占位待学
上一篇：《亿级消息解剖：吞吐、堆积与存储三笔账》
下一篇：《负载均衡：四层与七层、算法与副作用》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 1 · 单元 1.1
一、本文要解决的问题
QPS 上不去了，第一反应就是加机器？很多情况下先把一台机器用好更便宜。更重要的是：横向扩展有个隐藏前提——应用必须无状态，而有状态改造（session 外置、本地缓存、定时任务）不做完，加机器只会加出数据不一致。
二、知识点清单
- 垂直扩展（换更强的机器）vs 水平扩展（加更多的机器）：成本曲线与适用边界
- 单机瓶颈定位四件套：CPU、内存、磁盘 IO、网络，及 top / iostat / sar 的看法
- 应用层调优三板斧：线程池参数、数据库连接池、JVM 堆与 GC（深挖见性能调优系列）
- 无状态改造三件事：session 外置（Redis）、本地缓存清理、定时任务抽离（调度中心）
- CAP 视角：水平扩展后，原来进程内的一致性（锁、缓存）必须外移
三、动手实验（学习时必须真跑）
- 写一个带 MySQL 查询的接口，默认 Tomcat 200 线程 / 连接池 10，wrk 压出基线 QPS
- 只调连接池（10 → 50）再压，观察 QPS 与 RT 变化；继续加线程池对比，找到边际收益归零点
- 写一个带 session 的接口，直接起两个实例挂到 Nginx 后面，复现登录态错乱；session 外置 Redis 后修复
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。