(一)緩存和數據庫間數據一致性問題
分佈式環境下（單機就不用說了）非常容易出現緩存和數據庫間的數據一致性問題，針對這一點的話，只能說，如果你的項目對緩存的要求是強一致性的，那麼請不要使用緩存。我們只能採取合適的策略來降低緩存和數據庫間數據不一致的概率，而無法保證兩者間的強一致性。合適的策略包括 合適的緩存更新策略，更新數據庫後要及時更新緩存、緩存失敗時增加重試機制，例如MQ模式的消息隊列。
(二)緩存擊穿問題
緩存擊穿表示惡意用戶模擬請求很多緩存中不存在的數據，由於緩存中都沒有，導致這些請求短時間內直接落在了數據庫上，導致數據庫異常。這個我們在實際項目就遇到了，有些搶購活動、秒殺活動的接口API被大量的惡意用戶刷，導致短時間內數據庫c超時了，好在數據庫是讀寫分離，同時也有進行接口限流，hold住了。
解決方案的話：
方案1、使用互斥鎖排隊
業界比價普遍的一種做法，即根據key獲取value值爲空時，鎖上，從數據庫中load數據後再釋放鎖。若其它線程獲取鎖失敗，則等待一段時間後重試。這裏要注意，分佈式環境中要使用分佈式鎖，單機的話用普通的鎖（synchronized、Lock）就夠了。
public String getWithLock(String key, Jedis jedis, String lockKey, String uniqueId, long expireTime) {
// 通過key獲取value
String value = redisService.get(key);
if (StringUtil.isEmpty(value)) {
// 分佈式鎖，詳細可以參考https://blog.csdn.net/fanrenxiang/article/details/79803037
//封裝的tryDistributedLock包括setnx和expire兩個功能，在低版本的redis中不支持
try {
boolean locked = redisService.tryDistributedLock(jedis, lockKey, uniqueId, expireTime);
if (locked) {
value = userService.getById(key);
redisService.set(key, value);
redisService.del(lockKey);
return value;
} else {
// 其它線程進來了沒獲取到鎖便等待50ms後重試
Thread.sleep(50);
getWithLock(key, jedis, lockKey, uniqueId, expireTime);
}
} catch (Exception e) {
log.error("getWithLock exception=" + e);
return value;
} finally {
redisService.releaseDistributedLock(jedis, lockKey, uniqueId);
}
}
return value;
}
這樣做思路比較清晰，也從一定程度上減輕數據庫壓力，但是鎖機制使得邏輯的複雜度增加，吞吐量也降低了，有點治標不治本。
方案2、接口限流與熔斷、降級
重要的接口一定要做好限流策略，防止用戶惡意刷接口，同時要降級準備，當接口中的某些服務不可用時候，進行熔斷，失敗快速返回機制。
方案3、布隆過濾器
bloomfilter就類似於一個hash set，用於快速判某個元素是否存在於集合中，其典型的應用場景就是快速判斷一個key是否存在於某容器，不存在就直接返回。布隆過濾器的關鍵就在於hash算法和容器大小，下面先來簡單的實現下看看效果，我這裏用guava實現的布隆過濾器：
<dependencies>
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>23.0</version>
</dependency>
</dependencies>
public class BloomFilterTest {
private static final int capacity = 1000000;
private static final int key = 999998;
private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), capacity);
static {
for (int i = 0; i < capacity; i++) {
bloomFilter.put(i);
}
}
public static void main(String[] args) {
/*返回計算機最精確的時間，單位微妙*/
long start = System.nanoTime();
if (bloomFilter.mightContain(key)) {
System.out.println("成功過濾到" + key);
}
long end = System.nanoTime();
System.out.println("布隆過濾器消耗時間:" + (end - start));
int sum = 0;
for (int i = capacity + 20000; i < capacity + 30000; i++) {
if (bloomFilter.mightContain(i)) {
sum = sum + 1;
}
}
System.out.println("錯判率爲:" + sum);
}
}
成功過濾到999998
布隆過濾器消耗時間:215518
錯判率爲:318
可以看到，100w個數據中只消耗了約0.2毫秒就匹配到了key，速度足夠快。然後模擬了1w個不存在於布隆過濾器中的key，匹配錯誤率爲318/10000，也就是說，出錯率大概爲3%，跟蹤下BloomFilter的源碼發現默認的容錯率就是0.03：
public static <T> BloomFilter<T> create(Funnel<T> funnel, int expectedInsertions /* n */) {
return create(funnel, expectedInsertions, 0.03); // FYI, for 3%, we always get 5 hash functions
}
我們可調用BloomFilter的這個方法顯式的指定誤判率：
private static BloomFilter<Integer> bloomFilter = BloomFilter.create(Funnels.integerFunnel(), capacity,0.01);
我們斷點跟蹤下，誤判率爲0.02和默認的0.03時候的區別:
對比兩個出錯率可以發現，誤判率爲0.02時數組大小爲8142363，0.03時爲7298440，誤判率降低了0.01，BloomFilter維護的數組大小也減少了843923，可見BloomFilter默認的誤判率0.03是設計者權衡系統性能後得出的值。要注意的是，布隆過濾器不支持刪除操作。用在這邊解決緩存穿透問題就是：
public String getByKey(String key) {
// 通過key獲取value
String value = redisService.get(key);
if (StringUtil.isEmpty(value)) {
if (bloomFilter.mightContain(key)) {
value = userService.getById(key);
redisService.set(key, value);
return value;
} else {
return null;
}
}
return value;
}
(三)緩存雪崩問題
緩存在同一時間內大量鍵過期（失效），接着來的一大波請求瞬間都落在了數據庫中導致連接異常。
解決方案：
方案1、也是像解決緩存穿透一樣加鎖排隊，實現同上;
方案2、建立備份緩存，緩存A和緩存B，A設置超時時間，B不設值超時時間，先從A讀緩存，A沒有讀B，並且更新A緩存和B緩存;
方案3、設置緩存超時時間的時候加上一個隨機的時間長度，比如這個緩存key的超時時間是固定的5分鐘加上隨機的2分鐘，醬紫可從一定程度上避免雪崩問題；
public String getByKey(String keyA,String keyB) {
String value = redisService.get(keyA);
if (StringUtil.isEmpty(value)) {
value = redisService.get(keyB);
String newValue = getFromDbById();
redisService.set(keyA,newValue,31, TimeUnit.DAYS);
redisService.set(keyB,newValue);
}
return value;
}
(四)緩存併發問題
這裏的併發指的是多個redis的client同時set key引起的併發問題。其實redis自身就是單線程操作，多個client併發操作，按照先到先執行的原則，先到的先執行，其餘的阻塞。當然，另外的解決方案是把redis.set操作放在隊列中使其串行化，必須的一個一個執行，具體的代碼就不上了，當然加鎖也是可以的，至於爲什麼不用redis中的事務，留給各位看官自己思考探究。
————————————————
版權聲明：本文爲CSDN博主「飯一碗」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/fanrenxiang/article/details/80542580