日常程式設計中，對於一些有一定併發量或資料量較高的資料庫操作，我們都會在前端加一層快取層，並設定失效時間，現在一般是mongodb或memcached，簡單流程如下：
這個模式在併發量並非太高或資料操作效率很高的情況下基本沒有什麼問題。
但是也許你已經看到了，if(快取失效 && 恰好遇到併發量很高 && 資料庫操作時間長) then？
1. 快取失效
2. 第乙個程序去資料庫獲取新資料，假如包括sql+程式邏輯耗時5s
3. 這5s內，第二個、第三個...第n個都只是獲取到已失效的快取，於是也都連線資料庫...
4. 結果顯而易見，資料庫鎖表 -> 資料庫累計大量程序 -> 直至資料庫掛掉！
那麼，如何去解決這個問題呢？其實最簡單的方案就是：
新增乙個標記，類似檔案鎖，用於判斷此時程式是否正在更新快取。
若是，則直接返回舊快取（標記有設定失效時間，避免由於程式錯誤導致標記未刪除而引起的快取不更新問題）
若否，則設定乙個標記，然後進行資料獲取及快取更新，最後刪除標記。
ps. 第一次生成快取的話可能會有些使用者無法看到資料，不過這個機率很小，且可以通過其他方式如手動生成之類去解決。
流程如下：
快取雪崩問題
快取雪崩是指機器宕機或在我們設定快取時採用了相同的過期時間，導致快取在某一時刻同時失效，請求全部 到db，db瞬時壓力過重雪崩。1 在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量。比如對某個key只允許乙個執行緒查詢資料和寫快取，其他執行緒等待。2 做二級快取，a1為原始快取，a2為...
快取失效 穿透 併發 雪崩問題及解決方法
1 快取失效 引起這個原因的主要因素是高併發下，一般設定乙個快取的過期時間時，併發很高時可能會出在某乙個時間同時生成很多的快取，並且過期時間在同一時刻，這個時候就可能引發 當過期時間到後，這些快取同時失效，請求全部 到db，db可能會壓力過重。處理方法 將快取失效時間分散開，不要所以快取時間長度都設...
快取失效 穿透 併發 雪崩問題及解決方法
1 快取失效 引起這個原因的主要因素是高併發下，一般設定乙個快取的過期時間時，併發很高時可能會出在某乙個時間同時生成很多的快取，並且過期時間在同一時刻，這個時候就可能引發 當過期時間到後，這些快取同時失效，請求全部 到db，db可能會壓力過重。處理方法 將快取失效時間分散開，不要所以快取時間長度都設...