标签频道
缓存
该标签下的文章、提问与讨论帖。
一、背景与问题 现象 - RUM 显示 98% 请求 FCP<1.2s，但 CDN 日志显示 3.2% 请求回源耗时>2s - 拨测节点显示「缓存命中率 97%」，但故障时拨测永远显示 200 - 错误监控显示「资源加载失败率 0.5%」，
背景 我们使用 CloudFront+Lambda@Edge 架构，发现前端监控数据与 CDN 日志存在系统性偏差： - RUM 显示 98% 请求 FCP<1.2s，但 CDN 日志显示 3.2% 请求回源耗时>2s - 拨测节点显示「缓
背景 我们使用CloudFront+Lambda@Edge架构，发现前端监控数据与CDN日志存在系统性偏差： - RUM显示98%请求FCP<1.2s，但CDN日志显示3.2%请求回源耗时>2s - 拨测节点显示「缓存命中率97%」，但故障
【背景】 去年我负责一个 2000 万行的订单流水表（MySQL 8.0，InnoDB），一条报表查询 "SELECT ... WHERE tenant_id=? AND status IN (?,?) AND created_at > ?
【背景】 做了 15 年 SRE，我见过太多这样的场景：线上 P99 从 80ms 抖到 400ms，告警一响，值班同学的肌肉记忆就是——「加个缓存吧」。Redis 一上，TTL 给 10 秒，P99 曲线确实好看了一周。 直到某个大促前夜
【背景】 做性能优化 8 年，复盘过不少「指标降了、大家鼓掌、三个月后又炸」的案子。最典型的一次：一个商品详情接口 P99 从 180ms 超 SLO（100ms），我第一反应是加 Caffeine 本地缓存。加完 P99 直接落到 30m
【背景】 我在一家做电商后端的公司待了十几年，见过同一个「读多写少」接口，三个团队三种做法，最后各自踩坑： - A 组：核心商品详情走本地缓存（Caffeine，TTL 10s + 变更消息失效），P99 稳定在 8ms，但去年一次商品中心
【背景】 做了 8 年性能优化，我越来越觉得一个尴尬的事实：「把接口做快」和「证明它真的变快了」是两件完全不同的事。前者靠工程直觉，后者靠统计学，而大多数团队（包括我早期的团队）只有前者。 最近复盘了三个「优化后翻车」的真实案例，根因都不是
背景 社区里前端可观测性已经聊了不少层：#28 讲错误监控的落地路径、#121 聊采样 vs 全量的成本权衡、#431 聊稳定性投入的最低水位、#750 聊 RUM 还是合成拨测当主信号。但我发现一个被反复绕过去的工程细节——CDN 缓存状
背景 社区里已经有一篇讲「慢查询治理三件套顺序」的文章，把「先定位 → 再判断 → 最后加索引/改写」讲得很清楚，我基本认同。但真正到动手那一刻，我发现团队里吵得最凶的其实不是「顺序」，而是同一类慢查询，到底用哪条路去解：加索引、改写 SQ
文
标题
摘要