作者：牛牛碼特
鏈接：https://juejin.cn/post/6844903929281511438
背景
快取是軟體開發中一個非常有用的概念，資料庫快取更是在專案中必然會遇到的場景，而快取一致性的保證，更是在面試中被反復問到，這里進行一下總結，針對不同的要求，選擇恰到好處的一致性方案，
快取是什么
存盤的速度是有區別的，快取就是把低速存盤的結果，臨時保存在高速存盤的技術，
如圖所示，金字塔更上面的存盤，可以作為下面存盤的快取，
我們本次的討論，主要針對資料庫快取場景，將以redis作為mysql的快取為案例來進行，
推薦一個開源免費的 Spring Boot 最全教程：
https://github.com/javastacks/spring-boot-best-practice
為什么需要快取
存盤如mysql通常支持完整的ACID特性，因為可靠性，持久性等因素，性能普遍不高，高并發的查詢會給mysql帶來壓力，造成資料庫系統的不穩定，同時也容易產生延遲，根據區域性原理，80%請求會落到20%的熱點資料上，在讀多寫少場景，增加一層快取非常有助提升系統吞吐量和健壯性，
存在問題
存盤的資料隨著時間可能會發生變化，而快取中的資料就會不一致，具體能容忍的不一致時間，需要具體業務具體分析，但是通常的業務，都需要做到最終一致，
redis作為mysql快取
通常的開發模式中，都會使用mysql作為存盤，而redis作為快取，加速和保護mysql，但是，當mysql資料更新之后，redis怎么保持同步呢，
強一致性同步成本太高，如果追求強一致，那么沒必要用快取了，直接用mysql即可，通常考慮的，都是最終一致性，
解決方案
方案一
通過key的過期時間，mysql更新時，redis不更新， 這種方式實作簡單，但不一致的時間會很長，如果讀請求非常頻繁，且過期時間比較長，則會產生很多長期的臟資料，
優點：
- 開發成本低，易于實作；
- 管理成本低，出問題的概率會比較小，
不足
- 完全依賴過期時間，時間太短容易快取頻繁失效，太長容易有長時間更新延遲（不一致）
方案二
在方案一的基礎上擴展，通過key的過期時間兜底，并且，在更新mysql時，同時更新redis，
優點
- 相對方案一，更新延遲更小，
不足
- 如果更新mysql成功，更新redis卻失敗，就退化到了方案一；
- 在高并發場景，業務server需要和mysql,redis同時進行連接，這樣是損耗雙倍的連接資源，容易造成連接數過多的問題，
方案三
針對方案二的同步寫redis進行優化，增加訊息佇列，將redis更新操作交給kafka，由訊息佇列保證可靠性，再搭建一個消費服務，來異步更新redis，
優點
- 訊息佇列可以用一個句柄，很多訊息佇列客戶端還支持本地快取發送，有效解決了方案二連接數過多的問題；
- 使用訊息佇列，實作了邏輯上的解耦；
- 訊息佇列本身具有可靠性，通過手動提交等手段，可以至少一次消費到redis，
不足
- 依舊解決不了時序性問題，如果多臺業務服務器分別處理針對同一行資料的兩條請求，舉個栗子，a = 1； a = 5;，如果mysql中是第一條先執行，而進入kafka的順序是第二條先執行，那么資料就會產生不一致，
- 引入了訊息佇列，同時要增加服務消費訊息，成本較高，
方案四
通過訂閱binlog來更新redis，把我們搭建的消費服務，作為mysql的一個slave，訂閱binlog，決議出更新內容，再更新到redis，
優點
- 在mysql壓力不大情況下，延遲較低；
- 和業務完全解耦；
- 解決了時序性問題，
缺點
- 要單獨搭建一個同步服務，并且引入binlog同步機制，成本較大，
總結
方案選型
- 首先確認產品上對延遲性的要求，如果要求極高，且資料有可能變化，別用快取，
- 通常來說，方案1就夠了，筆者咨詢過4，5個團隊，基本都是用方案1，因為能用快取方案，通常是讀多寫少場景，同時業務上對延遲具有一定的包容性，方案1沒有開發成本，其實比較實用，
- 如果想增加更新時的即時性，就選擇方案2，不過沒必要做重試保證之類的，
- 方案3，方案4針對于對延時要求比較高業務，一個是推模式，一個是拉模式，而方案4具備更強的可靠性，既然都愿意花功夫做處理訊息的邏輯，不如一步到位，用方案4，
結論
一般情況，方案1夠用，若延時要求高，直接選擇方案4，如果是面試場景，從簡單講到復雜，面試官會一步一步追問，咱們就一點點推導，賓主盡歡，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/524862.html
標籤：Java
上一篇：聊一聊責任鏈模式