MESI協議
MESI協議是基於Invalidate的高速緩存一致性協議，並且是支持回寫高速緩存的最常用協議之一
此外還有一些其他的緩存一致性協議比如：MSI，MOSI，Synapse，Firefly及DragonProtocol等等
主流的計算機cpu執行，簡要流程
如下圖所示：
執行數據加載的流程如下：
- 將程序和數據從硬盤加載到內存中去
- 將數據從內存中加載到CPU的緩存中去，大多為三級緩存（L3 -> L2 -> L1）
- CPU取緩存中的數據，加載到寄存器中，進行計算
- CPU將計算完成的數據刷新回緩存，在一定的條件會刷新回內存中去，保持數據的一致性
為什么需要緩存一致性協議
在現在CPU多為多核的情況下，每個核心有自己單獨的緩存區，當多個核心一起操作多個線程對同一個數據進行操作時，如果在核心B在核心A把修改完之后的數據刷新回內存中去之前，進行了數據的操作，就會導致數據的不確定性。
總線加鎖可以解決這種情況，但是在加鎖的時候，在一個核心操作該數據完成前，其他核心也無法修改其他數據，這會導致CPU的性能嚴重下降。
緩存一致性協議只會對單個的緩存行進行類似加鎖的操作，來進可能的保證數據的一致性
MESI的狀態
MESI的四個字母就是標記緩存行的四種狀態 M E S I
| 狀態 | 描述 | 狀態改變條件 |
|---|---|---|
| M 修改 （Modify） | 表示該緩存行有效，但是是被更改過的，與內存中的數據並不一致，並且該緩存行只存在於本緩存中（舉例：我們有三個CPU，每個CPU都有自己的緩存區域，那么M表示CPU-A從內存中取到了數據，其他CPU並沒有取此數據（只存在於本緩存中），CPU-A還把該數據進行了更改，導致與內存中的源數據並不一致） | 當有其他試圖讀取該緩存在內存中的源數據時，它們須等待此緩存寫回到內存，這時此緩存行的狀態為S |
| E 獨占 （Exclusive） | 表示該緩存行有效，數據和內存中的一致（干凈），並且數據只存在於本緩存行中 | 如果有相應的其他讀取內存中關於本緩存行的操作時，會將自身的狀態更改為S。 |
| S 共享 （Shared） | 表示該緩存行有效，數據和內存中的一致，並且數據也同時存在於其他緩存中 | 如果其他緩存將該數據在它當前所在的緩存區域內將緩存修改，那么其他沒有修改的緩存就需要把S狀態修改為I狀態 |
| I 無效 （Invalid） | 該緩存行數據無效 |
那么接下來我們來看幾張圖來理解這幾個狀態：
M （修改）和 E （獨占）的描述（不包括狀態改變條件）
我們先只關心CPU-1 的操作步驟
- 我們先發出了一條指令，要讀取內存中a0的數據
- 我們經過總線等步驟，來到了內存
- 我們從內存中取到了數據並放入到了緩存中，此時這個緩存行的狀態為E （獨占，只存在於當前數據行中，並且干凈）
- CPU獲得數據
-
我們這個時候選擇了修改a0的數據，那么我們就會直接修改位於我們當下緩沖區中數據
此時我們修改成功，a0的數據狀態成功的變為了M （緩存行有效，只存在於當前緩存行中，於內存中的不一致）
我們來看下內存中目前的a0數據：
S（共享）
- 我們直接用CPU-0、CPU-1、CPU-2 都發出了read a0的指令，那么此時它們三個的緩沖區都有此數據，並且都沒有修改是干凈的，那么它們的狀態就都為S
M （修改）狀態改變條件描述
此時我們先在CPU-1中讀取並修改了a0所以它的目前狀態為M（修改）
接下來我們在CPU-0中讀取位於內存中的a0數據，看看會發生什么？
- CPU-0發出read a0的指令，這個時候通過數據總線（ADDRESS BUS）對CUP-1的數據進行同步
- 第一步這個時候CPU-1中M狀態的a0數據狀態修改為S（共享）這個時候開始把數據與內存中的數據進行同步
第二步，這個時候內存中同步了被修改的數據，然后被CPU-0進行讀取，並把S狀態的數據放入自己的緩存，然后讀取a0，執行完畢
E（獨占）狀態改變條件描述
此時只有CPU-1有a0這個數據，所以它是符合E（獨占）的狀態
接下來讓我們再用CPU-0來讀取a0來看看
不出所料當CPU-0讀取數據的時候，它們就符合了共享的條件，那么它們的狀態就會更改為S
S （共享） 狀態改變條件描述
此時我們三個CPU都擁有a0的數據緩存，所以它們的狀態都有S（共享），那么我們寫入其中一個數據
當我們更改了CPU-1的數據時，我們會同步內存中的數據，使其保持最新，然后把其他CPU中的緩存數據狀態置為I（無效、該緩存行無效）的狀態
MESI的缺點
如果由特定塊上的各種高速緩存執行連續讀取和寫入操作，則每次都必須將數據刷新到總線上。因此，主存儲器將在每次沖洗時拉動它並保持清潔狀態。但這不是一項要求，只是由於MESI的實施而導致的額外開銷。 MOESI協議克服了這一挑戰