一、緩存穿透
緩存穿透是指當請求的數據既不在緩存中也不存在于數據庫中時，請求會直接穿透緩存層，到達數據庫層。這通常是由于惡意攻擊或者程序錯誤造成的，比如攻擊者故意請求不存在的大量數據，導致緩存不命中，所有的請求都會落到數據庫上，從而可能對數據庫造成巨大的壓力，影響其性能甚至導致崩潰通常是 thread_running 飆高。
解決方案
- 布隆過濾器（Bloom Filter）：布隆過濾器是一種數據結構，可以用來檢測一個元素是否在一個集合中。在請求到達緩存之前，先通過布隆過濾器進行檢查，如果布隆過濾器判斷數據不存在，則直接返回錯誤響應，避免對數據庫的訪問。
- 緩存空結果：當查詢數據庫后發現數據不存在時，可以將這個"空結果"也緩存起來，并設置一個較短的過期時間。這樣當再次請求相同的數據時，可以直接從緩存中獲取到"空結果"，避免對數據庫的訪問。需要注意的是，這種方法可能會導致緩存被大量無用的空結果填滿，所以需要合理設置過期時間。
- 限制請求：對于異常頻繁的訪問行為，可以采取限流、封禁IP等手段進行限制。例如，可以對每個用戶的訪問頻率、請求的速度等進行限制，超過限制則暫時封禁其請求。
- 接口鑒權：在接口層做好身份驗證和參數校驗，不允許非法請求或者格式不正確的請求訪問數據庫。
- 數據庫建立合理索引：對于一些必須要訪問數據庫的場景，確保數據庫有好的查詢性能，可以通過建立合理的索引來提高查詢效率。
- 二級緩存：使用本地緩存作為一級緩存，redis作為二級緩存。當本地緩存不命中時再查詢Redis，如果Redis也不命中，最后才去查詢數據庫。這樣可以減少直接對Redis的查詢請求，降低Redis的壓力。
- 前端控制：在前端應用中加強校驗，比如表單校驗、輸入內容的合法性檢查等，避免發送無效請求到后端。
二、緩存雪崩
緩存雪崩是指在緩存系統中，由于大量緩存數據在同一時間過期，或者緩存服務宕機，導致所有的請求都直接落到數據庫上，造成數據庫瞬間承受巨大的訪問壓力，從而變得不穩定甚至崩潰的現象。這類似于雪崩一樣，一旦發生就會導致連鎖反應，導致整個系統的性能急劇下降。
解決方案
- 緩存數據的過期時間隨機化：設置緩存數據的過期時間時，不要讓大量的緩存數據在同一時間點過期。可以對過期時間加上一個隨機值，使得緩存數據的過期時間分散開來，防止在同一時刻大面積緩存失效。
- 使用持久化：如果緩存服務支持持久化，比如Redis的RDB和AOF，要確保開啟并合理配置這些功能。這樣，即使緩存服務重啟，也能從持久化的數據中恢復，減少緩存雪崩的風險。
- 設置熱點數據永不過期：對于一些熱點數據，可以設置為永不過期，或者采用手動更新緩存的策略，避免這些熱點數據集體過期。
- 使用多級緩存策略：可以使用本地緩存（如Ehcache）和分布式緩存（如Redis）結合的多級緩存策略，即使分布式緩存不可用，本地緩存仍然可以提供服務，減少對數據庫的直接壓力。
- 提升緩存服務的高可用性：使用主從復制、哨兵機制、集群等高可用方案來確保緩存服務的穩定性。即便單個節點出現故障，也能快速切換到正常的節點，保障緩存服務不中斷。
- 限流和熔斷機制：在系統中實施限流和熔斷機制，當流量或錯誤超過一定閾值時，暫時阻止部分請求，保護數據庫和系統不被過載。
- 異步隊列：當緩存失效后，可以將數據庫的讀取操作放入異步隊列中，用異步處理的方式來緩解瞬時流量對數據庫的沖擊。
三、緩存擊穿
緩存擊穿指的是緩存中沒有但數據庫中有的數據（一般是熱點數據）在緩存失效的瞬間，同時有大量并發請求這個數據點，這些請求會直接穿透緩存，全部落到數據庫上，造成數據庫短時間內的高壓力。這與緩存穿透不同，緩存穿透是查詢不存在的數據，而緩存擊穿則是查詢存在但是緩存剛好失效的數據。
解決方案
- 使用互斥鎖：對于同一個數據點，在緩存失效時，通過加鎖或同步機制，保證不管有多少并發請求，只允許一個請求去數據庫查詢數據，并更新緩存，其他請求等待緩存被更新后直接從緩存中獲取數據。常見的做法是使用分布式鎖。
- 設置熱點數據永不過期：對于一些訪問頻率非常高的熱點數據，可以設置緩存永不過期，或者緩存失效后由后臺維護線程負責更新，而不是由用戶請求觸發更新。
- 使用雙緩存機制（Cache Aside pattern）：當緩存失效時，并不立即刪除緩存，而是使用另一個緩存進行更新操作。在新緩存更新完成之前，所有的讀請求仍然訪問的是舊的緩存。更新完成后再進行切換。
- 提前更新緩存：對于即將到期的數據，可以通過定時任務來檢測并更新它。當檢測到緩存數據即將到期時，可以提前異步地更新緩存。
- 給緩存設置合理的過期時間：對于一些熱點數據，根據業務場景設置合理的過期時間，避免大量并發請求在同一時刻擊穿緩存。
- 分布式緩存+本地緩存：可以在本地實現一層緩存，以減少對分布式緩存服務的訪問頻率，即使分布式緩存服務的數據過期，本地緩存仍然可以提供服務。
- 讀寫分離和負載均衡：數據庫使用讀寫分離架構和負載均衡策略，將讀操作分散到多個從庫，減少對主庫的直接壓力。
四、數據不一致
緩存和數據庫數據不一致的問題通常是由于緩存層與數據庫層之間的數據同步策略不當導致的。這可能發生在以下幾種情況：
1. 寫操作沒有同時更新緩存與數據庫。
2. 緩存過期或被刪除，而數據庫中的數據在此期間被修改。
3. 分布式系統中由于網絡延遲或其他問題導致的數據同步延遲。
4. 數據庫事務回滾，但緩存更新已經發生。
這些問題可能導致用戶獲取到過時的數據，影響用戶體驗，并可能引發更嚴重的數據一致性問題。
解決方案
1. 緩存更新策略
- 緩存延遲雙刪：更新數據庫數據后，先刪除緩存，然后延遲一小段時間再次刪除緩存，以確保請求在這段時間內若讀取了舊數據，也會再次刪除緩存，從而讀到最新數據。
- Write/Read Through Cache：利用緩存提供的寫通(Writethrough)或讀取通(Read through)策略，讓緩存管理器負責數據的讀寫，確保數據的一致性。
- Write Behind Caching：更新操作首先在緩存中執行，然后異步批量更新到數據庫，這種策略要考慮數據丟失的風險和數據一致性的問題。
2. 數據庫觸發器：使用數據庫觸發器在數據發生變化時自動更新緩存，確保數據一致性。
3. 事務消息：通過使用支持事務的消息隊列，將緩存操作和數據庫操作放到同一個事務中，確保兩者要么都成功，要么都失敗。
4. 最終一致性：接受在某個時間窗口內緩存與數據庫中的數據不一致，但是通過后臺異步進程定期校對并同步數據，保證最終一致性。
5. 使用分布式緩存解決方案：選擇支持一致性哈希、數據同步等特性的分布式緩存解決方案，如Redis Cluster，保證數據在多個節點之間的一致性。
6. 版本號/時間戳校驗：給數據庫記錄添加版本號或時間戳，緩存數據時一同緩存這個版本信息，每次讀取緩存數據時都檢查版本或時間戳是否相符，若不符則重新從數據庫加載。
7. 強制緩存過期：設置較短的緩存過期時間，確保數據定期從數據庫中刷新。
五、數據并發競爭
數據并發競爭訪問問題，通常指的是多個客戶端或線程同時對同一數據進行讀寫操作時，由于沒有妥善的并發控制措施導致數據出現不一致或者丟失的情況。這個問題在分布式系統和多用戶系統中尤為常見，尤其是在使用像Redis這樣的緩存系統時也會遇到。
出現問題的場景
- 計數器更新：比如用Redis計數器統計網站點擊量，如果多個請求同時更新計數器，可能會因為讀寫操作不是原子性導致計數器丟失更新。
- 庫存扣減：在電商場景中，多個用戶同時下單扣減庫存，可能會導致超賣。
- 分布式鎖：多個進程需要對同一資源進行操作時，需要使用鎖來保證同時只有一個操作可以執行。
- Session共享：在分布式部署的Web應用中，多個服務器上的并發請求需要共享Session信息，可能導致Session數據不一致。
解決方案
- 使用事務：Redis事務可以通過MULTI和EXEC命令來確保一系列命令的原子性執行。
- 使用Lua腳本：Redis可以執行Lua腳本，Lua腳本在執行過程中會被當作一個整體執行，這保證了操作的原子性。
- 使用分布式鎖：可以實現一個基于Redis的分布式鎖來控制資源的并發訪問。比如使用SETNX命令實現鎖的獲取和釋放。
- 樂觀鎖/Optimistic Locking：使用WATCH命令監視一個或多個鍵，如果在執行事務前這些鍵沒有被其他命令改變，事務才會被執行。
- 悲觀鎖/Pessimistic Locking：對于關鍵業務，可以選擇先對數據加鎖，在業務處理完成后再解鎖，避免其他客戶端的訪問。
- 限流措施：通過限流算法如令牌桶、漏桶等，控制對某一資源的并發訪問數，減少并發沖突。
- 消息隊列：使用消息隊列將并發請求串行化處理，確保對共享資源的訪問是有序的。
作者丨yangyidba
來源丨公眾號：yangyidba（ID：yangyidba）
