資料庫的數據一致性

1. 資料庫系統中 數據的一致性指的是什麼

同步更新。

簡單說來就是一條column的數據在多個表中保持同步更新， 一般用foreign key實現mapping

比如兩張表table1,table2

其中table1的uid column是primary key，table2的uid column是foreign key,

則當修改table1的uid column的一row時，table2的對應row也會自動更新。

(1)資料庫的數據一致性擴展閱讀：

常用的一致性模型有：

1、嚴格一致性（linearizability, strict/atomic Consistency）：讀出的數據始終為最近寫入的數據。這種一致性只有全局時鍾存在時才有可能，在分布式網路環境不可能實現。

2、順序一致性（sequential consistency）：所有使用者以同樣的順序看到對同一數據的操作，但是該順序不一定是實時的，等。

2. 資料庫中數據一致性是什麼意思，又是如何做到的

比如，你有兩張表一張是用戶表，用戶編號，用戶名稱，一張是借書表，用戶編號，書籍編號，這樣這里邊如果你更改了用戶表中的用戶編號的數據，那麼，對應的借書表中對應的用戶編號也要跟著更新，才能使數據保持一致，像這種的操作，在資料庫里可以設置級聯更新~

3. 什麼是資料庫一致性

資料庫一致性（Database
Consistency）
是指事務執行的結果必須是使資料庫從一個一致性狀態變到另一個一致性狀態。
保證資料庫一致性是指當事務完成時，必須使所有數據都具有一致的狀態。在關系型資料庫中，所有的規則必須應用到事務的修改上，以便維護所有數據的完整性。
保證資料庫的一致性是資料庫管理系統的一項功能.比如有兩個表(員工\職位),員工表中有員工代碼、姓名、職位代碼等屬性，職位表中有職位代碼、職位名稱、職位等級等屬性。你在其中員工表中進行了插入操作,你插入了一個新員工的信息，而這個新員工的職位是公司新創建的一個職位。如果沒有一致性的保證，就會出現有這么一個員工，但是不知道他到底擔當什麼職責！這個只是它的一個小小方面。
讀一致性也是資料庫一致性的一個重要方面,在實際中,我們會遇到這種情況:我們對一個表中的某些數據進行了更新操作,,但是還沒有進行提交,這時另外一個用戶讀取表中數據.這個時候就出現了讀一致性的問題:到底是讀什麼時候的數據呢?是更新前的還是更新後的?在DBMS中設有臨時表,它用來保存修改前的值,在沒有進行提交前讀取數據,會讀取臨時表中的數據,這樣一來就保證了數據是一致的.(當前用戶看到的是更新後的值)
但是還有一種情況:用戶user1對表進行了更新操作,用戶user2在user1還沒有進行提交前讀表中數據,而且是大批量的讀取(打個比方:耗時3分鍾)而在這3分鍾內user1進行了提交操作,那又會產生什麼影響呢?這個時候怎麼保證讀寫一致性呢?這個時候DBMS就要保證有足夠大的臨時表來存放修改前的數值,,以保證user2讀取的數據是修改前的一致數據.然後下次再讀取時候就是更新後的數據了.

4. 信息系統中的數據一致性是指資料庫中的數據類型一致，哪裡錯了

不是數據類型一致，是指資料庫中多個有關聯的表中數據需要一致。同一數據可能在不同表中，比如常見的學生管理系統中，學生表中有學生學號，成績表中有學生學號，一但學生表中某個學號刪除，那麼成績表中對應學號的成績記錄也不應該存在。這叫做信息系統中的數據一致性。

5. SQLServer資料庫中如何保持數據一致性

