性能与成本优化：从缓存分层到资源治理的实战路径

定义核心指标（用户可感知的）：
□ 首屏延迟（TTFB / LCP）：时间线刷新
□ 交互延迟：点赞/关注/发帖的完成时间
□ 吞吐：QPS 峰值与均值
□ 错误率：5xx / 超时比例

设定 SLO（服务等级目标）：
□ 时间线读取 P99 < 300ms
□ 发布动作 P99 < 1s
□ 错误率 < 0.1%
□ 缓存命中率 > 95%（读路径）

度量与看板：
□ 全链路追踪（trace）+ 指标（metric）
□ 关键路径拆解：网络 → 网关 → 服务 → 缓存 → DB

优化排序原则：
□ 先看「读路径」，读 QPS 远高于写
□ 先打「最慢的 1%」：P99 才是体验，不是平均值
□ 每次优化后复测基线，确认收益

分层结构：
L1（应用内/进程缓存）：本地内存，微秒级
  → 适合：高频只读、近不变数据（配置、热榜快照）
  → 问题：多实例不一致，需短 TTL 兜底

L2（Redis/分布式缓存）：毫秒级，跨实例共享
  → 适合：时间线、计数、用户会话
  → 问题：网络往返，比 L1 慢

DB（最终一致）：命中缓存失败才查库

缓存一致性：
□ Cache Aside（旁路）：读先查缓存，miss 查库回填；写先更库再删缓存
□ 删除而非更新缓存：避免「更新缓存与写库的竞态」
□ 热点 key：永不过期 + 逻辑过期 + 后台重建（防缓存击穿）

防穿透/雪崩：
□ 穿透：空结果也缓存（短 TTL）
□ 雪崩：缓存 TTL 加随机抖动，避免同时过期

热点场景 1：大 V 时间线
  大 V 发帖 → 上千万粉丝刷新 → 读放大爆炸
  治理：大 V 内容独立缓存 + 粉丝刷新走缓存时间线

热点场景 2：计数热点
  大 V 的粉丝数/点赞数 → 单行超高并发更新
  治理：计数分片（多桶）→ 合并读；异步计数落库

热点场景 3：热门内容
  爆款内容被同时访问 → 单行读热点
  治理：内容缓存 + 多副本读取

热点检测：
□ 慢查询日志 → 定位高频慢 SQL
□ 缓存 key 热度统计 → 找热 key
□ 数据库连接池等待 → 找争抢点

大 V 时间线治理示例：
大 V 发帖 → 写一个「大 V 新帖」缓存（TTL 短）
粉丝刷新 → 先拼「自己关注的大 V 新帖」→ 命中率高
  → 避免每次刷新都全量扫描大 V 的旧内容

内存分析：
□ bigkey：超大 key（如整个时间线塞一个 key）→ 拆分/分片
□ 过期 key：无 TTL 的 key 是「内存泄漏」→ 设置 TTL
□ 淘汰策略：maxmemory-policy（allkeys-lru 常见）

压缩与优化：
□ 小对象合并：strings 合并为 hash 字段（省内存）
□ 整数编码：能用 int 别用 string
□ 序列化：JSON → 更紧凑的编码（MessagePack/自定义）

成本治理：
□ 缓存保留时长：只缓存「高访问频率」的数据
□ 降级：低频数据直接查库，不占缓存
□ 容量规划：按「命中率 × 数据规模」估算，别无限缓存

内存估算：
缓存价值 = 该数据被访问的频率 × 避免的 DB 开销
→ 低频数据缓存 = 纯浪费 → 让它查库

存储侧优化：
□ 多尺寸缩略图：上传即生成，避免客户端放大缩小
□ 格式升级：WebP/AVIF 比 JPEG 小 30-50%
□ 压缩参数：质量 70-80 足够（人眼几乎无差）

CDN 侧优化：
□ 缓存命中率：静态图片缓存长 TTL（Cache-Control 长）
□ 分级缓存：边缘 → 区域 → 源站
□ 缓存失效：上传新图用新 URL（内容寻址，避免覆盖失效）

