高并发场景下的缓存架构演进：从单一 Redis 到多层缓存的实战之路
引言：为什么需要缓存？ 在一个典型的电商系统中，读操作占比往往超过 80%。如果每次请求都打到数据库，单表的 QPS 上限大约在 1000-5000（取决于硬件配置）。当并发量达到 10 万+ 时，数据库必然成为瓶颈。 缓存是解决读性能问题的银弹，但它也带来了一系列挑战：数据一致性、缓存雪崩、缓存击穿、缓存穿透。本文将深入探讨这些问题及其解决方案。 一、缓存架构的演进路径 阶段1：无缓存时代 ┌─────────┐ │ 客户端 │ └────┬────┘ │ ▼ ┌─────────┐ │Web服务 │ └────┬────┘ │ ▼ ┌─────────┐ │ 数据库 │ ← 瓶颈 └─────────┘ 问题：数据库成为唯一瓶颈，QPS 上限低。 阶段2：单一 Redis 缓存 ┌─────────┐ │ 客户端 │ └────┬────┘ │ ▼ ┌─────────┐ │Web服务 │ └────┬────┘ │ ├───────────┐ ▼ ▼ ┌─────────┐ ┌─────────┐ │ Redis │ │ 数据库 │ └─────────┘ └─────────┘ 实现： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 type CacheService struct { redis *redis.Client db *sql.DB } func (s *CacheService) GetUser(ctx context.Context, userID string) (*User, error) { // 1. 尝试从 Redis 获取 cached, err := s.redis.Get(ctx, fmt.Sprintf("user:%s", userID)).Result() if err == nil { var user User json.Unmarshal([]byte(cached), &user) return &user, nil } // 2. Redis 未命中，查询数据库 user := &User{} if err := s.db.QueryRow("SELECT * FROM users WHERE id = ?", userID). Scan(user); err != nil { return nil, err } // 3. 写入 Redis data, _ := json.Marshal(user) s.redis.Set(ctx, fmt.Sprintf("user:%s", userID), data, 30*time.Minute) return user, nil } 问题： ...