根據實現策略的不同，主要有快照復制、事務復制、合並復制等三種類型。這三種復制類型，各有各的特點，分別適用於不同的場合。一般來說，在考慮採用哪種復制類型比較合適的時候，主要考慮的是性能與數據同步的時間間復制是SQLServer資料庫中保持數據一致性的一種手段。根據實現策略的不同，主要有快照復制、事務復制、合並復制等三種類型。這三種復制類型，各有各的特點，分別適用於不同的場合。一般來說，在考慮採用哪種復制類型比較合適的時候，主要考慮的是性能與數據同步的時間間隔。那麼在什麼情形下比較適用快照復制呢?筆者就跟大家來討論一下這個話題。 為了在恰當的時候採用快照復制，資料庫管理員首先需要知道快照復制的特點。快照復制是指將數據以特定時刻的瞬時狀態轉發，而不堅實對數據的更新。在發生同步時，將生成完整的快照並將其發送到訂閱伺服器。簡單的說，快照復制就是每隔一段時間發生數據同步操作。而不是發布伺服器的數據一有更新就出發這個快照復制。顯然這種快照復制的數據同步性稍微差一點。在訂閱伺服器與發布伺服器之間有一段時間會存在數據不一致的情況。但是這可以在很大程度上提高訂閱伺服器與發布伺服器的性能。這就好像汽車運輸。採用快照復制的話可以將一個集裝箱裝滿後在送貨，而不是有多少送多少。掌握這個資料庫復快照復制的具體特點之後，資料庫管理員就可以來考慮在什麼情況下，採用快照復制更加的合理。 一、數據更改比較少的系統中。 快照復制與其他復制相比最主要的缺陷就是資料庫中的數據無法及時同發布伺服器一致。為此如果發布伺服器中的內容很少更改的話，顯然此時採用快照復制是比較合理的。此時採用快照復制的話，不僅數據一致性延遲的負面效應會越來越不明顯，同時可以提高發布伺服器與訂閱伺服器的性能。如在實際工作中，經常會遇到這樣的客戶。如一家企業在各地都有辦事處或者銷售機構，就像肯德基一樣，各地的產品價格基本上都是相同的，不怎麼會更改。即使更改的話，各地也是統一調整。由於此時產品價格表更改的比較少，那麼在企業總部的資料庫服務與各地的訂閱伺服器之間，採用快照復制的形式就會比較合適。其實類似的情況有很多。如不少的服裝企業，像李寧、耐克等等，他們不僅自己生產，而且在各地又有自己的銷售辦事處。在價格方面也是統一的。在這種情況下，採用快照復制往往能夠提高資料庫復制的性能，同時又不影響其使用。 二、在某個時段內會出現數據大量的更改。 需要補充說明的一點是，上面說到的數據不怎麼發生更改，指的是數據的延續性更改。如在一年中，每天或者每個小時更改的數據都比較平均。此時採用快照復制不怎麼合適。但是如果數據的更改集中在一個時段內。而其他時間中資料庫的內容不會有多大的更改。此時採用快照復制是可行的。如一些決策性系統，往往在起初導入數據的時候，需要進行大量的更改。而等到數據導入完畢，在大家對數據進行分析時，則資料庫中的內容基本上保持不變。在這種情況下，筆者認為只要數據的更新集中在一個固定的時段，此時採用快照復制仍然是可行的。 再如上面這個KFC或者服裝企業的案例中，如果市場部門維護一個產品的價格，而且這些價格往往在一個固定的時間進行幾次更新。如在換季的時候會進行一些促銷。此時資料庫管理員可以在數據更新完畢後立即執行復制完成的數據快照。所以，以數據更新來判斷是否適合採用快照復制，標准並不是數據的更新量。像上面提到的分析決策系統，其起初的數據更新量可能比有些資料庫系統幾年的數據更新量都要大。筆者認為，主要是根據數據更新的頻率來進行判斷。如果數據更新的比較頻繁，那麼即使數據更新的數據不多，像那種細水長流似的更新，則不適合採用快照復制。而那些井噴似的數據更新，所有的更新都集中在一個固定的時刻，那麼此時採用快照復制是比較合理的。 三、在一段時間內是否允許具有相對發布伺服器已過時的數據副本? 現在不少超市也已經連鎖了，如世紀聯華等等。為了提高利潤，增加市場的份額，這些超市紛紛推出了沖值卡，即消費者先將一定金額的人民幣打入到沖值卡中。然後每次消費完成後從卡中扣費。但前些天經常有新聞報道，說一個客戶的消費卡在一家聯華超市掛失了。但是撿到這張卡的人仍然可以在其他的聯華超市中消費。為此消費者就想不明白了，為什麼掛失了的消費卡仍然可以在其他超市中消費?掛失後的損失該由誰來承擔呢?其實這就使超市在不適當的時候採用了快照復制所造成的。由於採用快照復制，在各個聯華超市的資料庫之間數據無法在短時間內取得一致。如有些商戶說掛失當日之內的損失他們不承擔，這就說明他們可能是每天下班後進行一次快照復制。一般情況下這不會有問題。但是像遇到消費卡被偷了等情況，就會遇到類似的問題了。 所以，在考慮是否適合採用快照復制的時候，還需要考慮在一段時間內是否允許具有相對發布伺服器來說已過時的數據副本。如果不允許的話，那麼就不允許採用這個快照復制。如果允許的話，那麼資料庫管理員就需要評估這段時間最長是多少。如果是24個小時，那麼就需要每隔24小時進行一次快照復制。但是需要注意的是，如果時間的間隔比較短，如才允許十分鍾的數據延遲，那麼採用快照復制就沒有必要了。此時採用事務復制或則和合並復制可能更加的合適。 四、復制少量的數據。 快照復制跟其他復制類型相比，還有一個比較顯著的特點，即當發生數據同步時，將生成完整的快照並將其從發布伺服器傳送到訂閱伺服器。這是一個什麼概念呢?如訂閱伺服器中有10G的數據，而在一個快照復制的周期內，只有1M的數據發生了更改。此時發生快照復制的話，資料庫系統會將10G的數據都傳送到訂閱伺服器上。此時更改的數據只有1M，卻需要在網路上傳送10G的數據流量，顯然會對企業的網路產生比較大的壓力。由於在發布伺服器上快照復制的連續開銷低於事務復制的開銷，一次資料庫系統不會啟用跟蹤增量更改。但是像這種情況，如果要復制的數據量非常的大，而平時的更新又不多。此時資料庫系統要生成和應用快照，就將耗用大量的資源，包括網路資源和伺服器資源。所以說，當發布伺服器中的數據比較多時，採用快照復制不怎麼合適。因為此時網路傳輸反而會成為其最重大的瓶頸資源。相反若能夠採取細水長流的事務復制策略，那麼對於企業網路性能的影響就會小的多，甚至可以忽略不計。 所以在採用快照復制的時候，資料庫管理員一定要明白，快照復制會傳送整個資料庫對象。從而在快照復制傳輸過程中會侵蝕大量的網路帶寬，從而明顯的降低企業網路的性能，甚至導致網路擁塞。有時候為了保障快照能夠准確、迅速的傳遞到其他的訂閱伺服器，還不得不採用VPN等技術來保障傳輸的准確性。為此，筆者認為只有發布伺服器的資料庫並不是很大的情況下，才適合採用快照復制。否則的話，採用快照復制是得不償失。 從以上的分析中，可以得到一個結論。在考慮採用快照復制是否合適時，往往不能夠採用一個指標來判斷。而需要考慮多個因素，如資料庫的大小、數據更新的頻率、允許數據延遲的時間等等因素來進行判斷。最後在數據的一致性與資料庫的性能之間取得一個均衡。說實話，對於大部分資料庫管理員來說，要做出一個抉擇，確實有困難。因為這沒有固定的指標可以拿來參考。如資料庫容量小於多少時該採用快照復制。任何一個資料庫管理專家都不能夠下這個結論。所以在掌握影響其選擇的相關因素外，就要依靠資料庫管理員的經驗了。在遇到類似的選擇題時，往往經驗可以幫助管理員迅速解決問題。最後需要提醒的是，無論最終採取了什麼方案，最好能夠持續跟蹤一段時間，看看自己的選擇是否合理。

