“

現在如果說不出幾句如何保證數據一致性方案的話，覺得出去面試都丟人,尤其是緩存和數據庫的數據一致性

“

全程無圖，請謹慎閱讀

緩存對于程序性能而言，無疑是個殺手锏，但不是完美的解決方案。關鍵在于緩存的物理位置和數據真實保存的位置是分離的，當然這里指的是分布式緩存方案。位于不同物理位置的兩份數據要想保證強一致性，理論上來說是不可能的。

但是，程序員總是愛創造奇跡。

單說數據庫，程序員們創造了事務特性，就是平時面試經常問的ACID特性的一個愛稱。至于ACID的概念是什么，簡單的抄襲一下：

“

ACID，是指數據庫管理系統（DBMS）在寫入或更新資料的過程中，為保證事務（transaction）是正確可靠的，所必須具備的四個特性：原子性（atomicity，或稱不可分割性）、一致性（consistency）、隔離性（isolation，又稱獨立性）、持久性（durability）。

• Atomicity（原子性）：一個事務（transaction）中的所有操作，要么全部完成，要么全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被恢復（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。

• Consistency（一致性）：在事務開始之前和事務結束以后，數據庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設規則，這包含資料的精確度、串聯性以及后續數據庫可以自發性地完成預定的工作。

• Isolation（隔離性）：數據庫允許多個并發事務同時對其數據進行讀寫和修改的能力，隔離性可以防止多個事務并發執行時由于交叉執行而導致數據的不一致。事務隔離分為不同級別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重復讀（repeatable read）和串行化（Serializable）。

• Durability（持久性）：事務處理結束后，對數據的修改就是永久的，即便系統故障也不會丟失。

回歸正題，存放緩存數據的設備能否也提供事務特性呢？如果可以，是否也能夠提供完整的ACID特性呢？

如果你看過幾篇緩存和DB一致性的文章就會發現，無論你先更新DB后更新緩存，還是先更新緩存后更新DB，或是先更新DB后刪除緩存.....無論怎么折騰，都不能保證數據的強一致性。

悲哀嗎？看了這么多文章居然不能解決這個問題。

“

多個不同的外部設備數據要想保證強一致性，除非都能提供事務的接口，還需要引入事務協調器

拿緩存和數據庫的一致性保證來說，沒有協調器根本不可能保證強一致性。所以業務讓步了：保證最終一致性即可

最終一致性容易保證嗎？其實也不容易

看有些人已經給你出解決方案了：引入MQ。因為MQ一是能保證消息的可靠性到達和可靠性消費，二是MQ是解耦利器。很多數據一致性的方案都會借助MQ的特性來做最終一致性。

分布式的鐵律CAP原則，大家都應該知道，但是我覺得最應該熟記的是BASE理論。

利用MQ來做數據庫和緩存一致性，本質上也屬于BASE理論的實踐。在業務上做出讓步，遺漏短暫的中間狀態來達到最終目的。

分布式鎖可行嗎

客戶端可以讀到錯誤數據的原因源自數據的中間狀態，如果在數據變動的整個過程不允許其他請求讀取也可以達到數據上的強一致性。

什么意思呢？在一個數據的變動過程中，不允許其他請求進來，等到緩存和數據庫全部修改完成再允許其他請求進來，這就是業務上的分布式鎖控制一致性方案。

無奈，一般的分布式鎖性能都比較低，這個低是對比無鎖的情況下來對比的，相對于肉眼時間，還是很快的。最主要的是，如果引入分布式鎖的技術，那又將面臨分布式鎖的一系列問題。

“

最后強調一點：緩存一定要設置過期時間，這是保證最終一致性的兜底方案

往期回顧

#

愚蠢的領導才會用程序員祭天！！

#

【另類見解】秒殺并非高不可攀

#

我把負載均衡講出了花，領導卻不給我漲工資

#

一個搜索需求搞垮微服務

總結

以上是生活随笔為你收集整理的【另类见解】那些要保证缓存和数据库数据一致性的最后怎么了？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。