极简架构在内容平台中的复盘读写分离与缓存策略的实践经验一、内容平台的读多写少特性一个技术博客平台日均PV约50万。数据分析显示读写比例为97:3——97%的请求是读取文章、列表、搜索只有3%是发布、编辑、评论。这种极端的读多写少模式下传统的对称架构读和写使用同样的数据库实例浪费资源。优化方向很明确读写分离 多级缓存——让读请求不经过主库。二、三级缓存的架构设计第一级CDN边缘缓存命中率约45%静态文章HTML页面缓存在CDN节点上。文章发布时主动预热CDN缓存读者访问时直接从最近的CDN节点返回。# CDN配置 location /article/ { proxy_cache article_cache; proxy_cache_valid 200 1h; # 缓存1小时 proxy_cache_bypass $arg_nocache; # ?nocache1绕过缓存 proxy_cache_key $host$uri; # 文章更新时通过API主动清除缓存 proxy_cache_purge $purge_method; }第二级Redis应用缓存命中率约40%CDN miss的请求到达应用层先查Redisfunc (s *ArticleService) GetArticle(ctx context.Context, id string) (*Article, error) { cacheKey : fmt.Sprintf(article:%s, id) // 1. 查Redis cached, err : s.redis.Get(ctx, cacheKey).Result() if err nil { var article Article json.Unmarshal([]byte(cached), article) return article, nil } // 2. Cache miss → 查只读副本 article, err : s.readDB.GetArticle(ctx, id) if err ! nil { return nil, err } // 3. 回写缓存——异步不影响响应 go func() { data, _ : json.Marshal(article) s.redis.Set(ctx, cacheKey, data, 30*time.Minute) }() return article, nil }第三级PostgreSQL只读副本命中率约15%CDN和Redis都miss的请求最终到达数据库只读副本。主库和只读副本之间通过WALWrite-Ahead Log复制延迟通常10ms。-- 只读副本的查询优化 -- 使用物化视图预计算热门文章 CREATE MATERIALIZED VIEW hot_articles AS SELECT id, title, author, views, created_at FROM articles WHERE created_at NOW() - INTERVAL 7 days ORDER BY views DESC LIMIT 50; -- 每5分钟刷新 CREATE EXTENSION pg_cron; SELECT cron.schedule(refresh-hot-articles, */5 * * * *, REFRESH MATERIALIZED VIEW CONCURRENTLY hot_articles);三、缓存失效策略——最复杂的部分缓存的难点不是怎么存而是什么时候失效。更新了一篇文章后需要失效至少3层缓存func (s *ArticleService) UpdateArticle(ctx context.Context, id string, content string) error { // 1. 写主库 if err : s.writeDB.UpdateArticle(ctx, id, content); err ! nil { return err } // 2. 主动失效缓存而非等待TTL过期 // Redis s.redis.Del(ctx, fmt.Sprintf(article:%s, id)) s.redis.Del(ctx, articles:list:*) // 列表缓存全失效 s.redis.Del(ctx, fmt.Sprintf(author:%s:*, authorID)) // 作者文章列表 // CDN——发送清除请求 s.cdn.Purge(fmt.Sprintf(/article/%s, id)) s.cdn.Purge(/) // 首页 // 3. 预热新缓存可选对于热门文章 go s.warmUpCache(ctx, id) return nil }缓存更新策略对比策略优点缺点适用场景TTL过期简单不一致窗口TTL可容忍短时不一致主动失效一致性好实现复杂银行、订单等强一致性写穿(Write-through)缓存始终最新写操作变慢读多写少写回(Write-back)写操作快宕机丢数据允许少量数据丢失当前采用的是主动失效 TTL兜底的组合——更新时主动失效缓存加上Redis的30分钟TTL作为兜底。四、缓存的隐藏成本内存成本Redis缓存了约5万篇文章占用约800MB内存。按云Redis的$0.04/GB·h计费月费约$230。但避免了约80%的数据库查询数据库从4C16G降为2C8G节省约$280/月。不一致窗口主库写入到只读副本同步延迟约10ms。在这个窗口内用户可能读到旧数据。解决方案对于发表后立即查看的场景使用读自己的写策略——作者查看自己的文章时读主库而非副本。缓存击穿一篇热门文章缓存到期时同一时刻可能有100请求穿透到数据库。解决方案互斥锁——只有第一个请求去查库其余等待。func (s *ArticleService) GetArticleWithMutex(ctx context.Context, id string) (*Article, error) { cacheKey : fmt.Sprintf(article:%s, id) mutexKey : fmt.Sprintf(mutex:%s, id) // 1. 尝试读缓存 cached, _ : s.redis.Get(ctx, cacheKey).Result() if cached ! { return parseArticle(cached), nil } // 2. 获取互斥锁 locked, _ : s.redis.SetNX(ctx, mutexKey, 1, 10*time.Second).Result() if !locked { // 其他请求在查库等待后重试 time.Sleep(200 * time.Millisecond) return s.GetArticleWithMutex(ctx, id) } defer s.redis.Del(ctx, mutexKey) // 3. Double-check cached, _ s.redis.Get(ctx, cacheKey).Result() if cached ! { return parseArticle(cached), nil } // 4. 查库并回写 return s.loadAndCache(ctx, id, cacheKey) }五、总结内容平台的读写分离与缓存策略97:3的读写比 → 三级缓存CDN→Redis→只读副本覆盖95%的读请求缓存失效采用主动失效TTL兜底——兼顾一致性和简单性Redis互斥锁解决缓存击穿——热门内容过期瞬间的流量保护读自己的写时直接读主库——消除读写分离的不一致窗口CDN缓存HTML页面是最廉价的高性能方案——45%命中率意味着近一半请求零服务器开销这套架构运行12个月月均基础设施成本约$350含CDNRedisPostgreSQL支撑日均50万PV。缓存命中率从上线时的62%逐步优化到87%。最大的教训缓存架构不是一蹴而就的。先上Redis做第一级缓存观察命中率和访问模式再决定是否需要CDN和只读副本。每一级缓存的增加都是基于前一级的miss数据驱动的——这是数据驱动的架构演进而非提前设计的完美架构。