6. 如何保證資料庫緩存的最終一致性

對於互聯網業務來說，傳統的直接訪問資料庫方式，主要通過數據分片、一主多從等方式來扛住讀寫流量，但隨著數據量的積累和流量的激增，僅依賴資料庫來承接所有流量，不僅成本高、效率低、而且還伴隨著穩定性降低的風險。

鑒於大部分業務通常是讀多寫少（讀取頻率遠遠高於更新頻率），甚至存在讀操作數量高出寫操作多個數量級的情況。因此， 在架構設計中，常採用增加緩存層來提高系統的響應能力 ，提升數據讀寫性能、減少資料庫訪問壓力，從而提升業務的穩定性和訪問體驗。

根據 CAP 原理，分布式系統在可用性、一致性和分區容錯性上無法兼得，通常由於分區容錯無法避免，所以一致性和可用性難以同時成立。對於緩存系統來說， 如何保證其數據一致性是一個在應用緩存的同時不得不解決的問題 。

需要明確的是，緩存系統的數據一致性通常包括持久化層和緩存層的一致性、以及多級緩存之間的一致性，這里我們僅討論前者。持久化層和緩存層的一致性問題也通常被稱為雙寫一致性問題，「雙寫」意為數據既在資料庫中保存一份，也在緩存中保存一份。

