原文鏈接CSDN：https://blog.csdn.net/u012562943/article/details/81482914
將不一致分為三種情況：
1. 數據庫有數據，緩存沒有數據；
2. 數據庫有數據，緩存也有數據，數據不相等；
3. 數據庫沒有數據，緩存有數據。
在討論這三種情況之前，先說明一下我使用緩存的策略，也是大多數人使用的策略，叫做 Cache Aside Pattern。簡而言之，就是
1. 首先嚐試從緩存讀取，讀到數據則直接返回；如果讀不到，就讀數據庫，並將數據會寫到緩存，並返回。
2. 需要更新數據時，先更新數據庫，然後把緩存裡對應的數據失效掉（刪掉）。
讀的邏輯大家都很容易理解，談談更新。如果不採取我提到的這種更新方法，你還能想到什麼更新方法呢？大概會是：先刪除緩存，然後再更新數據庫。這麼做引發的問題是，如果A,B兩個線程同時要更新數據，並且A,B已經都做完了刪除緩存這一步，接下來，A先更新了數據庫，C線程讀取數據，由於緩存沒有，則查數據庫，並把A更新的數據，寫入了緩存，最後B更新數據庫。那麼緩存和數據庫的值就不一致了。另外有人會問，如果採用你提到的方法，為什麼最後是把緩存的數據刪掉，而不是把更新的數據寫到緩存裡。這麼做引發的問題是，如果A,B兩個線程同時做數據更新，A先更新了數據庫，B後更新數據庫，則此時數據庫裡存的是B的數據。而更新緩存的時候，是B先更新了緩存，而A後更新了緩存，則緩存裡是A的數據。這樣緩存和數據庫的數據也不一致。按照我提到的這種更新緩存的策略，理論上也是有不一致的風險的，之前在其他的博客文章有看到過，只不過概率很小，我們暫時可以不考慮，後面我們有其他手段來補救。討論完使用緩存的策略，我們再來看這三種不一致的情況。
1. 對於第一種，在讀數據的時候，會自動把數據庫的數據寫到緩存，因此不一致自動消除.
2. 對於第二種，數據最終變成了不相等，但他們之前在某一個時間點一定是相等的（不管你使用懶加載還是預加載的方式，在緩存加載的那一刻，它一定和數據庫一致）。這種不一致，一定是由於你更新數據所引發的。前面我們講了更新數據的策略，先更新數據庫，然後刪除緩存。因此，不一致的原因，一定是數據庫更新了，但是刪除緩存失敗了。
3. 對於第三種，情況和第二種類似，你把數據庫的數據刪了，但是刪除緩存的時候失敗了。
因此，最終的結論是，需要解決的不一致，產生的原因是更新數據庫成功，但是刪除緩存失敗。
解決方案大概有以下幾種：
1. 對刪除緩存進行重試，數據的一致性要求越高，我越是重試得快。
2. 定期全量更新，簡單地說，就是我定期把緩存全部清掉，然後再全量加載。
3. 給所有的緩存一個失效期。
第三種方案可以說是一個大殺器，任何不一致，都可以靠失效期解決，失效期越短，數據一致性越高。但是失效期越短，查數據庫就會越頻繁。因此失效期應該根據業務來定。
併發不高的情況：
讀: 讀redis->沒有，讀mysql->把mysql數據寫回redis，有的話直接從redis中取；
寫: 寫mysql->成功，再寫redis；
併發高的情況：
讀: 讀redis->沒有，讀mysql->把mysql數據寫回redis，有的話直接從redis中取；
寫：異步話，先寫入redis的緩存，就直接返回；定期或特定動作將數據保存到mysql，可以做到多次更新，一次保存；
閱讀更多 java進階架構師 的文章
