㈠ 技術分享 | 兩個單機 MySQL 該如何校驗數據一致性
業務有兩個 MySQL 集群是通過 MQ 進行同步的，昨晚 MQ 出現異常，報了很多主鍵沖突，想請 dba 幫忙校驗一下兩個集群的數據是否一致。
當接到這個需求的時候並沒當回事，隱約有點印象 pt-table-checksum 能通過 dsn 實現 MySQL 的數據校驗，所以當時就應承下來了。不曾想，啪啪打臉，回想起來真是草率了。
本文參考的是 pt-table-checksum 的校驗邏輯，基於數據塊去遍歷每個表，然後比對 checksum 的值判斷該塊是否一致，本文主要是想聊聊我在實現數據校驗腳本過程中遇到的問題以及解決思路，希望對大家有幫助。
利用線上的配置文件搭建一套主從環境。
這個用例將通過 dsn 方式連接從庫。
這個用例將通過 dsn 方式連接從庫，但是會將從庫的復制鏈路 stop 掉，並清空復制信息。
熟悉 pt-table-checksum 的朋友應該都知道，該工具是基於主鍵(非空唯一鍵)進行掃描數據行，其實這個邏輯針對整型單列主鍵實現起來很簡單，但是如果是聯合主鍵且是字元型，好像就沒那麼簡單了，有興趣的可以思考一下。下面我先說一下大致的邏輯：
第一步：判斷 _min_rowid 是否為空，為空就取該表的第一行，並記作 _min_rowid 。
第二步：根據 _min_rowid 作為條件進行掃描該表，取下一個數據塊的數據，記錄數據塊的最後一行數據的主鍵值，記錄 checksum 的值，並記下 _min_rowid 。
第三步：判斷_min_rowid是否為空，非空重復第二步，為空退出檢查。
通過上述三個步驟可以看到，如果是單列整型的主鍵，實現起來很簡單，但是問題來了，業務的表的主鍵五花八門，有的是聯合主鍵，有的是字元型的聯合主鍵，還有整型+字元型的聯合主鍵，那麼上述的實現方式顯然是有問題的。所以實現起來需要多考慮幾個問題：
鑒於存在上述兩個問題，可以參考如下實現邏輯：
假如有這么一個聯合主鍵欄位 primary key(a,b,c) 都是整型，該如何編寫遍歷 sql 呢？起初我的想法很簡單，具體如下：
至此在編寫校驗腳本過程遇到的兩個問題就算告一段落了，剩下的就是各種邏輯處理了，不過多贅述，有興趣的可以自行閱讀腳本文件。
本著最低程度影響業務，所以取消加鎖邏輯。但是又要保證該數據塊的數據一致性，如果這個數據塊是個熱數據，當前正在變更，那麼校驗的時候難免會不一致。所以只能通過多次校驗實現，默認是校驗20次，其中有一次校驗結果是一致，就認為是一致的，如果前5次校驗過程中，這個數據塊的數據沒有變化，也視為不一致（可能是因為延遲，也可能是真的不一致）。
pt-table-checksum 不校驗表結構，改寫時添加表結構的校驗。
可以基於表的並行校驗，可由用戶指定並行數，但是腳本有個安全機制，如果用戶指定的並行數大於當前 cpu 空閑核心數，就會按當前（空閑核心數-1）作為並行數。
添加網路監控，由用戶指定網路上限百分比，當網卡流量超過這個百分比就暫停任務，等待網卡流量低於閾值才會繼續任務。這個主要是出於對於中間件（mycat）的場景或者分布式資料庫（tidb）的場景。
支持定時任務功能，用戶可以使用這個功能規避業務高峰，僅在業務低峰進行數據校驗。
不僅限於主從節點的校驗，只要目標對象支持 MySQL 的標准 SQL 語法就能做數據校驗。
校驗邏輯是通過 SQL 採集目標節點的資料庫，如果目標資料庫系統當前存在異常，無疑是雪上加霜，將會觸發未知問題，所以添加超時機制，單次取數據塊的閾值是5s，超過5秒就放棄等待重試。測試發現，有時候即便觸發超時了，但是 SQL 任務還是會在目標資料庫的 processlist 中能看到，所以又添加了一個 kill 機制，超時後會觸發一個 kill processlist id 的動作。另外為了避免 kill 錯，在每個 SQL 對象添加了一個32位的 md5 值，每次 kill 的時候會校驗這個 md5 值。
本工具借鑒 pt-table-checksum 工具思路改寫，可以檢查隨意兩個 mysql（支持 mysql sql 語法的資料庫）節點的數據一致性。
基於主鍵以一個塊遍歷數據表，比對checksum的值，塊的大小可通過參數指定。 （1）獲取該表的第一個數據塊的查詢SQL。 （2）將兩個目標節點的數據塊的checksum的值，記錄到臨時文件，file1 file2。 （3）比對file1 file2是否一致。
第一步：先開啟一個 screen 監控網路
第二步：新開啟一個screen執行校驗任務
（1）info.log 文件
（2）list目錄
（3）md5 目錄
（4）pri 目錄
（5）res 目錄
這是 table 目錄下記錄某個數據塊不一致的一個例子
這是 diff 目錄下記錄某個數據行不一致的一個例子
（6）skip.log 文件
本工具是參考了 pt-table-checksum 工具的一些思路並結合自身經驗進行改寫，尚有很多不足之處，僅做學習交流之用， 如有線上環境使用需求，請在測試環境充分測試。
㈡ 如何保證資料庫緩存的最終一致性
對於互聯網業務來說，傳統的直接訪問資料庫方式，主要通過數據分片、一主多從等方式來扛住讀寫流量，但隨著數據量的積累和流量的激增，僅依賴資料庫來承接所有流量，不僅成本高、效率低、而且還伴隨著穩定性降低的風險。
鑒於大部分業務通常是讀多寫少（讀取頻率遠遠高於更新頻率），甚至存在讀操作數量高出寫操作多個數量級的情況。因此， 在架構設計中，常採用增加緩存層來提高系統的響應能力 ，提升數據讀寫性能、減少資料庫訪問壓力，從而提升業務的穩定性和訪問體驗。
根據 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」的方案。
㈢ 緩存一致性
在現代的 CPU（大多數）上，所有的內存訪問都需要通過層層的緩存來進行。CPU 的讀 / 寫（以及取指令）單元正常情況下甚至都不能直接訪問內存——這是物理結構決定的；CPU 都沒有管腳直接連到內存。相反，CPU 和一級緩存（L1 Cache）通訊，而一級緩存才能和內存通訊。大約二十年前，一級緩存可以直接和內存傳輸數據。如今，更多級別的緩存加入到設計中，一級緩存已經不能直接和內存通訊了，它和二級緩存通訊——而二級緩存才能和內存通訊。或者還可能有三級緩存。
緩存是分「段」（line）的，一個段對應一塊存儲空間，大小是 32、64或128位元組，每個緩存段知道自己對應什麼范圍的物理內存地址。
當 CPU 看到一條讀內存的指令時，它會把內存地址傳遞給一級數據緩存。一級數據緩存會檢查它是否有這個內存地址對應的緩存段。如果沒有，它會把整個緩存段從內存（或者從更高一級的緩存，如果有的話）中載入進來。是的，一次載入整個緩存段，這是基於這樣一個假設：內存訪問傾向於本地化（localized），如果我們當前需要某個地址的數據，那麼很可能我們馬上要訪問它的鄰近地址。一旦緩存段被載入到緩存中，讀指令就可以正常進行讀取。
如果我們只處理讀操作，那麼事情會很簡單，因為所有級別的緩存都遵守以下規律—— 在任意時刻，任意級別緩存中的緩存段的內容，等同於它對應的內存中的內容。 。
一旦我們允許寫操作，事情就變得復雜一點了。這里有兩種基本的寫模式：直寫（write-through）和回寫（write-back）。直寫更簡單一點：我們透過本級緩存，直接把數據寫到下一級緩存（或直接到內存）中，如果對應的段被緩存了，我們同時更新緩存中的內容（甚至直接丟棄），就這么簡單。這也遵守前面的定律： 緩存中的段永遠和它對應的內存內容匹配。
回寫模式就有點復雜了。緩存不會立即把寫操作傳遞到下一級，而是僅修改本級緩存中的數據，並且把對應的緩存段標記為「臟」段。臟段會觸發回寫，也就是把裡面的內容寫到對應的內存或下一級緩存中。回寫後，臟段又變「干凈」了。當一個臟段被丟棄的時候，總是先要進行一次回寫。回寫所遵循的規律有點不同。 當所有的臟段被回寫後，任意級別緩存中的緩存段的內容，等同於它對應的內存中的內容。
換句話說，回寫模式的定律中，我們去掉了「在任意時刻」這個修飾語，代之以弱化一點的條件：要麼緩存段的內容和內存一致（如果緩存段是干凈的話），要麼緩存段中的內容最終要回寫到內存中（對於臟緩存段來說）。
只要系統只有一個 CPU 核在工作，一切都沒問題。如果有多個核，每個核又都有自己的緩存，那麼我們就遇到問題了，因為如果一個 CPU 緩存了某塊內存，那麼在其他 CPU 修改這塊內存的時候，我們希望得到通知。系統的內存在各個 CPU 之間無法做到與生俱來的同步，我們需要一個大家都能遵守的方法來達到同步的目的。
緩存一致性協議有多種，但是日常處理的大多數計算機設備使用的都屬於「窺探（snooping）」協議。
窺探」背後的基本思想是，所有內存傳輸都發生在一條共享的匯流排上，而所有的處理器都能看到這條匯流排：緩存本身是獨立的，但是內存是共享資源，所有的內存訪問都要經過仲裁（arbitrate）：同一個指令周期中，只有一個緩存可以讀寫內存。窺探協議的思想是，緩存不僅僅在做內存傳輸的時候才和匯流排打交道，而是不停地在窺探匯流排上發生的數據交換，跟蹤其他緩存在做什麼。所以當一個緩存代表它所屬的處理器去讀寫內存時，其他處理器都會得到通知，它們以此來使自己的緩存保持同步。只要某個處理器一寫內存，其他處理器馬上就知道這塊內存在它們自己的緩存中對應的段已經失效。
在直寫模式下，這是很直接的，因為寫操作一旦發生，它的效果馬上會被「公布」出去。但是如果混著回寫模式，就有問題了。因為有可能在寫指令執行過後很久，數據才會被真正回寫到物理內存中——在這段時間內，其他處理器的緩存也可能會傻乎乎地去寫同一塊內存地址，導致沖突。在回寫模型中，簡單把內存寫操作的信息廣播給其他處理器是不夠的，我們需要做的是，在修改本地緩存之前，就要告知其他處理器。
MESI 是四種緩存段狀態的首字母縮寫，任何多核系統中的緩存段都處於這四種狀態之一。
從CPU讀寫角度來說：
上圖的切換解釋：
緩存的一致性消息傳遞是要時間的，這就使其切換時會產生延遲。當一個緩存被切換狀態時其他緩存收到消息完成各自的切換並且發出回應消息這么一長串的時間中CPU都會等待所有緩存響應完成。可能出現的阻塞都會導致各種各樣的性能問題和穩定性問題。
比如你需要修改本地緩存中的一條信息，那麼你必須將I（無效）狀態通知到其他擁有該緩存數據的CPU緩存中，並且等待確認。等待確認的過程會阻塞處理器，這會降低處理器的性能。因為這個等待遠遠比一個指令的執行時間長的多。
為了避免這種CPU運算能力的浪費，Store Bufferes被引入使用。處理器把它想要寫入到主存的值寫到緩存，然後繼續去處理其他事情。當所有失效確認（Invalidate Acknowledge）都接收到時，數據才會最終被提交。
執行失效也不是一個簡單的操作，它需要處理器去處理。另外，存儲緩存（Store Buffers）並不是無窮大的，所以處理器有時需要等待失效確認的返回。這兩個操作都會使得性能大幅降低。為了應付這種情況，引入了失效隊列——對於所有的收到的Invalidate請求，Invalidate Acknowlege消息必須立刻發送，Invalidate並不真正執行，而是被放在一個特殊的隊列中，在方便的時候才會去執行，處理器不會發送任何消息給所處理的緩存條目，直到它處理Invalidate。
㈣ 如何檢查資料庫中數據的一致性
資料庫一致性檢查(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 的詳細使用方法, 請參閱有關命令手冊。
㈤ chcahe 如何保證分布式緩存數據一致性
VPLEX的技術核心是「分布式緩存一致性」，下圖則是「分布式緩存一致性」技術的工作機制示意：正是因為這項核心技術優勢，使得VPLEX方案和目前所有廠商的虛擬化方案截然不同，並能夠實現異地的數據中心整合。對跨數據中心的所有負載實現跨引擎的平攤或者實時遷移，來自任何一個主機的I/O請求可以通過任何一個引擎得到響應。
緩存一致性的記錄目錄使用少量的元數據，記錄下哪個數據塊屬於哪個引擎更新的，以及在何時更新過，並通過4K大小的數據塊告訴在集群中的所有其他的引擎。在整個過程中實際發生的溝通過程，遠遠比實際上正在更新數據塊少很多。
分布式緩存一致性數據流示意圖：上方是一個目錄，記錄下左側的主機讀取緩存A的操作，並分發給所有引擎，右側主機需要讀取該數據塊時，會先通過目錄查詢，確定該數據塊所屬的引擎位置，讀取請求會直接發送給引擎，並直接從數據塊所在的緩存上讀取。
當一個讀請求進入時，VPLEX會自動檢查目錄，查找該數據塊所屬的引擎，一旦確定該數據塊所屬的引擎位置，讀的請求會直接發送給該引擎。一旦一個寫入動作完成，並且目錄表被修改，這時另一個讀請求從另一個引擎過來，VPLEX會檢查目錄，並且直接從該引擎的緩存上讀取。如果該數據仍然在緩存上，則完全沒必要去磁碟上讀取。
如上圖，來自圖中左側主機的操作，由Cache A服務，會記錄一個更新狀態，並分發給所有所有引擎知道。如果讀取的需求來自最右側的伺服器，首先通過目錄查詢。通過這種技術可以實現所有引擎一致性工作，而且這個技術不僅可以跨引擎還可以跨VPLEX集群，而VPLEX集群可以跨區域，因此緩存一致性也可以跨區域部署。
分布式緩存一致性技術使VPLEX相比傳統的虛擬化方案擁有更高的性能和可靠性，並實現異地數據中心的虛擬化整合
對傳統的虛擬化架構來說，如果虛擬化的I/O集群中有一個節點壞了，那麼性能就會降低一半，而且實際情況降低不止一半。因為壞了一個節點，這個節點緩存一般會被寫進去。因為沒有緩存，操作會直接寫到硬碟里。如果圖中中心這個節點壞掉，那主機所有的可用性都沒有了。而VPLEX如果有一個引擎或者一個控制器壞掉了，那這個引擎的負載會均攤到其他活動引擎上。這樣總體來講用戶可以維持可預知性能，性能降低也不那麼明顯。
㈥ 如何保證緩存與資料庫雙寫時的數據一致性
一般來說，就是如果系統不是嚴格要求緩存+資料庫必須一致性的話，緩存可以稍微的跟資料庫偶爾有不一致的情況，最好不要做這個方案，讀請求和寫請求串列化，串到一個內存隊列里去，這樣就可以保證一定不會出現不一致的情況
串列化之後，就會導致系統的吞吐量會大幅度的降低，用比正常情況下多幾倍的機器去支撐線上的一個請求。