對於一致性來說，包含強一致性和弱一致性 ，強一致性保證寫入後立即可以讀取，弱一致性則不保證立即可以讀取寫入後的值，而是盡可能的保證在經過一定時間後可以讀取到，在弱一致性中應用最為廣泛的模型則是最終一致性模型，即保證在一定時間之後寫入和讀取達到一致的狀態。對於應用緩存的大部分場景來說，追求的則是最終一致性，少部分對數據一致性要求極高的場景則會追求強一致性。

為了達到最終一致性，針對不同的場景，業界逐步形成了下面這幾種應用緩存的策略。

— 1 —

Cache-Aside

Cache-Aside 意為旁路緩存模式，是應用最為廣泛的一種緩存策略。下面的圖示展示了它的讀寫流程，來看看它是如何保證最終一致性的。在讀請求中，首先請求緩存，若緩存命中（cache hit），則直接返回緩存中的數據；若緩存未命中（cache miss），則查詢資料庫並將查詢結果更新至緩存，然後返回查詢出的數據（demand-filled look-aside ）。在寫請求中，先更新資料庫，再刪除緩存（write-invalidate）。

1、為什麼刪除緩存，而不是更新緩存？

在 Cache-Aside 中，對於讀請求的處理比較容易理解，但在寫請求中，可能會有讀者提出疑問，為什麼要刪除緩存，而不是更新緩存？站在符合直覺的角度來看，更新緩存是一個容易被理解的方案，但站在性能和安全的角度，更新緩存則可能會導致一些不好的後果。

首先是性能 ，當該緩存對應的結果需要消耗大量的計算過程才能得到時，比如需要訪問多張資料庫表並聯合計算，那麼在寫操作中更新緩存的動作將會是一筆不小的開銷。同時，當寫操作較多時，可能也會存在剛更新的緩存還沒有被讀取到，又再次被更新的情況（這常被稱為緩存擾動），顯然，這樣的更新是白白消耗機器性能的，會導致緩存利用率不高。

而等到讀請求未命中緩存時再去更新，也符合懶載入的思路，需要時再進行計算。刪除緩存的操作不僅是冪等的，可以在發生異常時重試，而且寫-刪除和讀-更新在語義上更加對稱。

其次是安全 ，在並發場景下，在寫請求中更新緩存可能會引發數據的不一致問題。參考下面的圖示，若存在兩個來自不同線程的寫請求，首先來自線程 1 的寫請求更新了資料庫（step 1），接著來自線程 2 的寫請求再次更新了資料庫（step 3），但由於網路延遲等原因，線程 1 可能會晚於線程 2 更新緩存（step 4 晚於 step 3），那麼這樣便會導致最終寫入資料庫的結果是來自線程 2 的新值，寫入緩存的結果是來自線程 1 的舊值，即緩存落後於資料庫，此時再有讀請求命中緩存（step 5），讀取到的便是舊值。

2、為什麼先更新資料庫，而不是先刪除緩存？

另外，有讀者也會對更新資料庫和刪除緩存的時序產生疑問，那麼為什麼不先刪除緩存，再更新資料庫呢？在單線程下，這種方案看似具有一定合理性，這種合理性體現在刪除緩存成功。

但更新資料庫失敗的場景下，盡管緩存被刪除了，下次讀操作時，仍能將正確的數據寫回緩存，相對於 Cache-Aside 中更新資料庫成功，刪除緩存失敗的場景來說，先刪除緩存的方案似乎更合理一些。那麼，先刪除緩存有什麼問題呢？

