## 前言 本篇文章是我之前系列文章中的一篇，主要討論了我們在平時的開發過程中，各大系統中都要用到的**快取資料**的問題，進一步延伸到**資料庫和快取的雙寫一致性問題**，並且給出了所有方案的實現程式碼方便大家參考。 ## 本篇文章主要內容 - 資料快取 - 為何要使用快取 - 哪類資料適合快取 - 快取的利與弊 - 如何保證快取和資料庫一致性 - 不更新快取，而是刪除快取 - 先操作快取，還是先操作資料庫 - 非要保證資料庫和快取資料強一致該怎麼辦 - 快取和資料庫一致性實戰 - 實戰：先刪除快取，再更新資料庫 - 實戰：先更新資料庫，再刪快取 - 實戰：快取延時雙刪 - 實戰：刪除快取重試機制 - 實戰：讀取binlog非同步刪除快取 > 碼字不易，只求關注，歡迎關注我的原創技術公眾號：後端技術漫談（二維碼見文章底部） ## 專案原始碼在這裡 https://github.com/qqxx6661/miaosha ## 資料快取 在我們實際的業務場景中，一定有很多需要做資料快取的場景，比如售賣商品的頁面，包括了許多併發訪問量很大的資料，它們可以稱作是是“熱點”資料，這些資料有一個特點，**就是更新頻率低，讀取頻率高**，這些資料應該儘量被快取，從而減少請求打到資料庫上的機會，減輕資料庫的壓力。 ### 為何要使用快取 快取是為了追求“快”而存在的。我們用程式碼舉一個例子。 我在自己的Demo程式碼倉庫中增加了兩個查詢庫存的介面getStockByDB和getStockByCache，分別表示從資料庫和快取查詢某商品的庫存量。 隨後我們用JMeter進行併發請求測試。（JMeter的使用請參考我之前寫的文章：[點選這裡](https://mp.weixin.qq.com/s?__biz=MzU1NTA0NTEwMg==&mid=2247484174&idx=1&sn=235af7ead49a7d33e7fab52e05d5021f&lang=zh_CN#rd)） > 需要宣告的是，我的測試並不嚴謹，只是作對比測試，不要作為實際服務效能的參考。 這是兩個介面的程式碼： ``` /** * 查詢庫存：通過資料庫查詢庫存 * @param sid * @return */ @RequestMapping("/getStockByDB/{sid}") @ResponseBody public String getStockByDB(@PathVariable int sid) { int count; try { count = stockService.getStockCountByDB(sid); } catch (Exception e) { LOGGER.error("查詢庫存失敗：[{}]", e.getMessage()); return "查詢庫存失敗"; } LOGGER.info("商品Id: [{}] 剩餘庫存為: [{}]", sid, count); return String.format("商品Id: %d 剩餘庫存為：%d", sid, count); } /** * 查詢庫存：通過快取查詢庫存 * 快取命中：返回庫存 * 快取未命中：查詢資料庫寫入快取並返回 * @param sid * @return */ @RequestMapping("/getStockByCache/{sid}") @ResponseBody public String getStockByCache(@PathVariable int sid) { Integer count; try { count = stockService.getStockCountByCache(sid); if (count == null) { count = stockService.getStockCountByDB(sid); LOGGER.info("快取未命中，查詢資料庫，並寫入快取"); stockService.setStockCountToCache(sid, count); } } catch (Exception e) { LOGGER.error("查詢庫存失敗：[{}]", e.getMessage()); return "查詢庫存失敗"; } LOGGER.info("商品Id: [{}] 剩餘庫存為: [{}]", sid, count); return String.format("商品Id: %d 剩餘庫存為：%d", sid, count); } ``` 首先設定為10000個併發請求的情況下，執行JMeter，結果首先出現了大量的報錯，10000個請求中98%的請求都直接失敗了。讓人很慌張~ 開啟日誌，報錯如下：  SpringBoot內建的Tomcat最大併發數搞的鬼，其預設值為200，對於10000的併發，單機服務實在是力不從心。當然，你可以修改這裡的併發數設定，但是你的小機器仍然可能會扛不住。  將其修改為如下配置後，我的小機器才在通過快取拿庫存的情況下，保證了10000個併發的100%返回請求： ``` server.tomcat.max-threads=10000 server.tomcat.max-connections=10000 ``` **可以看到，不使用快取的情況下，吞吐量為668個請求每秒**：  **使用快取的情況下，吞吐量為2177個請求每秒**：  在這種“**十分不嚴謹**”的對比下，有快取對於一臺單機，效能提升了3倍多，如果在多臺機器，更多併發的情況下，由於資料庫有了更大的壓力，快取的效能優勢應該會更加明顯。 測完了這個小實驗，我看了眼我掛著MySql的小水管騰訊雲伺服器，生怕他被這麼高流量搞掛。這種突發的流量，指不定會被檢測為異常攻擊流量呢~  我用的是騰訊雲伺服器1C4G2M，活動買的，很便宜。這裡打個免費的廣告，請騰訊雲看到後聯絡我給我打錢 ;)  ### 哪類資料適合快取 快取量大但又不常變化的資料，比如詳情，評論等。對於那些經常變化的資料，其實並不適合快取，一方面會增加系統的複雜性（快取的更新，快取髒資料），另一方面也給系統帶來一定的不穩定性（快取系統的維護）。 **但一些極端情況下，你需要將一些會變動的資料進行快取，比如想要頁面顯示準實時的庫存數，或者其他一些特殊業務場景。這時候你需要保證快取不能（一直）有髒資料，這就需要再深入討論一下。** ### 快取的利與弊 我們到底該不該上快取的，這其實也是個trade-off（權衡）的問題。 上快取的優點： - 能夠縮短服務的響應時間，給使用者帶來更好的體驗。 - 能夠增大系統的吞吐量，依然能夠提升使用者體驗。 - 減輕資料庫的壓力，防止高峰期資料庫被壓垮，導致整個線上服務BOOM！ 上了快取，也會引入很多額外的問題： - 快取有多種選型，是記憶體快取，memcached還是redis，你是否都熟悉，如果不熟悉，無疑增加了維護的難度（本來是個純潔的資料庫系統）。 - 快取系統也要考慮分散式，比如redis的分散式快取還會有很多坑，無疑增加了系統的複雜性。 - 在特殊場景下，如果對快取的準確性有非常高的要求，就必須考慮**快取和資料庫的一致性問題**。 **本文想要重點討論的，就是快取和資料庫的一致性問題，各位看官且往下看。** ## 如何保證快取和資料庫一致性 說了這麼多快取的必要性，那麼使用快取是不是就是一個很簡單的事情了呢，我之前也一直是這麼覺得的，直到遇到了需要快取與資料庫保持**強一致**的場景，才知道讓資料庫資料和快取資料保持一致性是一門很高深的學問。 從遠古的硬體快取，作業系統快取開始，快取就是一門獨特的學問。這個問題也被業界探討了非常久，爭論至今。我翻閱了很多資料，發現其實這是一個權衡的問題。值得好好講講。 **以下的討論會引入幾方觀點，我會跟著觀點來寫程式碼驗證所提到的問題。** ### 不更新快取，而是刪除快取 **大部分觀點認為，做快取不應該是去更新快取，而是應該刪除快取，然後由下個請求去去快取，發現不存在後再讀取資料庫，寫入快取。** 觀點引用：《分散式之資料庫和快取雙寫一致性方案解析》孤獨煙 > **原因一：執行緒安全形度** > > 同時有請求A和請求B進行更新操作，那麼會出現 > > （1）執行緒A更新了資料庫 > > （2）執行緒B更新了資料庫 > > （3）執行緒B更新了快取 > > （4）執行緒A更新了快取 > > 這就出現請求A更新快取應該比請求B更新快取早才對，但是因為網路等原因，B卻比A更早更新了快取。這就導致了髒資料，因此不考慮。 > > **原因二：業務場景角度** > > 有如下兩點： > > （1）如果你是一個寫資料庫場景比較多，而讀資料場景比較少的業務需求，採用這種方案就會導致，資料壓根還沒讀到，快取就被頻繁的更新，浪費效能。 > > （2）如果你寫入資料庫的值，並不是直接寫入快取的，而是要經過一系列複雜的計算再寫入快取。那麼，每次寫入資料庫後，都再次計算寫入快取的值，無疑是浪費效能的。顯然，刪除快取更為適合。 **其實如果業務非常簡單，只是去資料庫拿一個值，寫入快取，那麼更新快取也是可以的。但是，淘汰快取操作簡單，並且帶來的副作用只是增加了一次cache miss，建議作為通用的處理方式。** ### 先操作快取，還是先操作資料庫 **那麼問題就來了，我們是先刪除快取，然後再更新資料庫，還是先更新資料庫，再刪快取呢？** 先來看看大佬們怎麼說。 《【58沈劍架構系列】快取架構設計細節二三事》58沈劍： > 對於一個不能保證事務性的操作，一定涉及“哪個任務先做，哪個任務後做”的問題，解決這個問題的方向是：如果出現不一致，誰先做對業務的影響較小，就誰先執行。 > > 假設先淘汰快取，再寫資料庫：第一步淘汰快取成功，第二步寫資料庫失敗，則只會引發一次Cache miss。 > > 假設先寫資料庫，再淘汰快取：第一步寫資料庫操作成功，第二步淘汰快取失敗，則會出現DB中是新資料，Cache中是舊資料，資料不一致。 沈劍老師說的沒有問題，不過**沒完全考慮好併發請求時的資料髒讀問題**，讓我們再來看看孤獨煙老師《分散式之資料庫和快取雙寫一致性方案解析》： > **先刪快取，再更新資料庫** > > 該方案會導致請求資料不一致 > > 同時有一個請求A進行更新操作，另一個請求B進行查詢操作。那麼會出現如下情形: > > （1）請求A進行寫操作，刪除快取 > > （2）請求B查詢發現快取不存在 > > （3）請求B去資料庫查詢得到舊值 > > （4）請求B將舊值寫入快取 > > （5）請求A將新值寫入資料庫 > > 上述情況就會導致不一致的情形出現。而且，如果不採用給快取設定過期時間策略，該資料永遠都是髒資料。 **所以先刪快取，再更新資料庫並不是一勞永逸的解決方案，再看看先更新資料庫，再刪快取這種方案怎麼樣？** > **先更新資料庫，再刪快取**這種情況不存在併發問題麼？ > > 不是的。假設這會有兩個請求，一個請求A做查詢操作，一個請求B做更新操作，那麼會有如下情形產生 > > （1）快取剛好失效 > > （2）請求A查詢資料庫，得一箇舊值 > > （3）請求B將新值寫入資料庫 > > （4）請求B刪除快取 > > （5）請求A將查到的舊值寫入快取 > > ok，如果發生上述情況，確實是會發生髒資料。 > > 然而，發生這種情況的概率又有多少呢？ > > 發生上述情況有一個先天性條件，就是步驟（3）的寫資料庫操作比步驟（2）的讀資料庫操作耗時更短，才有可能使得步驟（4）先於步驟（5）。可是，大家想想，**資料庫的讀操作的速度遠快於寫操作的（不然做讀寫分離幹嘛，做讀寫分離的意義就是因為讀操作比較快，耗資源少），因此步驟（3）耗時比步驟（2）更短，這一情形很難出現。** **先更新資料庫，再刪快取依然會有問題，不過，問題出現的可能性會因為上面說的原因，變得比較低！** 所以，如果你想實現基礎的快取資料庫雙寫一致的邏輯，那麼在大多數情況下，在不想做過多設計，增加太大工作量的情況下，請**先更新資料庫，再刪快取!** ### 我非要資料庫和快取資料強一致怎麼辦 那麼，如果我非要保證絕對一致性怎麼辦，先給出結論： **沒有辦法做到絕對的一致性，這是由CAP理論決定的，快取系統適用的場景就是非強一致性的場景，所以它屬於CAP中的AP。** 所以，我們得委曲求全，可以去做到BASE理論中說的**最終一致性**。 > 最終一致性強調的是系統中所有的資料副本，在經過一段時間的同步後，最終能夠達到一個一致的狀態。因此，最終一致性的本質是需要系統保證最終資料能夠達到一致，而不需要實時保證系統資料的強一致性 大佬們給出了到達最終一致性的解決思路，主要是針對上面兩種雙寫策略（先刪快取，再更新資料庫/先更新資料庫，再刪快取）導致的**髒資料問題，進行相應的處理，來保證最終一致性。** #### 快取延時雙刪 問：先刪除快取，再更新資料庫中避免髒資料？ 答案：採用延時雙刪策略。 上文我們提到，在先刪除快取，再更新資料庫的情況下，如果不採用給快取設定過期時間策略，該資料永遠都是髒資料。 **那麼延時雙刪怎麼解決這個問題呢？** > （1）先淘汰快取 > > （2）再寫資料庫（這兩步和原來一樣） > > （3）休眠1秒，再次淘汰快取 > > 這麼做，可以將1秒內所造成的快取髒資料，再次刪除。 **那麼，這個1秒怎麼確定的，具體該休眠多久呢？** > 針對上面的情形，讀者應該自行評估自己的專案的讀資料業務邏輯的耗時。然後寫資料的休眠時間則在讀資料業務邏輯的耗時基礎上，加幾百ms即可。這麼做的目的，就是確保讀請求結束，寫請求可以刪除讀請求造成的快取髒資料。 **如果你用了mysql的讀寫分離架構怎麼辦？** > ok，在這種情況下，造成資料不一致的原因如下，還是兩個請求，一個請求A進行更新操作，另一個請求B進行查詢操作。 > > （1）請求A進行寫操作，刪除快取 > > （2）請求A將資料寫入資料庫了， > > （3）請求B查詢快取發現，快取沒有值 > > （4）請求B去從庫查詢，這時，還沒有完成主從同步，因此查詢到的是舊值 > > （5）請求B將舊值寫入快取 > > （6）資料庫完成主從同步，從庫變為新值 > > 上述情形，就是資料不一致的原因。還是使用雙刪延時策略。只是，睡眠時間修改為在主從同步的延時時間基礎上，加幾百ms。 **採用這種同步淘汰策略，吞吐量降低怎麼辦？** > ok，那就將第二次刪除作為非同步的。自己起一個執行緒，非同步刪除。這樣，寫的請求就不用沉睡一段時間後了，再返回。這麼做，加大吞吐量。 **所以在先刪除快取，再更新資料庫的情況下**，可以使用延時雙刪的策略，來保證髒資料只會存活一段時間，就會被準確的資料覆蓋。 **在先更新資料庫，再刪快取的情況下**，快取出現髒資料的情況雖然可能性極小，但也會出現。我們依然可以用延時雙刪策略，在請求A對快取寫入了髒的舊值之後，再次刪除快取。來保證去掉髒快取。 #### 刪快取失敗了怎麼辦：重試機制 看似問題都已經解決了，但其實，還有一個問題沒有考慮到，那就是刪除快取的操作，失敗了怎麼辦？比如延時雙刪的時候，第二次快取刪除失敗了，那不還是沒有清除髒資料嗎？ **解決方案就是再加上一個重試機制，保證刪除快取成功。** 參考孤獨煙老師給的方案圖： **方案一：**  > 流程如下所示 > > （1）更新資料庫資料； > > （2）快取因為種種問題刪除失敗 > > （3）將需要刪除的key傳送至訊息佇列 > > （4）自己消費訊息，獲得需要刪除的key > > （5）繼續重試刪除操作，直到成功 > > 然而，該方案有一個缺點，對業務線程式碼造成大量的侵入。於是有了方案二，在方案二中，啟動一個訂閱程式去訂閱資料庫的binlog，獲得需要操作的資料。在應用程式中，另起一段程式，獲得這個訂閱程式傳來的資訊，進行刪除快取操作。 方案二：  > 流程如下圖所示： > > （1）更新資料庫資料 > > （2）資料庫會將操作資訊寫入binlog日誌當中 > > （3）訂閱程式提取出所需要的資料以及key > > （4）另起一段非業務程式碼，獲得該資訊 > > （5）嘗試刪除快取操作，發現刪除失敗 > > （6）將這些資訊傳送至訊息佇列 > > （7）重新從訊息佇列中獲得該資料，重試操作。 **而讀取binlog的中介軟體，可以採用阿里開源的canal** 好了，到這裡我們已經把快取雙寫一致性的思路徹底梳理了一遍，下面就是我對這幾種思路徒手寫的實戰程式碼，方便有需要的朋友參考。 ## 快取和資料庫一致性實戰 ### 實戰：先刪除快取，再更新資料庫 終於到了實戰，我們在秒殺專案的程式碼上增加介面：先刪除快取，再更新資料庫 OrderController中新增： ``` /** * 下單介面：先刪除快取，再更新資料庫 * @param sid * @return */ @RequestMapping("/createOrderWithCacheV1/{sid}") @ResponseBody public String createOrderWithCacheV1(@PathVariable int sid) { int count = 0; try { // 刪除庫存快取 stockService.delStockCountCache(sid); // 完成扣庫存下單事務 orderService.createPessimisticOrder(sid); } catch (Exception e) { LOGGER.error("購買失敗：[{}]", e.getMessage()); return "購買失敗，庫存不足"; } LOGGER.info("購買成功，剩餘庫存為: [{}]", count); return String.format("購買成功，剩餘庫存為：%d", count); } ``` stockService中新增： ``` @Override public void delStockCountCache(int id) { String hashKey = CacheKey.STOCK_COUNT.getKey() + "_" + id; stringRedisTemplate.delete(hashKey); LOGGER.info("刪除商品id：[{}] 快取", id); } ``` 其他涉及的程式碼都在之前三篇文章中有介紹，並且可以直接去Github拿到專案原始碼，就不在這裡重複貼了。 ### 實戰：先更新資料庫，再刪快取 如果是先更新資料庫，再刪快取，那麼程式碼只是在業務順序上顛倒了一下，這裡就只貼OrderController中新增： ``` /** * 下單介面：先更新資料庫，再刪快取 * @param sid * @return */ @RequestMapping("/createOrderWithCacheV2/{sid}") @ResponseBody public String createOrderWithCacheV2(@PathVariable int sid) { int count = 0; try { // 完成扣庫存下單事務 orderService.createPessimisticOrder(sid); // 刪除庫存快取 stockService.delStockCountCache(sid); } catch (Exception e) { LOGGER.error("購買失敗：[{}]", e.getMessage()); return "購買失敗，庫存不足"; } LOGGER.info("購買成功，剩餘庫存為: [{}]", count); return String.format("購買成功，剩餘庫存為：%d", count); } ``` ### 實戰：快取延時雙刪 如何做延時雙刪呢，最好的方法是開設一個執行緒池，線上程中刪除key，而不是使用Thread.sleep進行等待，這樣會阻塞使用者的請求。 更新前先刪除快取，然後更新資料，再延時刪除快取。 OrderController中新增介面： ``` // 延時時間：預估讀資料庫資料業務邏輯的耗時，用來做快取再刪除 private static final int DELAY_MILLSECONDS = 1000; /** * 下單介面：先刪除快取，再更新資料庫，快取延時雙刪 * @param sid * @return */ @RequestMapping("/createOrderWithCacheV3/{sid}") @ResponseBody public String createOrderWithCacheV3(@PathVariable int sid) { int count; try { // 刪除庫存快取 stockService.delStockCountCache(sid); // 完成扣庫存下單事務 count = orderService.createPessimisticOrder(sid); // 延時指定時間後再次刪除快取 cachedThreadPool.execute(new delCacheByThread(sid)); } catch (Exception e) { LOGGER.error("購買失敗：[{}]", e.getMessage()); return "購買失敗，庫存不足"; } LOGGER.info("購買成功，剩餘庫存為: [{}]", count); return String.format("購買成功，剩餘庫存為：%d", count); } ``` OrderController中新增執行緒池： ``` // 延時雙刪執行緒池 private static ExecutorService cachedThreadPool = new ThreadPoolExecutor(0, Integer.MAX_VALUE, 60L, TimeUnit.SECONDS,new Synchron