Web 应用中是否应将分类统计结果常驻内存？——轻量级缓存实践指南-Golang-PHP中文网

Web 应用中是否应将分类统计结果常驻内存？——轻量级缓存实践指南

在产品数据更新不频繁但分类统计需高频展示的场景下，将 updateProductsCategories() 的结果缓存在应用内存中，可显著减少数据库查询开销，提升页面响应速度，是合理且常见的性能优化手段。

在产品数据更新不频繁但分类统计需高频展示的场景下，将 `updateproductscategories()` 的结果缓存在应用内存中，可显著减少数据库查询开销，提升页面响应速度，是合理且常见的性能优化手段。

对于典型的电商类 Web 应用，侧边栏展示“食品（20）”“饮品（74）”“夹克（15）”这类带数量的分类导航，本质是一个读多写少、计算有代价、数据体量小的典型缓存候选场景。直接在每次页面渲染时执行 SQL 聚合查询（如 SELECT category, COUNT(*) FROM products GROUP BY category）虽逻辑简单，但在高并发下易成为数据库瓶颈；而将其结果缓存在进程内存中，则能以极低延迟提供服务。

✅ 推荐实现方式（Go 示例）：

var (
    mu          sync.RWMutex
    categoryStats = make(map[string]int)
)

// 更新统计（在产品增删改后调用）
func updateProductsCategories() {
    mu.Lock()
    defer mu.Unlock()

    // 执行 DB 查询并重建映射
    rows, _ := db.Query("SELECT category, COUNT(*) FROM products GROUP BY category")
    categoryStats = make(map[string]int)
    for rows.Next() {
        var cat string
        var count int
        rows.Scan(&cat, &count)
        categoryStats[cat] = count
    }
}

// 读取统计（供 HTTP handler 调用）
func getCategoryStats() map[string]int {
    mu.RLock()
    defer mu.RUnlock()
    // 浅拷贝避免外部修改原始 map
    stats := make(map[string]int, len(categoryStats))
    for k, v := range categoryStats {
        stats[k] = v
    }
    return stats
}

⚠️ 关键注意事项：

并发安全必须保障：Web 服务器通常使用多 goroutine 处理请求，对共享缓存的读写需通过 sync.RWMutex 等机制保护，避免竞态导致数据错乱或 panic；
多实例部署需谨慎：若应用横向扩展为多个服务器实例，各实例内存缓存彼此隔离，无法自动同步——此时一次产品更新仅刷新本机缓存，其他实例仍返回旧值。单机部署适用，集群环境建议引入 Redis 等中心化缓存；
失效策略要明确：推荐采用「写时主动更新」而非「过期自动失效」。即在产品 CRUD 操作成功后立即调用 updateProductsCategories()，确保缓存与 DB 强一致，避免用户看到陈旧计数；
监控缓存命中率：可通过日志或指标（如 Prometheus）记录 getCategoryStats() 调用次数与实际 DB 查询次数，验证优化效果——理想情况下 DB 查询应仅发生在数据变更时刻。