問題仍然出現在並發場景下，首先來自線程 1 的寫請求刪除了緩存（step 1），接著來自線程 2 的讀請求由於緩存的刪除導致緩存未命中，根據 Cache-Aside 模式，線程 2 繼而查詢資料庫（step 2），但由於寫請求通常慢於讀請求，線程 1 更新資料庫的操作可能會晚於線程 2 查詢資料庫後更新緩存的操作（step 4 晚於 step 3），那麼這樣便會導致最終寫入緩存的結果是來自線程 2 中查詢到的舊值，而寫入資料庫的結果是來自線程 1 的新值，即緩存落後於資料庫，此時再有讀請求命中緩存（ step 5 ），讀取到的便是舊值。

另外，先刪除緩存，由於緩存中數據缺失，加劇資料庫的請求壓力，可能會增大緩存穿透出現的概率。

3、如果選擇先刪除緩存，再更新資料庫，那如何解決一致性問題呢？

為了避免「先刪除緩存，再更新資料庫」這一方案在讀寫並發時可能帶來的緩存臟數據，業界又提出了延時雙刪的策略，即在更新資料庫之後，延遲一段時間再次刪除緩存，為了保證第二次刪除緩存的時間點在讀請求更新緩存之後，這個延遲時間的經驗值通常應稍大於業務中讀請求的耗時。

延遲的實現可以在代碼中 sleep 或採用延遲隊列。顯而易見的是，無論這個值如何預估，都很難和讀請求的完成時間點准確銜接，這也是延時雙刪被詬病的主要原因。

4、那麼 Cache-Aside 存在數據不一致的可能嗎？

在 Cache-Aside 中，也存在數據不一致的可能性。在下面的讀寫並發場景下，首先來自線程 1 的讀請求在未命中緩存的情況下查詢資料庫（step 1），接著來自線程 2 的寫請求更新資料庫（step 2），但由於一些極端原因，線程 1 中讀請求的更新緩存操作晚於線程 2 中寫請求的刪除緩存的操作（step 4 晚於 step 3），那麼這樣便會導致最終寫入緩存中的是來自線程 1 的舊值，而寫入資料庫中的是來自線程 2 的新值，即緩存落後於資料庫，此時再有讀請求命中緩存（step 5），讀取到的便是舊值。

這種場景的出現，不僅需要緩存失效且讀寫並發執行，而且還需要讀請求查詢資料庫的執行早於寫請求更新資料庫，同時讀請求的執行完成晚於寫請求。足以見得，這種 不一致場景產生的條件非常嚴格，在實際的生產中出現的可能性較小 。

除此之外，在並發環境下，Cache-Aside 中也存在讀請求命中緩存的時間點在寫請求更新資料庫之後，刪除緩存之前，這樣也會導致讀請求查詢到的緩存落後於資料庫的情況。

雖然在下一次讀請求中，緩存會被更新，但如果業務層面對這種情況的容忍度較低，那麼可以採用加鎖在寫請求中保證「更新資料庫&刪除緩存」的串列執行為原子性操作（同理也可對讀請求中緩存的更新加鎖）。 加鎖勢必會導致吞吐量的下降，故採取加鎖的方案應該對性能的損耗有所預期。

— 2 —

補償機制

我們在上面提到了，在 Cache-Aside 中可能存在更新資料庫成功，但刪除緩存失敗的場景，如果發生這種情況，那麼便會導致緩存中的數據落後於資料庫，產生數據的不一致的問題。

其實，不僅 Cache-Aside 存在這樣的問題，在延時雙刪等策略中也存在這樣的問題。針對可能出現的刪除失敗問題，目前業界主要有以下幾種補償機制。

1、刪除重試機制

由於同步重試刪除在性能上會影響吞吐量，所以常通過引入消息隊列，將刪除失敗的緩存對應的 key 放入消息隊列中，在對應的消費者中獲取刪除失敗的 key ，非同步重試刪除。這種方法在實現上相對簡單，但由於刪除失敗後的邏輯需要基於業務代碼的 trigger 來觸發 ，對業務代碼具有一定入侵性。

鑒於上述方案對業務代碼具有一定入侵性，所以需要一種更加優雅的解決方案，讓緩存刪除失敗的補償機制運行在背後，盡量少的耦合於業務代碼。一個簡單的思路是通過後台任務使用更新時間戳或者版本作為對比獲取資料庫的增量數據更新至緩存中，這種方式在小規模數據的場景可以起到一定作用，但其擴展性、穩定性都有所欠缺。