带宽治理：
□ 懒加载（见内容管线篇）
□ 视频走低清预转码 + 流式
□ 原图保护：默认只给缩略图，原图点击才取

成本公式：
图片带宽成本 ≈ 请求数 × 单图大小 × (1 - CDN 命中率)
→ 缩略图 + WebP + 高命中 = 三个最大的杠杆

数据分层（按访问频率）：
□ 热：Redis / SSD（在线库）→ 高访问
□ 温：对象存储（标准）→ 偶尔访问
□ 冷：对象存储（低频/归档）→ 极少访问

归档对象：
□ 老内容（超过 N 个月）→ 归档表/对象存储
□ 日志：详细日志 → 对象存储（低成本），热日志 → 在线
□ 计数历史：趋势数据归档

归档体验：
□ 在线库保留索引行（post_id → 归档位置）
□ 访问老内容 → 点击「加载更多/重新加载」从归档取
□ 归档检索：可接受的秒级延迟

降本对比（量级直觉）：
在线 SSD 1TB 成本 ≈ 归档存储 10-20TB
→ 把 80% 的「永不访问」数据归档，成本立降一个数量级

监控三件套：
□ 指标（Metric）：QPS、延迟、错误率、命中率、内存/CPU
□ 日志（Log）：错误日志、慢日志、风控日志
□ 追踪（Trace）：请求全链路耗时拆解

告警分层：
□ 业务告警：错误率、SLO 违约、积压
□ 资源告警：CPU/内存/磁盘/带宽水位
□ 成本告警：云账单异常增长、CDN 流量突增

容量规划：
□ 峰值容量：按「业务峰值 QPS × 单机能力」算节点数
□ 增长预留：按月度增长斜率预留缓冲
□ 弹性：读服务支持横向扩容（无状态），缓存按容量扩

容量公式（读服务）：
节点数 = 峰值QPS / (单机QPS能力 × 冗余系数)
冗余系数 = 1.5~2（留故障余量 + 突增缓冲）

取舍框架：
□ 先保 SLO：P99 不违约是第一优先级
□ 再控成本：在「满足 SLO 的前提下」最小化成本
□ 分级投入：核心路径（时间线/发布）重投入，长尾路径轻投入

常见取舍决策：
□ 缓存：命中率 < 某阈值 → 撤缓存（省内存，SLO 仍达标）
□ 图片：质量 80 → 70（省带宽，视觉影响可接受）
□ 归档：老内容进冷存储（省成本，体验降级可控）
□ 冗余：读服务从 3 副本 → 2 副本（省成本，容错降级可接受）

量化每一步：
□ 每项优化都要「省了多少钱/降了多少延迟」的量化
□ 没有量化的取舍 = 拍脑袋

决策记录（例）：
图片质量 80→70：带宽成本 -18%，视觉 PSNR 下降 <1%，用户投诉 0
  → 执行。回滚条件：投诉率 > 0.5%

现状：时间线读取 P99 = 900ms，DB 打满，缓存命中率 60%

优化步骤：
1. 缓存分层改造
   L1（本地）缓存「大 V 新帖」+ L2（Redis）缓存时间线
   → 命中率 60% → 90%，P99 900ms → 350ms

2. 热点治理
   大 V 计数分片 + 内容多副本读取
   → 数据库 QPS 下降 40%，无热点争抢

3. 图片优化
   全量 WebP + 多尺寸缩略图 + CDN 命中率 95%+
   → 带宽成本 -45%

4. 冷数据归档
   6 个月以上内容进对象存储归档
   → 在线库瘦身 70%，存储成本 -60%

5. 容量复盘
   按「峰值 QPS × 单机 × 冗余」重算节点数，撤 20% 冗余
   → 成本 -15%，SLO 保持

结果：P99 900ms → 180ms，总成本 -60%，SLO 达标
每一步都有量化 + 可回滚