前言我們在日常工作中經常會遇到要求快取和資料庫強一致性的問題，我們平常的做法是，確保資料庫插入成功，然後再更新快取，但有時候資料庫插入成功後，快取出現問題或者快取系統掛了，這時候請求會直接訪問資料庫最新的資料，但是當快取恢復的時候，我們的併發請求又會訪問到以前舊的快取資料，這時候就會出現不一致問題。如果我們的業務系統對一致性要求不高，那麼可以這麼做，但是如果必須是強一致性，那麼這個方案是有明顯漏洞的。
方案一講解
paste_image.png
注：同樣我們是同時寫資料庫和快取，但是在寫快取的時候會判斷寫入是否成功，如果寫入出錯，我們將key和更新狀態值插入到資料庫狀態表中，同時關閉前端訪問快取的開關。
paste_image.png
注：客戶端在讀資料的時候，要先判斷一下當然開關是否開啟，如果開啟則讀取快取，如果關閉則直接訪問資料庫。關於判斷快取開關的問題，可以不用每次讀庫，而可以事先快取到本地。
paste_image.png
注：後台有乙個守護定時任務，每隔一定時間來檢測快取系統是否可用，如果可用則從狀態表中讀取key值和更新狀態位，然後開啟快取讀取開關，這樣前端資料讀取端則能夠從快取讀取最新資料。
這方案的前提是當前併發量並不是非常大的情況，試想如果當前併發非常大，同時快取又出了問題，這時候整個請求就穿透到了資料庫層造成嚴重問題。
那麼我之前的初步想法是將這個流程封裝為中介軟體，根據不同庫配置不同的資料來源，客戶端只需要直接請求中介軟體即可。但此方案不適合分庫分表的場景！在某種情況下是有侷限性的！這個方案更多是為大家提供一種思路！
方案二講解當快取不可用時，在第一時間不對資料庫服務發起請求，在需要的時候非同步填充快取（優先熱點快取），然後我們將前端的請求直接返回失敗，也就是快速返回失敗，直到快取恢復並且熱點快取填充完畢。
paste_image.png
注：在某些情況下，這種方法意義不大，但當系統的一部分發生故障時可以確保系統仍然可用的一種方式，讓請求快速失敗，確保不占用資源，也避免了級聯下游服務的故障。
快取和資料庫一致性
對應比較常用的資料，比如鑑權資料一般會放在快取中 比如 redis 這樣能夠跟快的實現讀取，所以一般讀取流程如下 目前網上有很多關於快取和資料庫怎麼保持一致性的文件，主要可以總結為如下幾點 1 先更新資料庫，在更新快取 2 先刪除快取，在更新資料庫 3 先更新資料庫，在刪除快取 下面將對著幾種機制作...
快取和資料庫一致性問題分析
問題 如何保證快取和資料庫雙寫的一致性 一般來說，如果允許快取可以稍微的跟資料庫偶爾有不一致的情況，也就是說如果你的系統不是嚴格要求 快取 資料庫 必須保持一致性的話，最好不要做這個方案，即 讀請求和寫請求序列化，串到乙個記憶體佇列裡去。序列化可以保證一定不會出現不一致的情況，但是它也會導致系統的吞...
怎麼保證快取和資料庫資料的一致性？
選擇淘汰快取 選擇先淘汰快取，再更新資料庫 原因 假如先更新資料庫，再淘汰快取，假如快取淘汰失敗，那麼後面的請求都會得到髒資料，直至快取過期。假如先淘汰快取再更新資料庫，如果資料庫更新失敗，只會產生一次快取miss，相比較而言，後者對業務影響更小一點。如下場景 同時有乙個請求a進行更新操作，另乙個請...