一個相對成熟的方案是基於 MySQL 資料庫增量日誌進行解析和消費，這里較為流行的是阿里巴巴開源的作為 MySQL binlog 增量獲取和解析的組件 canal（類似的開源組件還有 Maxwell、Databus 等）。

canal sever 模擬 MySQL slave 的交互協議，偽裝為 MySQL slave，向 MySQL master 發送 mp 協議，MySQL master 收到 mp 請求，開始推送 binary log 給 slave （即 canal sever ），canal sever 解析 binary log 對象（原始為 byte 流），可由 canal client 拉取進行消費，同時 canal server 也默認支持將變更記錄投遞到 MQ 系統中，主動推送給其他系統進行消費。

在 ack 機制的加持下，不管是推送還是拉取，都可以有效的保證數據按照預期被消費。當前版本的 canal 支持的 MQ 有 Kafka 或者 RocketMQ。另外， canal 依賴 ZooKeeper 作為分布式協調組件來實現 HA ，canal 的 HA 分為兩個部分：

那麼，針對緩存的刪除操作便可以在 canal client 或 consumer 中編寫相關業務代碼來完成。這樣，結合資料庫日誌增量解析消費的方案以及 Cache-Aside 模型，在讀請求中未命中緩存時更新緩存（通常這里會涉及到復雜的業務邏輯），在寫請求更新資料庫後刪除緩存，並基於日誌增量解析來補償資料庫更新時可能的緩存刪除失敗問題，在絕大多數場景下，可以有效的保證緩存的最終一致性。

另外需要注意的是，還應該隔離事務與緩存，確保資料庫入庫後再進行緩存的刪除操作。 比如考慮到資料庫的主從架構，主從同步及讀從寫主的場景下，可能會造成讀取到從庫的舊數據後便更新了緩存，導致緩存落後於資料庫的問題，這就要求對緩存的刪除應該確保在資料庫操作完成之後。所以，基於 binlog 增量日誌進行數據同步的方案，可以通過選擇解析從節點的 binlog，來避免主從同步下刪除緩存過早的問題。

3、數據傳輸服務 DTS

— 3 —

Read-Through

Read-Through 意為讀穿透模式，它的流程和 Cache-Aside 類似，不同點在於 Read-Through 中多了一個訪問控制層，讀請求只和該訪問控制層進行交互，而背後緩存命中與否的邏輯則由訪問控制層與數據源進行交互，業務層的實現會更加簡潔，並且對於緩存層及持久化層交互的封裝程度更高，更易於移植。

— 4 —

Write-Through

Write-Through 意為直寫模式，對於 Write-Through 直寫模式來說，它也增加了訪問控制層來提供更高程度的封裝。不同於 Cache-Aside 的是，Write-Through 直寫模式在寫請求更新資料庫之後，並不會刪除緩存，而是更新緩存。

這種方式的 優勢在於讀請求過程簡單 ，不需要查詢資料庫更新緩存等操作。但其劣勢也非常明顯，除了上面我們提到的更新資料庫再更新緩存的弊端之外，這種方案還會造成更新效率低，並且兩個寫操作任何一次寫失敗都會造成數據不一致。

如果要使用這種方案， 最好可以將這兩個操作作為事務處理，可以同時失敗或者同時成功，支持回滾，並且防止並發環境下的不一致 。另外，為了防止緩存擾動的頻發，也可以給緩存增加 TTL 來緩解。

站在可行性的角度，不管是 Write-Through 模式還是 Cache-Aside 模式，理想狀況下都可以通過分布式事務保證緩存層數據與持久化層數據的一致性，但在實際項目中，大多都對一致性的要求存在一些寬容度，所以在方案上往往有所折衷。

Write-Through 直寫模式適合寫操作較多，並且對一致性要求較高的場景，在應用 Write-Through 模式時，也需要通過一定的補償機制來解決它的問題。首先，在並發環境下，我們前面提到了先更新資料庫，再更新緩存會導致緩存和資料庫的不一致，那麼先更新緩存，再更新資料庫呢？

這樣的操作時序仍然會導致下面這樣線程 1 先更新緩存，最後更新資料庫的情況，即由於線程 1 和 線程 2 的執行不確定性導致資料庫和緩存的不一致。這種由於線程競爭導致的緩存不一致，可以通過分布式鎖解決，保證對緩存和資料庫的操作僅能由同一個線程完成。對於沒有拿到鎖的線程，一是通過鎖的 timeout 時間進行控制，二是將請求暫存在消息隊列中順序消費。

