极简架构在内容平台中的复盘：读写分离与缓存策略的实践经验
一、内容平台的读多写少特性
一个技术博客平台，日均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; # ?nocache=1绕过缓存 proxy_cache_key "$host$uri"; # 文章更新时通过API主动清除缓存 proxy_cache_purge $purge_method; }第二级：Redis应用缓存（命中率约40%）
CDN miss的请求到达应用层，先查Redis：
func (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的请求最终到达数据库只读副本。主库和只读副本之间通过WAL（Write-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（含CDN+Redis+PostgreSQL），支撑日均50万PV。缓存命中率从上线时的62%逐步优化到87%。
最大的教训：缓存架构不是一蹴而就的。先上Redis做第一级缓存，观察命中率和访问模式，再决定是否需要CDN和只读副本。每一级缓存的增加都是基于前一级的miss数据驱动的——这是"数据驱动的架构演进"，而非"提前设计的完美架构"。
)
)
