在微服务架构中，数据库往往是系统吞吐量的核心瓶颈。面对突发的高流量（High QPS），仅仅依赖数据库的水平扩展不仅成本高昂，而且响应延迟无法满足实时性要求。
构建多级缓存架构是解决这一问题的标准路径。本文将深入解析Redis与Memcached的选型策略，并通过代码与实战案例，阐述如何解决缓存一致性与高可用性难题。
Redis与Memcached的内核级选型对比
尽管Redis已占据主导地位，但在特定场景下Memcached仍具备优势。技术选型不应基于流行度，而应基于内存管理模型与数据结构需求。
| 特性 | Redis | Memcached |
|---|---|---|
| 线程模型 | 单线程主循环（6.0+支持多线程IO），无锁竞争，逻辑简单 | 多线程异步IO，利用多核优势，适合极高吞吐量的纯KV场景 |
| 数据结构 | String, Hash, List, Set, ZSet, Bitmap, HyperLogLog等 | 仅支持简单的String（Key-Value） |
| 持久化 | 支持RDB快照与AOF日志，可恢复数据 | 不支持，重启后数据丢失（纯内存） |
| 集群模式 | 原生支持Redis Cluster（分片、高可用） | 客户端侧哈希（Consistent Hashing），服务端互不通信 |
| 适用场景 | 复杂业务逻辑、排行榜、计数器、消息队列、分布式锁 | 静态页面缓存、图片元数据、简单的Session存储 |
标准缓存读写策略：Cache-Aside Pattern
在业务开发中，旁路缓存模式（Cache-Aside Pattern） 是最成熟且广泛使用的策略。其核心逻辑由应用程序直接控制数据库与缓存的交互。
读写流程规范
- 读路径： 先读缓存；若命中则返回；若未命中（Miss），读数据库并将数据写入缓存，最后返回。
- 写路径： 先更新数据库，成功后删除缓存（而非更新缓存）。
为何是“删除”而非“更新”？在高并发写场景下，更新缓存容易产生竞态条件（Race Condition），导致缓存通过旧数据覆盖新数据，且“删除”操作是幂等的。
实现代码示例（Java/Spring伪代码）
public User getUser(long userId) {
String cacheKey = "user:" + userId;
// 1. 尝试从缓存读取
String userJson = redisTemplate.opsForValue().get(cacheKey);
if (userJson != null) {
return deserialize(userJson);
}
// 2. 缓存未命中，加锁防止击穿（可选，视热度而定）
synchronized(this) {
// 双重检查
userJson = redisTemplate.opsForValue().get(cacheKey);
if (userJson != null) return deserialize(userJson);
// 3. 从数据库读取
User user = userMapper.selectById(userId);
if (user == null) {
// 防止缓存穿透，写入空值并设置短TTL
redisTemplate.opsForValue().set(cacheKey, "{}", 60, TimeUnit.SECONDS);
return null;
}
// 4. 回写缓存，设置随机过期时间防止雪崩
long ttl = 3600 + new Random().nextInt(600);
redisTemplate.opsForValue().set(cacheKey, serialize(user), ttl, TimeUnit.SECONDS);
return user;
}
}
public void updateUser(User user) {
// 1. 更新数据库
userMapper.update(user);
// 2. 删除缓存
redisTemplate.delete("user:" + user.getId());
}解决缓存一致性的进阶方案
虽然Cache-Aside模式解决了大部分问题，但在“先更新DB，再删除Cache”的瞬间，如果删除失败或有并发读请求，仍可能出现数据不一致。以下是工业级解决方案：
1. 延时双删策略 (Delayed Double Deletion)
在主从读写分离的架构中，主库更新同步到从库存在延迟。此时若直接删除缓存，读请求可能会从旧数据的从库读取并回填脏数据到缓存。
流程： 更新DB -> 删除缓存 -> 休眠N毫秒 -> 再次删除缓存。第二次删除旨在清除可能被并发读请求回填的脏数据。
2. 订阅Binlog异步删除
为了解耦业务代码与缓存逻辑，可通过Canal等工具监听MySQL Binlog。当检测到数据变更时，发送消息至MQ，由消费者负责可靠地删除缓存。此方案具备重试机制，能保证最终一致性。
高并发下的灾难预防与故障排查
系统上线后，必须针对以下三种典型故障预置防御机制。
1. 缓存穿透 (Cache Penetration)
现象： 大量请求查询数据库中不存在的数据（如ID=-1），流量直接打穿缓存压垮DB。
解决方案：
1. 接口层增加参数校验。
2. 缓存空对象（set key null）并设置短TTL。
3. 使用布隆过滤器（Bloom Filter）在访问缓存前快速判断Key是否存在。
2. 缓存击穿 (Cache Breakdown)
现象： 某个极热点Key（如秒杀商品）突然过期，海量并发请求瞬间涌入数据库。
解决方案：
1. 设置热点数据永不过期（逻辑过期，后台异步刷新）。
2. 使用互斥锁（Mutex Lock），如Redis的SETNX，保证同一时刻只有一个线程查询DB并回填缓存。
3. 缓存雪崩 (Cache Avalanche)
现象： 大量缓存Key在同一时间集中过期，或Redis节点宕机。
解决方案：
1. 过期时间（TTL）添加随机因子，避免同时失效。
2. 构建Redis高可用集群（Sentinel或Cluster模式）。
3. 开启多级缓存（本地Ehcache + 远程Redis）。
总结与架构演进
设计高流量系统缓存架构，不仅仅是部署一个Redis实例。从底层的协议选型、中间层的读写模式设计，到上层的一致性保障与容灾策略，每一环都决定了系统的稳定性。
在流量持续增长的背景下，建议引入热点发现系统，自动识别Hot Key并推送到应用本地缓存（Local Cache），形成“L1本地 + L2分布式 + L3数据库”的立体防御体系。
Post a Comment