在下面這種並發執行場景下，來自線程 1 的寫請求更新了資料庫，接著來自線程 2 的讀請求命中緩存，接著線程 1 才更新緩存，這樣便會導致線程 2 讀取到的緩存落後於資料庫。同理，先更新緩存後更新資料庫在寫請求和讀請求並發時，也會出現類似的問題。面對這種場景，我們也可以加鎖解決。

另在，在 Write-Through 模式下，不管是先更新緩存還是先更新資料庫，都存在更新緩存或者更新資料庫失敗的情況，上面提到的重試機制和補償機制在這里也是奏效的。

— 5 —

Write-Behind

Write behind 意為非同步回寫模式，它也具有類似 Read-Through/Write-Through 的訪問控制層，不同的是，Write behind 在處理寫請求時，只更新緩存而不更新資料庫，對於資料庫的更新，則是通過批量非同步更新的方式進行的，批量寫入的時間點可以選在資料庫負載較低的時間進行。

在 Write-Behind 模式下，寫請求延遲較低，減輕了資料庫的壓力，具有較好的吞吐性。但資料庫和緩存的一致性較弱，比如當更新的數據還未被寫入資料庫時，直接從資料庫中查詢數據是落後於緩存的。同時，緩存的負載較大，如果緩存宕機會導致數據丟失，所以需要做好緩存的高可用。顯然，Write behind 模式下適合大量寫操作的場景，常用於電商秒殺場景中庫存的扣減。

— 6 —

Write-Around

如果一些非核心業務，對一致性的要求較弱，可以選擇在 cache aside 讀模式下增加一個緩存過期時間，在寫請求中僅僅更新資料庫，不做任何刪除或更新緩存的操作，這樣，緩存僅能通過過期時間失效。這種方案實現簡單，但緩存中的數據和資料庫數據一致性較差，往往會造成用戶的體驗較差，應慎重選擇。

— 7 —

總結

在解決緩存一致性的過程中，有多種途徑可以保證緩存的最終一致性，應該根據場景來設計合適的方案，讀多寫少的場景下，可以選擇採用「Cache-Aside 結合消費資料庫日誌做補償」的方案，寫多的場景下，可以選擇採用「Write-Through 結合分布式鎖」的方案 ，寫多的極端場景下，可以選擇採用「Write-Behind」的方案。

7. 如何檢查資料庫中數據的一致性

資料庫一致性檢查(dbcc)提供了一些命令用於檢查資料庫的邏輯和物理一致性。Dbcc主要有兩個功能： 使用checkstorage 或 checktable 及 checkdb 在頁一級和行一級檢查頁鏈及數據指針。 使用checkstorage, checkalloc, 或 checkverify, tablealloc, 及indexalloc 檢查頁分配。 在下列情況中需要使用 dbcc 命令： 作為資料庫日常維護工作的一部分, 資料庫內部結構的完整性決定於sa 或dbo 定期地運行 dbcc 檢查。 在系統報錯以後, 確定資料庫是否有損壞。 在備份資料庫之前, 確保備份的完整性。 如果懷疑資料庫有損壞時, 例如, 使用某個表時報出表損壞的信息, 可以使用 dbcc 確定資料庫中其他表是否也有損壞。 下面是dbcc的簡單用法： dbcc checktable (table_name) 檢查指定的表, 檢查索引和數據頁是否正確鏈接, 索引是否正確排序, 所有指針是否一致, 每頁的數據信息是否合理, 頁偏移是否合理。 dbcc checkdb (database_name) 對指定資料庫的所有表做和checktable 一樣的檢查。 dbcc checkalloc (database_name,fix|nofix) 檢查指定資料庫, 是否所有頁面被正確分配, 是否被分配的頁面沒被使用。當使用"fix"選項時，在檢查資料庫的同時會自動修復有問題的頁面。（若資料庫數據量很大，則該過程會持續很長時間。） dbcc tablealloc (table_name,fix|nofix) 檢查指定的表, 是否所有頁面被正確分配, 是否被分配的頁面沒被使用。是 checkalloc 的縮小版本, 對指定的表做完整性檢查。當使用"fix"選項時，在檢查數據表的同時會自動修復數據表中有問題的頁面。 關於上述命令的其它選項及詳細使用方法和checkstorage, checkverify, indexalloc 的詳細使用方法, 請參閱有關命令手冊。

