性能调优与缓存 入门教程
所属主题：Claude 提示词工程完全指南
性能调优与缓存 入门教程 是一套面向开发者和运维人员的系统性实践指南，其核心在于：识别系统瓶颈、选择合适的缓存策略（本地缓存、分布式缓存、HTTP 缓存等）、结合数据库优化与代码优雅化，将响应时间从秒级降至毫秒级。但这绝非一次性操作，而是一个可重复的发现-诊断-压测-调优闭环。新手最常见的误区包括：跳过基线度量、直接照搬线上配置、在不理解缓存失效原理的情况下盲目加缓存。
开始之前
在介入任何调优工作前，务必确认以下基础条件。跳过任一项都可能导致后续步骤无法复现，甚至产生负面效果。
你需要准备
- 可观测性基础设施：至少具备应用性能监控（APM，如 SkyWalking、Jaeger）和基础指标采集（CPU、内存、I/O、网络）。没有度量，就没有调优方向。
- 压测工具：简单场景可用
ab（Apache Bench）或wrk，复杂场景选择JMeter或Locust。手动点浏览器不能算作压测。 - 版本与环境快照：记录当前应用版本、依赖库版本、中间件版本及配置文件的完整快照。调优前后比对时，版本差异往往是问题的根源。
- 回滚方案：明白“怎么改回来”比“怎么改”更重要。建议将所有修改纳入版本控制（如 Git），或至少在修改配置文件前进行备份。
何时停止并另寻他路
如果系统已经频繁出现 OOM、CPU 持续 95% 以上且无法通过垂直扩容解决，或者业务负载模式极端不规则（如瞬间流量峰值达到均值的 1000 倍以上），那么纯缓存调优的作用空间有限。此时应优先考虑架构层面的调整，例如服务拆分、异步化、限流降级等。
步骤清单
以下是经过验证的核心执行步骤。建议严格按序号顺序执行，不要跳跃。
| 步骤 | 行动 | 关键检查点 | 常见耗时 |
|---|---|---|---|
| 1 | 建立性能基线（响应时间、吞吐量、错误率） | 采样时间 >= 15 分钟，避开业务低峰尖刺 | 2–3 小时 |
| 2 | 定位瓶颈层（CPU-bound、IO-bound、锁竞争、网络） | 使用火焰图或 tracing 确认热点 | 1–2 小时 |
| 3 | 选择缓存维度与层级（本地 vs 分布式 vs CDN） | 数据一致性要求、平均数据大小、访问频率 | 1 小时 |
| 4 | 实施缓存（设置过期策略、序列化方式、缓存键设计） | 测试缓存命中率 >= 80%，检查缓存穿透与雪崩 | 2–4 小时 |
| 5 | 数据库级调优（索引、慢查询、连接池） | 慢查询日志清零或显著下降 | 2–3 小时 |
| 6 | 代码级微调（循环内重复调用、序列化开销、对象创建） | 单次请求分配的内存下降 | 1–2 小时 |
| 7 | 压测验证与回归 | 在基线相同环境下重跑压测，对比关键分位数（P95/P99） | 1 小时 |
详细操作说明
步骤一：建立基线
用空跑或稳定负载压测，记录以下三个核心指标：
- 平均响应时间（ms）
- 吞吐量（每秒请求数，RPS）
- 错误率（%）
示例：假设一台 4C8G 的 Web 服务器，在 200 并发下，基线数据为：平均响应 1500ms，RPS 133，错误率 0.2%。这个 RPS 等于 200 / 1.5，这是一个合理的计算验证。
边界提醒：基线数据不是一次性获得的。系统在低负载和高负载下的表现可能截然不同（锁竞争、连接池耗尽、GC 都会导致响应时间出现锯齿形波动）。建议至少运行两次压测，分别对应低负载（50% 预期峰值）和高负载（100% 预期峰值）。
步骤二：定位瓶颈
使用火焰图（Flame Graph）或基于采样的 Profiler（如 async-profiler、pprof）。
- 如果火焰图的大部分宽度集中在
system或内核调用，说明问题出在 IO-bound 或锁竞争。 - 如果集中在业务代码的少数几个方法上，检查这些方法是否在执行重复数据库查询或大对象序列化。
典型例子：一个用户详情接口每次请求都查询四次数据库（用户基础信息、地址、角色、订单），但四个表之间没有事务依赖。这种情况下，一次缓存读取完全可以替代四次查询，前提是业务允许数据有短暂滞后。
步骤三：选择缓存策略
从三个维度进行考量：
| 维度 | 本地缓存（Caffeine/Guava） | 分布式缓存（Redis） | HTTP 缓存/CDN |
|---|---|---|---|
| 数据量 | < 10GB | 任意 | 静态文件 |
| 一致性要求 | 弱，容忍节点间不一致 | 强，通过主从或集群保证 | 强，CDN 失效可精确控制 |
| 访问延迟 | < 1ms | 1–5ms | 取决于网络 |
| 适用场景 | 字典表、配置、低频变动数据 | 用户会话、商品详情、计数器 | 图片、CSS/JS、API 响应 |
新手最容易卡在哪里：在本地缓存与分布式缓存之间做出错误选择。一个常见案例是，把动态的商品价格数据缓存在本地 Caffeine 中，导致不同节点返回的价格不一致，引发价格争议。这类场景应该使用 Redis 并配合 TTL 机制。
步骤四：缓存实施细节
缓存键设计：
不要直接用 SQL 语句或完整 URL 作为键；应使用业务含义明确的组合。例如 product:price:12345 优于 product_12345_price_20260627。
过期策略：
- TTL（Time To Live）：最常用。注意设置随机偏移量（如 TTL + random(0, 60s)）以避免缓存雪崩。
- LRU（Least Recently Used）：适合本地缓存，当容量满时淘汰最久未使用的条目。
- W-TinyLFU：Caffeine 使用的策略，比 LRU 更能抵御突发流量。
序列化：
尽量不要使用 Java 原生序列化。采用 Protobuf 或 Kryo 比 Jackson 快 3–5 倍，内存占用也更小。对于 Redis，String 类型的 value 建议序列化为二进制字节数组，而非 JSON 字符串。
命中率预期：
如果缓存命中率低于 60%，说明缓存设计存在缺陷（要么 TTL 过短，要么缓存的是不常访问的数据）。此时应优先检查访问模式，而不是盲目增大缓存容量。
步骤五：数据库调优
很多时候，缓存只对重复查询有效。如果每分钟有 5 万次完全不同的查询，缓存无法完全覆盖。这时必须审视索引。
慢查询日志分析：
- 开启 MySQL 慢查询日志（
long_query_time = 0.5），观察rows_examined是否远大于rows_sent。 - 使用
EXPLAIN确认索引使用情况。type = ALL表示全表扫描。 - 连接池大小建议公式：
（core_count * 2） + effective_spindle_count，而不是随意设为 200。
边界案例：一个包含 5000 万行的订单表，即使加了索引，如果查询条件使用了函数包裹索引列（如 WHERE DATE(order_time) = '2026-06-27'），索引也会失效。这属于 SQL 写法问题，不是缓存能解决的。
步骤六：代码级微调
这一步骤最容易被忽略，但往往能带来意想不到的收获。
- 循环内重复调用：循环 100 次内每次都调用一次
new SimpleDateFormat()，可改为类静态变量或使用DateTimeFormatter。 - 序列化开销：gRPC/Thrift 调用序列化对象如果包含 50 个字段但实际只用 3 个，考虑使用 DTO 精简。
- 对象创建：高频路径上避免匿名类和 Lambda 捕获外部变量，这会导致每次生成新的字节码对象。
具体例子：一个每秒钟被调用 1000 次的接口，内部每次都会创建一个 Map 并填充 10 个 KV。改用 ImmutableMap 或静态初始化，可以消除 GC 压力，P99 降低 15ms。
步骤七：验证与回归
在与基线完全相同的环境（同样的机器规格、同样的并发量、同样的数据量）下重新运行压测。
- 平均响应时间应下降 40% 以上才算有效调优。
- P99 响应时间不应出现异常尖刺（如果出现，说明缓存逐出或 GC 抖动）。
- 错误率不能上升。如果错误率上升，立即回滚最后一次变更。
常见错误与排查
错误一：跳过前提条件，直接改配置
很多人拿到 Redis 配置就直接将 maxmemory