巧用Redis：构建高可用交易系统缓存架构
在当今高速发展的数字时代，交易系统面临着前所未有的并发访问压力。作为关键组件的缓存系统，其稳定性和性能直接影响整个系统的可用性。Redis凭借其出色的性能和丰富的数据结构，成为众多交易系统的首选缓存方案。然而，若使用不当，可能会引发缓存穿透、雪崩等问题，甚至导致系统崩溃。本文将深入探讨这些问题的成因，并提供切实可行的解决方案。
1. 缓存穿透：当查询不存在的数据时
缓存穿透是指查询一个一定不存在的数据，由于缓存中不存在，请求会直接穿透到数据库。如果有恶意攻击者频繁发起这类请求，数据库可能不堪重负。
1.1 问题成因与分析
想象一下超市的储物柜系统：顾客询问一个不存在的柜子号，管理员每次都需要去后台系统查询，而无法从缓存中获取答案。在交易系统中，这种情况可能由恶意攻击或程序错误导致，攻击者可能使用随机生成的ID发起大量请求。
1.2 解决方案与实践
1.2.1 布隆过滤器（Bloom Filter）布隆过滤器是一种空间效率高的概率型数据结构，用于判断一个元素是否在集合中。它可能产生假阳性（误报），但不会产生假阴性（漏报）。
复制
// 使用Redisson实现布隆过滤器
public class BloomFilterService {
private RBloomFilter<String> bloomFilter;
@PostConstruct
public void init() {
// 初始化布隆过滤器，预计元素数量100000，误报率1%
bloomFilter = redisson.getBloomFilter("productBloomFilter");
bloomFilter.tryInit(100000L, 0.01);
// 预热数据：将现有有效ID加入布隆过滤器
List<String> validIds = productDao.findAllIds();
for (String id : validIds) {
bloomFilter.add(id);
}
}
public boolean mightContain(String id) {
return bloomFilter.contains(id);
}
}1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.
在实际查询前，先通过布隆过滤器检查键是否存在：
复制
public Product getProduct(String id) {
// 先检查布隆过滤器
if (!bloomFilterService.mightContain(id)) {
return null; // 肯定不存在
}
// 尝试从缓存获取
Product product = redisTemplate.opsForValue().get(buildProductKey(id));
if (product != null) {
return product;
}
// 缓存未命中，查询数据库
product = productDao.findById(id);
if (product != null) {
// 写入缓存并设置过期时间
redisTemplate.opsForValue().set(
buildProductKey(id),
product,
30, TimeUnit.MINUTES
);
} else {
// 即使数据库不存在，也缓存空值防止穿透
redisTemplate.opsForValue().set(
buildProductKey(id),
NullProduct.getInstance(),
5, TimeUnit.MINUTES // 较短过期时间
);
}
return product;
}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.28.29.30.31.32.
对于确定不存在的键，也可以缓存空值或特殊对象，并设置较短的过期时间：
复制
// 空对象表示
public class NullProduct implements Serializable {
private static final NullProduct INSTANCE = new NullProduct();
private NullProduct() {}
public static NullProduct getInstance() {
return INSTANCE;
}
}
// 使用示例
public Product getProduct(String id) {
String cacheKey = buildProductKey(id);
Object value = redisTemplate.opsForValue().get(cacheKey);
if (value instanceof NullProduct) {
return null; // 已知的不存在对象
}
if (value != null) {
return (Product) value;
}
Product product = productDao.findById(id);
if (product != null) {
redisTemplate.opsForValue().set(cacheKey, product, 30, TimeUnit.MINUTES);
} else {
// 缓存空对象，有效期5分钟
redisTemplate.opsForValue().set(cacheKey, NullProduct.getInstance(), 5, TimeUnit.MINUTES);
}
return product;
}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.28.29.30.31.32.33.34.
在API层面对参数进行基础校验，拦截明显无效的请求：
复制
@GetMapping("/product/{id}")
public ResponseEntity<Product> getProduct(@PathVariable("id") String id) {
// ID格式校验：必须是数字且长度在6-10位之间
if (!id.matches("\\d{6,10}")) {
return ResponseEntity.badRequest().build();
}
// 其他业务逻辑...
}1.2.3.4.5.6.7.8.9.
2. 缓存雪崩：当大量缓存同时失效时
缓存雪崩是指缓存中大量数据在同一时间过期，导致所有请求直接访问数据库，造成数据库压力激增。
2.1 问题场景与影响
设想一个电商平台，所有商品信息缓存都设置在凌晨2点统一过期。到期时，大量用户请求直接涌向数据库，可能导致数据库崩溃，进而引发整个系统故障。
2.2 解决方案与实施
2.2.1 差异化过期时间为缓存设置随机的过期时间，避免同时失效：
复制
public void setProductCache(Product product) {
String key = buildProductKey(product.getId());
// 基础过期时间30分钟 + 随机0-10分钟
int expireTime = 30 + new Random().nextInt(10);
redisTemplate.opsForValue().set(key, product, expireTime, TimeUnit.MINUTES);
}1.2.3.4.5.6.
采用"永不过期"策略，通过后台任务定期更新缓存：
复制
// 缓存永不过期，但记录数据版本或更新时间
public void setProductCache(Product product) {
String key = buildProductKey(product.getId());
// 不设置过期时间
redisTemplate.opsForValue().set(key, product);
// 同时记录数据更新时间
redisTemplate.opsForValue().set(
buildProductUpdateTimeKey(product.getId()),
System.currentTimeMillis()
);
}
// 后台任务定期检查并更新缓存
@Scheduled(fixedRate = 300000) // 每5分钟执行一次
public void refreshProductCache() {
// 获取所有需要检查的产品ID
Set<String> productIds = getActiveProductIds();
for (String id : productIds) {
Long lastUpdateTime = (Long) redisTemplate.opsForValue()
.get(buildProductUpdateTimeKey(id));
// 如果超过一定时间未更新，则重新加载
if (lastUpdateTime == null ||
System.currentTimeMillis() - lastUpdateTime > 3600000) { // 1小时
Product product = productDao.findById(id);
if (product != null) {
setProductCache(product);
}
}
}
}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.28.29.30.31.32.33.
当缓存失效时，使用互斥锁确保只有一个线程更新缓存：
复制
public Product getProductWithMutex(String id) {
String cacheKey = buildProductKey(id);
Product product = (Product) redisTemplate.opsForValue().get(cacheKey);
if (product != null) {
return product;
}
// 尝试获取分布式锁
String lockKey = buildLockKey(id);
boolean locked = false;
try {
// 尝试获取锁，等待100ms，锁有效期3秒
locked = redisLockService.tryLock(lockKey, 100, 3000);
if (locked) {
// 获取锁成功，再次检查缓存
product = (Product) redisTemplate.opsForValue().get(cacheKey);
if (product != null) {
return product;
}
// 查询数据库
product = productDao.findById(id);
if (product != null) {
redisTemplate.opsForValue().set(
cacheKey, product, 30 + new Random().nextInt(10), TimeUnit.MINUTES
);
} else {
// 缓存空对象
redisTemplate.opsForValue().set(
cacheKey, NullProduct.getInstance(), 5, TimeUnit.MINUTES
);
}
return product;
} else {
// 未获取到锁，短暂等待后重试
Thread.sleep(50);
return getProductWithMutex(id);
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return productDao.findById(id);
} finally {
if (locked) {
redisLockService.unlock(lockKey);
}
}
}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.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.48.49.
集成熔断器，当数据库压力过大时自动降级：
复制
// 使用Resilience4j实现熔断
@CircuitBreaker(name = "productService", fallbackMethod = "fallbackGetProduct")
public Product getProductWithCircuitBreaker(String id) {
return getProductWithMutex(id);
}
// 降级方法
private Product fallbackGetProduct(String id, Exception e) {
// 返回默认产品或部分数据
return getDefaultProduct();
// 或者从二级缓存（如本地缓存）获取
// return localCache.get(id);
}1.2.3.4.5.6.7.8.9.10.11.12.13.14.
3. 冷热数据分离与自动淘汰机制
在交易系统中，不同数据的访问频率差异很大。合理区分冷热数据并设计自动淘汰机制，是提高缓存效率的关键。
3.1 识别热数据
3.1.1 基于访问频率的识别使用Redis的排序集合（Sorted Set）记录键的访问频率：
复制
public Product getProductWithFrequency(String id) {
String cacheKey = buildProductKey(id);
String frequencyKey = "product:frequency";
// 每次访问增加分数
redisTemplate.opsForZSet().incrementScore(frequencyKey, cacheKey, 1);
// 获取产品逻辑...
return getProduct(id);
}1.2.3.4.5.6.7.8.9.10.
按时间窗口（如最近1小时）统计访问频率，更准确地识别当前热数据：
复制
public void recordAccess(String productId) {
String windowKey = "access:window:" + System.currentTimeMillis() / 3600000; // 小时级窗口
redisTemplate.opsForZSet().incrementScore(windowKey, productId, 1);
// 设置过期时间，自动清理旧窗口数据
redisTemplate.expire(windowKey, 2, TimeUnit.HOURS);
}1.2.3.4.5.6.
3.2 多级缓存架构
设计多级缓存体系，将最热的数据存放在更快的存储中：
复制
public class MultiLevelCache {
@Autowired
private RedisTemplate<String, Object> redisTemplate;
// 本地缓存（使用Caffeine）
private Cache<String, Object> localCache = Caffeine.newBuilder()
.maximumSize(1000)
.expireAfterWrite(10, TimeUnit.MINUTES)
.build();
public Product getProduct(String id) {
String key = buildProductKey(id);
// 第一级：本地缓存
Product product = (Product) localCache.getIfPresent(key);
if (product != null) {
return product;
}
// 第二级：Redis缓存
product = (Product) redisTemplate.opsForValue().get(key);
if (product != null) {
// 回填本地缓存
localCache.put(key, product);
return product;
}
// 第三级：数据库
product = productDao.findById(id);
if (product != null) {
// 写入两级缓存
redisTemplate.opsForValue().set(key, product, 30, TimeUnit.MINUTES);
localCache.put(key, product);
}
return product;
}
}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.28.29.30.31.32.33.34.35.36.37.38.
3.3 智能淘汰策略
3.3.1 基于访问模式的淘汰策略结合LRU（最近最少使用）和LFU（最不经常使用）策略的优点：
复制
public class AdaptiveEvictionPolicy {
// 记录键的访问时间和频率
private Map<String, AccessInfo> accessInfoMap = new ConcurrentHashMap<>();
public void onAccess(String key) {
AccessInfo info = accessInfoMap.getOrDefault(key, new AccessInfo());
info.accessCount++;
info.lastAccessTime = System.currentTimeMillis();
accessInfoMap.put(key, info);
}
public double calculateEvictionScore(String key) {
AccessInfo info = accessInfoMap.get(key);
if (info == null) {
return Double.MAX_VALUE; // 优先淘汰未知键
}
long currentTime = System.currentTimeMillis();
long timeSinceLastAccess = currentTime - info.lastAccessTime;
// 综合访问频率和最近访问时间计算得分
// 得分越高，越容易被淘汰
return (double) timeSinceLastAccess / (info.accessCount + 1);
}
// 定期清理访问记录
@Scheduled(fixedRate = 3600000)
public void cleanupAccessInfo() {
long cutoffTime = System.currentTimeMillis() - 86400000; // 24小时前
accessInfoMap.entrySet().removeIf(entry ->
entry.getValue().lastAccessTime < cutoffTime
);
}
static class AccessInfo {
int accessCount;
long lastAccessTime;
}
}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.28.29.30.31.32.33.34.35.36.37.38.39.
识别冷数据并移动到成本更低的存储：
复制
public class ColdDataArchiver {
@Scheduled(fixedRate = 86400000) // 每天执行一次
public void archiveColdData() {
// 获取最近7天访问频率最低的数据
Set<String> coldKeys = redisTemplate.opsForZSet()
.range("product:frequency", 0, 1000); // 获取1000个最冷键
for (String key : coldKeys) {
Object value = redisTemplate.opsForValue().get(key);
if (value != null) {
// 归档到低成本存储（如MySQL归档表）
archiveToColdStorage(key, value);
// 从Redis删除
redisTemplate.delete(key);
}
}
}
}1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.
4. 监控与预警体系
建立完善的监控体系，及时发现和处理缓存问题：
4.1 关键指标监控
• 缓存命中率：反映缓存效率的核心指标
• 缓存大小和内存使用情况
• 持久化效率和状态
• 网络流量和连接数
4.2 实时预警机制
复制
public class CacheMonitor {
@Autowired
private RedisTemplate<String, Object> redisTemplate;
private long lastTotalRequests = 0;
private long lastHitCount = 0;
@Scheduled(fixedRate = 60000) // 每分钟检查一次
public void checkCacheHealth() {
long currentTotalRequests = getTotalRequests();
long currentHitCount = getHitCount();
long requestDelta = currentTotalRequests - lastTotalRequests;
long hitDelta = currentHitCount - lastHitCount;
// 计算当前命中率
double currentHitRate = requestDelta > 0 ? (double) hitDelta / requestDelta : 1.0;
if (currentHitRate < 0.5) { // 命中率低于50%
alertLowHitRate(currentHitRate);
}
lastTotalRequests = currentTotalRequests;
lastHitCount = currentHitCount;
// 检查内存使用情况
Long memoryUsed = redisTemplate.execute((RedisCallback<Long>) connection ->
connection.serverCommands().info("memory").get("used_memory")
);
if (memoryUsed != null && memoryUsed > 1024 * 1024 * 1024) { // 超过1GB
alertHighMemoryUsage(memoryUsed);
}
}
}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.28.29.30.31.32.33.34.35.
5. 结语
构建高可用的Redis缓存架构需要综合考虑多方面因素。缓存穿透、雪崩和冷热数据分离只是其中几个关键问题。在实际应用中，还需要根据具体业务特点进行调整和优化。
值得注意的是，没有一种方案适合所有场景。有效的缓存策略需要：
1. 深入理解业务数据访问模式
2. 建立完善的监控和预警机制
3. 定期评估和调整策略参数
4. 设计 graceful degradation（优雅降级）方案
通过本文介绍的技术方案，结合实际情况灵活应用，可以显著提升交易系统的稳定性和性能，为用户提供更流畅的体验。
阅读剩余
THE END
