ApsaraDB RDS：設定一致性層級

功能介紹

RDS MySQL資料庫代理預設採用最終一致性層級，在Binlog複製不中斷的情況下，讀請求直接發送到唯讀節點。由於唯讀節點的資料在Binlog複製下是最終一致的，因此代理上的讀請求也是最終一致的。RDS MySQL代理支援設定延遲閾值，限制唯讀執行個體的最大延遲時間。一旦唯讀節點的延遲超過該閾值，讀請求將不再被發送到該節點。

此外，複寫延遲可能導致不同唯讀節點上的資料存在差異。例如，在一個會話中連續執行如下查詢，最終查詢結果可能有所不同：

SET AUTOCOMMIT = 1;INSERT INTO t1(id, price) VALUES (111, 96);UPDATE t1 SET price = 100 WHERE id = 111;SELECT price FROM t1;

這些查詢的結果可能會因複寫延遲而有所變化。

適用情境

一致性需求較弱，更希望盡量減輕主節點壓力，使更多讀請求路由到唯讀節點時，您可以選擇最終一致性。

功能介紹

為應對最終一致性導致查詢結果不準確的問題，業務系統通常會將讀請求拆分：高一致性要求的讀請求發往主節點，低一致性要求的讀請求發往唯讀節點。然而，這種做法不僅增加了應用複雜度，還會使主節點承擔更多的讀請求，影響讀寫分離的效果。

為瞭解決上述問題，RDS MySQL代理提供了會話一致性。與最終一致性直接將讀請求發送到唯讀節點不同，會話一致性下，代理會記錄前一個更新操作在主節點上的資料位元點（基於GTID確定）。代理僅將讀請求發送到已同步該位點資料的唯讀節點，確保讀請求能查詢到當前會話中已更新的資料，從而保證會話內的資料一致性。

適用情境

單個會話記憶體在一致性依賴，推薦使用會話一致性，該層級對效能影響相對較小而且能滿足大多數應用情境。

功能介紹

在某些應用情境中，不僅會話內部存在邏輯上的因果依賴關係，不同會話之間也存在依賴關係，要求各會話讀取的資料必須完全一致。此時，會話一致性無法滿足需求。RDS MySQL代理通過提供全域一致性來解決這一問題。與會話一致性不同，全域一致性下，代理會在每次讀操作前記錄當前主節點上的資料位元點（基於GTID確定），並僅將讀請求發送到已完成相應資料位元點同步的唯讀節點，確保讀請求能查詢到所有會話已更新的資料，從而保證了全域資料的一致性。

適用情境

會話間存在一致性依賴，並且業務為讀多寫少的情境，建議使用全域一致性。