8. 資料庫事務一致性

一致性（Consistent）(Consistency) 事務在完成時，必須使所有的數據都保持一致狀態。在相關資料庫中，所有規則都必須應用於事務的修改，以保持所有數據的完整性。事務結束時，所有的內部數據結構（如 B 樹索引或雙向鏈表）都必須是正確的。某些維護一致性的責任由應用程序開發人員承擔，他們必須確保應用程序已強制所有已知的完整性約束。如，當開發用於轉賬的應用程序時，應避免在轉賬過程中任意移動小數點。隔離性（Insulation）(Isolation) 由並發事務所作的修改必須與任何其它並發事務所作的修改隔離。事務查看數據時數據所處的狀態，要麼是另一並發事務修改它之前的狀態，要麼是另一事務修改它之後的狀態，事務不會查看中間狀態的數據。這稱為隔離性，因為它能夠重新裝載起始數據，並且重播一系列事務，以使數據結束時的狀態與原始事務執行的狀態相同。當事務可序列化時將獲得最高的隔離級別。在此級別上，從一組可並行執行的事務獲得的結果與通過連續運行每個事務所獲得的結果相同。由於高度隔離會限制可並行執行的事務數，所以一些應用程序降低隔離級別以換取更大的吞吐量。持久性（Duration）(Durability） 事務完成之後，它對於系統的影響是永久性的。該修改即使出現致命的系統故障也將一直保持。

9. 如何理解資料庫事務中的一致性的概念

定義：資料庫一致性（Database Consistency）是指事務執行的結果必須是使資料庫從一個一致性狀態變到另一個一致性狀態。

資料庫狀態如何變化？每一次數據變更就會導致資料庫的狀態遷移。如果資料庫的初始狀態是C0，第一次事務T1的提交就會導致系統生成一個SYSTEM CHANGE NUMBER（SCN），這是資料庫狀態從C0轉變成C1。執行第二個事務T2的時候資料庫狀態從T1變成T2，以此類推，執行第Tn次事務的時候資料庫狀態由C(n-1)變成Cn。

定義一致性主要有2個方面，一致讀和一致寫。

一致寫：事務執行的數據變更只能基於上一個一致的狀態，且只能體現在一個狀態中。T(n)的變更結果只能基於C(n-1)，C(n-2), ...C(1)狀態，且只能體現在C(n)狀態中。也就是說，一個狀態只能有一個事務變更數據，不允許有2個或者2個以上事務在一個狀態中變更數據。至於具體一致寫基於哪個狀態，需要判斷T(n)事務是否和T(n-1)，T(n-2),...T(1)有依賴關系。

一致讀：事務讀取數據只能從一個狀態中讀取，不能從2個或者2個以上狀態讀取。也就是T(n)只能從C(n-1），C(n-2)... C(1)中的一個狀態讀取數據，不能一部分數據讀取自C(n-1)，而另一部分數據讀取自C(n-2)。

擺事實

一致寫：
定義100個事務T(1)...T(100)實現相同的邏輯 update table set i=i+1，i的初始值是0，那麼並發執行這100個事務之後i的值是多少？可能很容易想到是100。那麼怎麼從一致性角度去理解呢？

資料庫隨機調度到T(50)執行，此時資料庫狀態是C(0)，而其它事務都和T(50)有依賴關系，根據寫一致性原理，其它事務必須等到T(50)執行完畢後資料庫狀態變為C(1)才可以執行。因此資料庫利用鎖機制阻塞其它事務的執行。直到T(50)執行完畢，資料庫狀態從C(0)遷移到C(1)。資料庫喚醒其它事務後隨機調度到T(89)執行，以此類推直到所有事務調度執行完畢，資料庫狀態最終變為C(100)。

一致讀：
還是上面的例子，假設T(1)...T(100)順序執行，在不同的時機執行select i from table，我們看到i的值是什麼？
1. T(1)的執行過程中。資料庫狀態尚未遷移，讀到的i=0
2. T(1)執行完畢，T(2)的執行過程中，資料庫狀態遷移至C(1)，讀到的i=1