高性能攻略：从容量规划到「缓存+异步+分布式」三板斧
面向一线开发与准架构师，用轻松聊天式博客整理高并发/高性能构建方法：认清指标 → 建流程 → 选方案 → 做妥协 → 面试套路。
1. 什么叫「高并发 / 高性能」？
- TPS/QPS 不是越高越好吹：天猫 54.4 万 TPS 是真实峰值；eBay “百万” TPS 只是压测某子系统；区块链秒算百万其实平均下来 2000 TPS。
- 决定 TPS 的两个因子：并发连接数、响应时间（还要减掉客户端思考时间 Think Time）。
- 规模 vs 能力：
- 千万注册 / 百万日活的电商 → 峰值并发几万到几十万。
- 大厂平峰：TPS 几万、QPS 数十万；大促可到数十万 TPS、数百万 QPS。
- 四类关键指标：
- 交易类：TPS/QPS + 响应延时 + 错误率。
- 流媒体类：吞吐量（大 B/s）+ 滞后时间。
- 系统资源：CPU、内存、磁盘 IO、网络带宽拐点。
- 体验：是否满足用户对 1s 内响应的心理预期。
2. 流程：容量规划是第一性原理
2.1 设目标
- UV/PV、Session、峰值并发、TPS/QPS、延迟、错误率、水位线（CPU/内存/磁盘/网络）。
2.2 规划方法
- 建基线 → 定不同场景（平峰、节假日、秒杀） → 形成水位图 → 规划短期/长期资源。
2.3 执行闭环
- 压测
- 负载测试：常态高值，验证 99.9% 场景是否稳定。
- 压力测试：冲拐点，找到崩溃边界，调整参数继续冲。
- 七个关键词：历史基线、准生产环境、真实数据集、自动化、统计分析、报告入库、持续迭代。
- 监控（APM）
- 衣带渐宽：Prometheus/时序指标 + 告警。
- 为伊憔悴：全链路追踪（TraceID/SpanID）。
- 蓦然回首：业务关联告警，一条消息串起磁盘→系统→应用→业务。
- 预测
- 根据压测 + 实际监控，预判何时触顶，提前调优或扩容。
2.4 云时代：弹性扩缩容
- 监控眼睛（APM）+ 决策大脑（Auto Scale 策略）+ 行动之手（增资源/启容器/调路由）。
- 弹性让「容量规划」从精确算服务器，变成「算阈值 + 写策略」。
3. 三板斧：缓存为王，异步为帅，分布式为将
3.1 缓存为王（读 10~100x 写）
- 网络层缓存
- 浏览器缓存：Cache-Control、ETag、LocalStorage。
- CDN：内容分发网络（阿里云/Akamai），让静态资源就近命中。
- 反向代理缓存：Nginx/OpenResty/Squid，承接动态内容。
- 应用层缓存
- 本地内存缓存（堆内/堆外、Ehcache/Terracotta）。
- 数据层缓存
- 集中式 KV（Redis/Memcached/Couchbase），承载 Session、热点数据。
命中顺序：浏览器 → CDN → 反向代理 → 应用本地 → 分布式缓存 → 数据库。能往前挪就往前挪。
3.2 异步为帅
- 把同步等待改成排队：邮箱验证码、风控通知、库存同步都可消息化。
- 应用层异步：Ajax + WebFlux + WebClient；后台减少响应阻塞。
- 系统层异步：消息队列（Kafka/RabbitMQ/ActiveMQ/Redis PubSub）、ESB、事件总线。
- 收益：
- 减延时（直接提升 TPS/QPS）。
- 服务解耦（Y 轴更好拆）。
- 销峰填谷（队列像银行取号机）。
- 成本：一致性延迟、业务需接受「时间换空间」。
3.3 分布式为将
- X 轴：复制/多副本/横向扩节点（K8s、Auto Scaling、读写分离）。
- Y 轴: 微服务拆分、领域界限清晰，配熔断、限流、降级。
- Z 轴：按用户/产品/地域分片，降低延迟、支持有状态。
- 数据库：
- X：CDC、一写多读、NoSQL 多副本。
- Y：分库分表配合微服务。
- Z：ShardingSphere/MyCAT、Spanner/GaussDB 原生分片、NoSQL chunk。
4. 妥协策略：资源烧不起怎么办？
4.1 外部排队（用户体验折价换稳定）
- 图形验证码 + 行为验证：先挡掉脚本、顺便拉长时间轴。
- 排队系统：
- DNS 切到排队域名 → 控制 token → 才放行到主站。
- 或保持 CDN 域名不变，CDN→排队系统→再回源，按 token 控流。
- 场景：中小电商两周内上线秒杀，大幅提升能撑的并发，但用户需要等几分钟。
4.2 内部限流
- 漏桶（Leaky Bucket）：恒定出水速，平抑突发。
- 令牌桶（Token Bucket）：按速率发令牌，没令牌就拒绝或排队。
- 处理方式：Gateway/Spring Cloud/SService Mesh/消息队列都能实现。
4.3 熔断 / 降级：丢卒保车
- 熔断：高错误率/高延迟服务直接断开（评论系统崩了，不影响下单）。
- 降级：主动关闭非核心功能，集中资源给主链路（关评论、缩轮播、禁图只留文字）。
- 老鼠仓策略：主动“偷”非关键服务的 CPU/内存给支付/下单。
5. 实战案例：某跨境电商的性能翻身
| 阶段 | 动作 | 指标 |
|---|---|---|
| 初版 | 单体 + 几百 TPS，几千 QPS | 秒杀需求顶不住 |
| 方案一 | CDN（Akamai）、OpenResty 反代、Ehcache/Terracotta、Couchbase | TPS 升到数百，QPS 数万 |
| 方案二 | Kafka + ActiveMQ（异步 + 订单一致）、Solr/Hadoop（读写拆分） | 进一步提升吞吐 |
| 秒杀需求（2 周交付） | 行为校验 + 外部排队系统（令牌控制） | 支撑几十万用户排队完成下单，系统不爆 |
经验：真想线性提升靠时间堆栈、资源烧钱；快交付就得用排队+限流+降级组合拳。
6. 面试问什么？怎么答？
- 聊聊分布式 / 高并发 / 多线程的区别？
- 分布式是扩展手段，高并发是目标，多线程是单机调度手段。
- 加分：结合实战讲线程池策略（CPU 密集 N+1，IO 密集 2N）。
- 如何做高性能 + 高可用的反向代理？
- 缓存策略（静态、API、失效控制），多层回源。
- 高可用：前置 LVS/F5 + Keepalived，或多 Nginx 主备心跳。
- 加分：列参数调优/缓存粒度/日志落盘策略。
- 异步通讯如何提升网站性能？
- 先说 NIO → MQ → Pub/Sub/P2P，再给 Netty/WebFlux/Kafka/RabbitMQ/Redis 实战。
- 重点：减少等待+解耦+削峰；同时说明一致性与补偿策略。
QQ 讨论题
- 拿自己系统：用缓存/异步/分布式组合再提一档 TPS/QPS。
- 分享一次「资源有限」下采取的妥协策略（排队/限流/降级）及效果。
7. 小抄
- 「先流程再方案」：容量规划永远放在技术之前。
- 「缓存优先」：能往前挪就往前挪，先网络再应用再对象。
- 「异步要敢妥协」：明确哪些业务可以“时间换空间”。
- 「分布式不是银弹」：拆服务前先想组织/流程是否跟得上。
- 「妥协方案要准备」：排队、限流、熔断、降级都是救命稻草。
- 「面试多讲实战」：数据来源、压测方式、参数调优，越具体越有说服力。
下一章我们继续聊「高可用」，把性能和可用性拼成完整的质量保障闭环。敬请期待。
