【搞定面試官】系列：當面試官問你如何保證緩存和數據庫雙寫一致性時，他到底想問什麼

面試開始

小夥子你好，看你簡歷上寫到了MySQL和Redis。今天咱們就圍繞他們兩個展開吧。Redis和MySQL是後端開發中舉重若輕的重要角色。實際開發中兩者也基本上形影不離，爲了提升性能和響應，Redis經常存放熱點數據，MySQL存放全部數據，保證數據持久化。因此Redis能夠說是MySQL的一部分數據。

那麼問題來了，當MySQL中的持久化數據發生改變，如何通知Redis呢？也即如何保證緩存和數據庫數據的雙寫一致性呢？

---

面試官您好，咱們在開發中採起的方案是：先更新數據庫，而後刪除相應緩存，直到下次請求緩存發現沒有數據，再從MySQL中讀取，同時將數據更新到Redis。

那爲何採用刪除緩存而不是更新緩存呢？

---

以下圖所示，若是採起更新緩存的方式，可能出現請求A先於請求B發生，更新緩存應該比請求B更新緩存早纔對，可是由於網絡等緣由，B卻比A更早更新了緩存，這就致使了髒數據。

其次，若是你是一個寫數據庫場景比較多，而讀數據場景比較少的業務需求，採用更新緩存的方案就會致使數據壓根還沒被讀取過，但緩存已被頻繁的更新，浪費性能。

那先刪除緩存，再更新數據庫會不會有什麼問題？

---

以下圖所示，請求A進行寫操做，刪除緩存，請求B查詢發現緩存不存在，就去數據庫查詢獲得舊值，以後將舊值寫入緩存，此時請求A再將新值寫入數據庫。
這種狀況就會致使數據不一致的情形出現。並且，若是不採用給緩存設置過時時間策略，該緩存數據永遠都是髒數據。

好的，剛剛說的方案確實在併發環境中都會有問題。那大家採用先更新數據庫，再刪除緩存，這種方案必定不會出現併發問題嗎？

---

答案是不必定，也可能會出現併發問題。以下圖所示，
當步驟Step3的更新數據庫操做比步驟Step2的讀取數據庫操做耗時更短，就有可能使得步驟Step4先於步驟Step5，此時緩存中的就是髒數據。但通常狀況下數據庫的讀操做的速度是遠快於寫操做的（此點從MySQL的併發讀寫量就可看出，相同硬件配置下併發讀的效率是併發寫的數倍）。

所以，若是你想實現基礎的緩存和數據庫雙寫一致的邏輯，那麼在大多數狀況下，在不想作過多設計、增長太大工做量的狀況下，請 先更新數據庫，再刪除緩存!

先更新數據庫，再刪除緩存，除了你剛剛說得問題，還會有別的問題嗎？

---

若是MySQL採用了讀寫分離架構，當請求A更新數據在master庫上並刪除了緩存，但此時數據庫主從同步還未完成。請求B查詢緩存發生Cache miss以後從slave庫上讀取到的仍是舊值，此時也會形成數據不一致。

你剛剛說到先更新數據庫，再刪除緩存也有可能形成數據不一致，怎麼解決呢？

---

採用延時雙刪。以下圖所示，請求A更新數據庫以後，爲防止刪除緩存先行發生於請求B的將緩存寫入舊值，能夠經過將請求A更新完數據庫以後休眠一會（例如100ms,200ms，根據實際業務場景擬定），再刪除緩存，這樣基本能保證緩存中存放的不會是髒數據。主從架構也是這個原理，就是請求A在更新master以後不用當即刪除緩存，經過延時雙刪保證主從同步已經完成，最後刪除緩存數據。

但你這種方案，請求A休眠一段時間的話，可能會影響到接口的RT，下降系統的吞吐量，如何解決呢？

---

這裏比較優雅的方案是經過異步實現。即開啓一個線程池，在請求A的時候開啓一個單獨的線程，異步的休眠一段時間而後執行緩存刪除。固然也能夠經過將緩存中相應的key扔到消息隊列，經過MQ異步刪除，但僅爲了異步刪除緩存就多加了一層消息隊列，可能會形成系統設計更加複雜，而且會帶來別的問題。

前面一直有提到刪除緩存，若是刪除緩存失敗了怎麼辦呢？

---

再加一個重試機制，保證刪除緩存成功。

若是我必定要數據庫和緩存數據一致性怎麼辦？

---

沒有辦法作到絕對的一致性，這是由CAP理論決定的，緩存系統適用的場景就是非強一致性的場景，因此它屬於CAP中的AP。

CAP理論是分佈式系統中的經典理論，即一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）。

根據BASE（Basically Available，Soft State和Eventually Consistent）理論，緩存和數據庫只能作到數據的最終一致性。

面試結束

時間也不早了，今天就到這裏吧，看出來小夥子對這塊掌握的比較深刻。咱們公司就缺乏你這種人才，要不如今就籤把Offer簽了吧。
這個時候你確定欲絕還迎，一手接Offer一邊擺擺手：不行不行，深圳馬那邊也急着等我給回覆呢，催了我好幾天了。
面試官一聽，payroll組何在，加價！

小結

使用緩存並非一個很簡單的事情，尤爲在須要緩存與數據庫保持強一致的場景，才知道讓數據庫數據和緩存數據保持一致性是一門很高深的學問。從遠古的硬件緩存，操做系統緩存開始，緩存就是一門獨特的學問。這個問題也被業界探討了很是久，爭論至今也無果，由於其實這是一個權衡的問題。我是少俠露飛，愛技術，愛分享。