PolarDB MySQL版通過資料庫核心與RDMA網路的深度融合，提供全域一致性（高效能模式），簡稱SCC。在保證全域資料一致性的前提下，實現高效能資料讀寫。與最終一致性方案相比，開啟全域一致性（高效能模式）後叢集效能損失保持在10%以內。本文將詳細介紹全域一致性（高效能模式）的使用限制、技術原理、開啟方式以及效能測試結果對比。
版本要求
若要開啟全域一致性（高效能模式），PolarDB MySQL版叢集版本需為以下版本之一：
8.0.2版本且核心小版本需為8.0.2.2.19及以上。
8.0.1版本且核心小版本需為8.0.1.1.29及以上。
5.7版本且核心小版本需為5.7.1.0.26及以上。
如何確認叢集版本，請參見查詢版本號碼。
注意事項
Serverless叢集的所有隻讀節點預設開啟全域一致性（高效能模式）。
全球資料庫網路GDN中的從叢集的唯讀節點不支援開啟全域一致性（高效能模式）。
全域一致性（高效能模式）與Fast Query Cache功能相容。若此前全域一致性（高效能模式）開啟了分層的細粒度的修改跟蹤（MTT）最佳化功能。當同時開啟Fast Query Cache功能和全域一致性（高效能模式）功能時，全域一致性（高效能模式）的MTT最佳化功能將失效。
全域一致性（高效能模式）技術方案
PolarDB MySQL版全域一致性（高效能模式）是以PolarTrans為基礎，這是一套全新設計的基於時間戳記的事務系統，旨在重構原生MySQL中基於活躍事務數組的傳統交易管理方式。該系統不僅支援分散式交易的擴充，更顯著提升了單機的效能表現。
PolarDB全域一致性（高效能模式）的具體實現如下圖所示，利用高速RDMA網路構建互動式多維度主從資訊同步機制，取代了傳統的主從日誌複製架構，並通過線性Lamport時間戳記演算法，減少RO節點擷取時間戳記的次數，同時避免了不必要的日誌回放等待。
線性Lamport時間戳記：為了最佳化讀操作（RO）節點擷取最新修改時間戳記的效率，我們引入了線性Lamport時間戳記機制。傳統方法中，RO節點需要在處理每個請求時都從寫操作（RW）節點擷取時間戳記，即使網路速度很快，在高負載情況下也會產生顯著開銷。線性Lamport時間戳記的優勢在於，RO節點可以將從RW節點擷取的時間戳記儲存在本地。對於早於本機存放區的時間戳記的請求，RO節點可以直接使用本地時間戳記，無需再次向RW節點擷取。這種機制有效減少了高負載下頻繁擷取時間戳記的開銷，提高了RO節點的效能。
分層的細粒度的修改跟蹤：為了最佳化讀操作（RO）的效能，RW引入了多級時間戳記機制：全域、表級和頁面級。當RO處理請求時，首先會擷取全域時間戳記。如果全域時間戳記小於RO回放日誌的時間戳記，RO不會立即進入等待狀態，而是會繼續檢查請求訪問的表和頁面時間戳記。只有當訪問的頁面時間戳記仍然不滿足時，RO才會等待日誌回放完成。這種機制可以有效避免一些不必要的日誌回放等待，提高RO的響應速度。
基於RDMA的日誌傳輸：PolarDB全域一致性（高效能模式）採用了單邊RDMA的介面來實現RW到RO的日誌傳輸，極大地提高了日誌傳輸速度，同時減少了日誌傳輸時帶來的CPU開銷。
線性Lamport時間戳記
為了降低讀請求的延遲和頻寬消耗，RO節點可以利用線性Lamport時間戳記機制。當一個請求到達RO節點時，如果發現其他請求已經從RW節點擷取了時間戳記，它可以直接重用該時間戳記，從而避免重複請求，保證強一致性的同時提升效能。
上圖中一個RO上有兩個並發的讀請求r1和r2。r2在t2時向RW發送讀取時間戳記的請求，在t3時刻拿到了RW的時間戳記TS3rw。我們可以得到這幾個事件的關係：e2TS3rwe3。r1在t1時刻到達。通過在RO給每個事件分配一個時間戳記，可以確定同一個RO上不同事件的先後關係。如果t1在t2之前，我們可以得到e1e2TS3rwe3。也就是說r2拿到的時間戳記，其實已經反映了r1到達之前的所有更新，所以r1可以直接使用r2的時間戳記，而不必去拿新的時間戳記。基於這個原則，RO每次拿到RW的時間戳記時，都會把這個時間戳記儲存在本地，並且會記錄擷取到該時間戳記的時間，如果某個請求的到達時間早於本機快取時間戳記的擷取時間，則該請求可以直接使用該時間戳記。
分層的細粒度的修改跟蹤
為了實現強一致讀，RO需要首先擷取RW當前事務的最新提交時間戳記，並等待RO上的日誌回放到該時間戳記才能處理讀請求。然而，在等待日誌回放期間，當前請求的資料可能已經是最新的，無需等待。為了避免不必要的等待時間。PolarDB全域一致性（高效能模式）採用了更加細粒度的修改追蹤。在RW上維護三層修改資訊：全域的最新修改的時間戳記，表級的時間戳記和頁面（page）層級的時間戳記。
在處理讀請求時，RO首先擷取全域時間戳記，以判斷資料一致性。如果全域時間戳記不滿足條件，RO會進一步擷取目標表的本地時間戳記，進行更細粒度的校正。如果仍不滿足，RO會繼續檢查目標頁面的時間戳記，進行更精確的判斷。只有當頁面時間戳記仍然大於RO日誌回放時間戳記時，RO才需要等待日誌回放，以確保讀取到最新的資料。
在RW上，為了降低記憶體消耗，三種層級的時間戳記都儲存在記憶體雜湊表中。為了進一步最佳化記憶體使用量，多個表或頁的時間戳記可能被映射到同一個雜湊表位置。為了保證一致性，僅允許較大的時間戳記替換較小的。這種設計確保即使RO擷取到較大的時間戳記也不會破壞一致性。具體實現如圖所示，TID和PID分別表示表和頁的ID。RO擷取到的時間戳記會按照線性Lamport時間戳記的設計緩衝到本地，方便其他合格請求使用。
基於RDMA的日誌傳輸
在PolarDB全域一致性（高效能模式）中。RW通過單邊RDMA的方式遠程將日誌寫入到RO緩衝，該過程不需要RO的CPU參與，同時延遲也很低。具體實現如下圖所示，RO和RW都維護了相同大小的log buffer。RW的後台線程會將RW的log buffer通過RDMA寫入到RO的log buffer，RO通過讀取本地log buffer替代讀取檔案, 加快複製同步效率。
如需瞭解RDMA日誌傳輸的更多說明，請參見RDMA日誌傳輸。
全域一致性（高效能模式）和全域一致性
PolarDB一共提供了四種一致性層級：最終一致性、會話一致性、全域一致性和全域一致性（高效能模式），可以滿足在不同情境下對一致性層級的要求。
其中，全域一致性（高效能模式）是對原有全域一致性層級的升級，具有比全域一致性更嚴格的強一致性要求。因此，若您的業務追求更強的一致性，更推薦全域一致性（高效能模式），具體如下：
對於PolarDB MySQL版5.7、8.0.1和8.0.2版本，若追求嚴格強一致性，更推薦全域一致性（高效能模式）。
對於PolarDB MySQL版5.6版本，若追求嚴格強一致性，由於該版本暫不支援全域一致性（高效能模式），可選擇全域一致性。
關於如何開啟全域一致性，請參見開啟全域一致性。
如何開啟全域一致性（高效能模式）
登入PolarDB控制台，在目的地組群的基本資料頁面的資料庫連接地區，選中需要開啟全域一致性（高效能模式）功能的串連地址，單擊配置。詳細操作步驟請參見設定資料庫代理。
全域一致性（高效能模式）需要在叢集中所有地址同時生效，如果在某個地址開啟全域一致性（高效能模式），則叢集其他所有地址都會開啟全域一致性（高效能模式）。
效能對比
測試環境
一個規格為8核32 GB的PolarDB MySQL版8.0版本叢集版。
測試載入器
Sysbench
測試資料量
25張表，每張表250000行資料。
測試結果及說明
全域一致性（高效能模式）叢集混合讀寫效能對比
圖表說明：
縱座標qps：表示sysbench測試結果。
橫座標threads：表示測試時使用的sysbench並發線程數。
RW：表示假設RO無法提供全域一致性讀，所有的讀寫請求均發往RW節點。
全域一致性：表示由代理提供的全域一致性功能。
全域一致性（高效能模式）：表示開啟核心提供的全域一致性（高效能模式）代理設定最終一致性。
最終一致性：表示代理設定為最終一致性讀，並且關閉核心提供的全域一致性（高效能模式）。
在
sysbench oltp_read_write情境中，全域一致性（高效能模式）相比較於最終一致性，叢集整體效能損耗控制在10%以內。