用好緩存的十條軍規
前言
"蘇工！首頁崩了！"
幾年前的一天晚上，我接到電話時，我正夢見自己成了緩存之神。
打開監控一看：
緩存命中率：0%
數據庫QPS：10萬+
線程阻塞數：2000+根本原因竟是之前有同事寫的這段代碼：
public Product getProduct(Long id) {
return productDao.findById(id);
}直連數據庫，未加緩存。
這一刻我意識到：不會用緩存的程序員，就像不會剎車的賽車手。
今天這篇文章跟大家一起聊聊使用緩存的10條軍規，希望對你會有所幫助。
圖片
軍規1: 避免大key
反例場景：
@Cacheable(value = "user", key = "#id")
public User getUser(Long id) {
return userDao.findWithAllRelations(id);
}這里一次查詢出了用戶及其所有關聯對象，然后添加到內存緩存中。
如果通過id查詢用戶信息的請求量非常大，會導致頻繁的GC。
正確實踐：
@Cacheable(value = "user_base", key = "#id")
public UserBase getBaseInfo(Long id) { /*...*/ }
@Cacheable(value = "user_detail", key = "#id")
public UserDetail getDetailInfo(Long id) { /*...*/ }這種情況，需要拆分緩存對象，比如：將用戶基本信息和用戶詳細信息分開緩存。
緩存不是存儲數據的垃圾桶，需要根據數據訪問頻率、讀寫比例、數據一致性要求進行分級管理。
大對象緩存會導致內存碎片化，甚至觸發Full GC。
建議將基礎信息（如用戶ID、名稱）與擴展信息（如訂單記錄）分離存儲。
軍規2: 永遠設置過期時間
血淚案例：某系統將配置信息緩存設置為永不過期，導致修改配置后三天才生效。
正確配置：
@Cacheable(value = "config", key = "#key",
unless = "#result == null",
cacheManager = "redisCacheManager")
public String getConfig(String key) {
return configDao.get(key);
}Redis配置如下：
spring.cache.redis.time-to-live=300000 // 5分鐘
spring.cache.redis.cache-null-values=false需要指定key的存活時間，比如：time-to-live設置成5分鐘。
TTL設置公式：
最優TTL = 平均數據變更周期 × 0.3深層思考：過期時間過短會導致緩存穿透風險，過長會導致數據不一致。
建議采用動態TTL策略。
例如電商商品詳情頁可設置30分鐘基礎TTL+隨機5分鐘抖動。
軍規3: 避免批量失效
典型事故：所有緩存設置相同TTL，導致每天凌晨集中失效，數據庫瞬時被打爆。
解決方案：
使用基礎TTL + 隨機抖動的方案：
public long randomTtl(long baseTtl) {
return baseTtl + new Random().nextInt(300);
}TTL增加0-5分鐘隨機值。
使用示例
redisTemplate.opsForValue().set(key, value, randomTtl(1800), TimeUnit.SECONDS);失效時間分布：
圖片
軍規4: 需要增加熔斷降級
我們在使用緩存的時候，需要增加熔斷降級策略，防止萬一緩存掛了，不能影響整個服務的可用性。
Hystrix實現示例：
@HystrixCommand(fallbackMethod = "getProductFallback",
commandProperties = {
@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "20"),
@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "5000")
})
public Product getProduct(Long id) {
return productDao.findById(id);
}
public Product getProductFallback(Long id) {
return new Product().setDefault(); // 返回兜底數據
}熔斷狀態機：
圖片
軍規5: 空值緩存
在用戶請求并發量大的業務場景種，我們需要把空值緩存起來。
防止大批量在系統中不存在的用戶id，沒有命中緩存，而直接查詢數據庫的情況。
典型代碼：
public Product getProduct(Long id) {
String key = "product:" + id;
Product product = redis.get(key);
if (product != null) {
if (product.isEmpty()) { // 空對象標識
returnnull;
}
return product;
}
product = productDao.findById(id);
if (product == null) {
redis.setex(key, 300, "empty"); // 緩存空值5分鐘
returnnull;
}
redis.setex(key, 3600, product);
return product;
}空值緩存原理：
圖片
需要將數據庫中返回的空值，緩存起來。
后面如果有相同的key查詢數據，則直接從緩存中返回空值。
而無需再查詢一次數據庫。
軍規6: 分布式鎖用Redisson
用Redis做分布式鎖的時候，可能會遇到很多問題。
建議大家使用Redisson做分布式鎖。
Redisson分布式鎖實現：
public Product getProduct(Long id) {
String key = "product:" + id;
Product product = redis.get(key);
if (product == null) {
RLock lock = redisson.getLock("lock:" + key);
try {
if (lock.tryLock(3, 30, TimeUnit.SECONDS)) {
product = productDao.findById(id);
redis.setex(key, 3600, product);
}
} finally {
lock.unlock();
}
}
return product;
}鎖競爭流程圖：
圖片
軍規7: 延遲雙刪策略
在保證數據庫和緩存雙寫數據一致性的業務場景種，可以使用延遲雙刪的策略。
例如：
@Transactional
public void updateProduct(Product product) {
// 1. 先刪緩存
redis.delete("product:" + product.getId());
// 2. 更新數據庫
productDao.update(product);
// 3. 延時再刪
executor.schedule(() -> {
redis.delete("product:" + product.getId());
}, 500, TimeUnit.MILLISECONDS);
}軍規8: 最終一致性方案
延遲雙刪可能還有其他的問題。
我們可以使用最終一致性方案。
基于Binlog的方案：
圖片
DB更新數據之后，Canal會自動監聽數據的變化，它會解析數據事件，然后發送一條MQ消息。
在MQ消費者中，刪除緩存。
軍規9: 熱點數據預加載
對于一些經常使用的熱點數據，我們可以提前做數據的預加載。
實時監控方案：
// 使用Redis HyperLogLog統計訪問頻率
public void recordAccess(Long productId) {
String key = "access:product:" + productId;
redis.pfadd(key, UUID.randomUUID().toString());
redis.expire(key, 60); // 統計最近60秒
}
// 定時任務檢測熱點
@Scheduled(fixedRate = 10000)
public void detectHotKeys() {
Set<String> keys = redis.keys("access:product:*");
keys.forEach(key -> {
long count = redis.pfcount(key);
if (count > 1000) { // 閾值
Long productId = extractId(key);
preloadProduct(productId);
}
});
}定時任務檢測熱點，并且更新到緩存中。
軍規10: 根據場景選擇數據結構
血淚案例：某社交平臺使用String類型存儲用戶信息。
錯誤用String存儲對象：
redis.set("user:123", JSON.toJSONString(user));每次更新單個字段都需要反序列化整個對象。
導致問題：
- 序列化/反序列化開銷大
- 更新單個字段需讀寫整個對象
- 內存占用高 正確實踐：
// 使用Hash存儲
redis.opsForHash().putAll("user:123", userToMap(user));
// 局部更新
redis.opsForHash().put("user:123", "age", "25");數據結構選擇矩陣：
圖片
各數據結構最佳實踐：
1.String
計數器
redis.opsForValue().increment("article:123:views");分布式鎖
redis.opsForValue().set("lock:order:456", "1", "NX", "EX", 30);2.Hash
存儲商品信息
Map<String, String> productMap = new HashMap<>();
productMap.put("name", "iPhone15");
productMap.put("price", "7999");
redis.opsForHash().putAll("product:789", productMap);部分更新
redis.opsForHash().put("product:789", "stock", "100");3.List
消息隊列
redis.opsForList().leftPush("queue:payment", orderJson);最新N條記錄
redis.opsForList().trim("user:123:logs", 0, 99);4.Set
標簽系統
redis.opsForSet().add("article:123:tags", "科技", "數碼");共同好友
redis.opsForSet().intersect("user:123:friends", "user:456:friends");5.ZSet
排行榜
redis.opsForZSet().add("leaderboard", "player1", 2500);
redis.opsForZSet().reverseRange("leaderboard", 0, 9);延遲隊列
redis.opsForZSet().add("delay:queue", "task1", System.currentTimeMillis() + 5000);總結
緩存治理黃金法則
問題類型 | 推薦方案 | 工具推薦 |
緩存穿透 | 空值緩存+布隆過濾器 | Redisson BloomFilter |
緩存雪崩 | 隨機TTL+熔斷降級 | Hystrix/Sentinel |
緩存擊穿 | 互斥鎖+熱點預加載 | Redisson Lock |
數據一致性 | 延遲雙刪+最終一致性 | Canal+RocketMQ |
圖片
最后忠告：緩存是把雙刃劍，用得好是性能利器，用不好就是定時炸彈。
當你準備引入緩存時，先問自己三個問題：
- 真的需要緩存嗎？
- 緩存方案是否完整？
- 有沒有兜底措施？
