ApsaraDB for MongoDB：事務與Read/Write Concern

基礎資訊

MongoDB事務的使用和互動習慣與關係型資料庫的事務基本一致，API使用方法也類似，無額外的學習成本。

以下樣本為一個完整事務，您可以看到API（startTransaction/abortTransaction/commitTransaction）以及相關聯的session和readConcern/writeConcern設定。

// 建立集合
db.getSiblingDB("mydb1").foo.insertOne(
    {abc: 0},
    { writeConcern: { w: "majority", wtimeout: 2000 } }
)
db.getSiblingDB("mydb2").bar.insertOne(
   {xyz: 0},
   { writeConcern: { w: "majority", wtimeout: 2000 } }
)
// 開啟一個會話
session = db.getMongo().startSession( { readPreference: { mode: "primary" } } );
coll1 = session.getDatabase("mydb1").foo;
coll2 = session.getDatabase("mydb2").bar;
// 開啟一個事務
session.startTransaction( { readConcern: { level: "local" }, writeConcern: { w: "majority" } } );
// 在事務中執行若干操作
try {
   coll1.insertOne( { abc: 1 } );
   coll2.insertOne( { xyz: 999 } );
} catch (error) {
   // 遇到問題時中止事務
   session.abortTransaction();
   throw error;
}
// 提交事務
session.commitTransaction();
session.endSession();

事務的使用說明如下：

• 事務需要與會話（session）關聯，一個會話同一時間只能有一個未完成事務。如果會話結束，其關聯的未完成事務也會復原。

• 一個分散式交易可以同時包含對不同庫表的不同文檔的操作。

• 在事務執行期間，事務能夠讀取自己未提交的寫操作，但事務外部的其他動作不會讀取到事務中未提交的寫操作。

• 在事務提交之前，不會將未提交的寫入資料複製到從節點。一旦事務被提交，寫入的資料將被複製並自動應用於所有複本集中的從節點。

• 在修改文檔時，事務將鎖定文檔，使文檔無法被其他動作更改，直至事務完成。如果一個事務無法獲得它需要修改文檔上的鎖，可能是因為另一個事務已經持有該鎖，那麼該事務將在5毫秒後立即終止（該時間由maxTransactionLockRequestTimeoutMillis核心參數控制），並提示寫衝突（WriteConflicts）。

• 事務有重試機制，如果遇到了暫時的可重試錯誤（比如網路臨時中斷），事務會自動重試。而且用戶端對重試操作無感知。

• 事務有生命週期，運行超過60秒的事務將會被後台線程強制終止（該時間由transactionLifetimeLimitSeconds核心參數控制）。

使用限制

• 分散式交易不能建立新的集合和索引。

• 事務不能寫入capped集合。

• 事務不能使用快照（snapshot）的Read Concern讀取capped集合（該限制存在於MongoDB 5.0及以上版本）。

• 事務不能讀寫config/admin/local庫裡的集合。

• 事務不能寫形如system.*的系統庫表。

• 事務不支援explain。

• 事務無法通過getMore讀取事務外建立的遊標；事務外也無法通過getMore讀取事務內建立的遊標。

• 事務內的第一個操作不能為killCursors/hello等。

• 事務內無法執行非CURD的命令，包括listCollections/listIndexes/createUser/getParameter/count等。

• 分散式交易不支援將分區上的writeConcernMajorityJournalDefault參數設定為false。

• 分散式交易不支援帶arbiters的分區。

最佳實務

核心缺陷風險說明

建立長時間啟動並執行大事務，或者試圖在單個事務中執行過多的操作，都會給WiredTiger儲存引擎的緩衝帶來很大壓力。因為自最早的已建立未提交事務起，WiredTiger緩衝必須能為所有後續的寫入維持相關資料和狀態。由於事務在運行時使用相同的快照，因此，在整個事務運行期間，新的寫操作會持續累積在WiredTiger緩衝中。當前運行在舊快照上的事務在提交或中止之前，緩衝中的這些寫操作都不能被逐出。而長事務引起的WiredTiger緩衝壓力超載（wt cache使用率以及dirty使用率超閾值）通常會帶來更多的問題，包括資料庫卡頓、請求延時大幅增加、CPU使用率滿等問題，甚至出現“死結”，導致業務受損。更多關於核心風險的介紹，請參見SERVER-50365和SERVER-51281。

ApsaraDB for MongoDB建議所有重度使用事務的業務都將MongoDB執行個體升級至5.0及以上的版本來規避相關風險和隱患。

基礎資訊

控制一致性和隔離等級的Read Concern包括以下幾種：

• "local"：複本集架構下讀主或從節點時的預設層級，從本地讀取，可能會讀到被復原的資料。

• "available"：分區叢集架構下讀從節點時的預設層級，可能讀到會被復原的資料。讀資料前不會進行shardVersion的檢查，因此可能讀到孤立文檔。優點是提供了最優的訪問延遲。

• "majority"：讀取的是已被大多數節點確認的資料，即不會被復原的資料。

• "linearizable"：資料一致性要求最嚴格的線性化層級，讀操作需要等待所有前序寫入都已經被大多數節點確認。效能最差，只能在主節點上使用。

• "snapshot"：基於快照讀取，同樣讀取的是已被大多數節點確認的資料，只不過可以關聯某一個特定時間點的快照，比如配合atClusterTime使用。

Read Concern的使用說明如下：

• 無論Read Concern的層級如何，某一個mongod節點上最新的資料都不代表複本集中最近版本的資料。

• 可以為不同的操作指定不同的Read Concern，4.4及以上版本也可以設定伺服器端預設的Read Concern，操作的Read Concern優先順序高於伺服器端設定的Read Concern。

• 當讀取local庫時，您指定的Read Concern會被忽略，您總是能在local庫裡讀到所有本機資料。

• 分散式交易裡僅支援3種Read Concern層級，分別為"local"、"majority"、"snapshot"。

• 因果一致性會話裡，必須使用"majority"層級的Read Concern。

最佳實務

基礎資訊

指定Write Concern的格式如下。關於Write Concern的更多介紹，請參見Write Concern。

{ w: <value>, j: <boolean>, wtimeout: <number> }

• 控制資料持久化保證層級的Write Concern可以簡單分為以下幾種主要層級：

  • {w: 0}：表示寫（write）不確認，不確認寫操作是否完成，可能發生寫入資料丟失。

  • {w: 1}：表示寫（write）確認，為MongoDB 5.0版本以前的預設行為。確認寫操作在記憶體中已完成，但由於還沒有持久化，依然可能發生資料丟失。

  • {j: true}：表示日誌（journal）確認。確認寫操作已完成並刷到持久化儲存的WAL中，寫操作不會丟失。

  • { w: "majority" }：表示大多數（majority），為MongoDB 5.0及以上版本的預設行為。等待寫操作被複製到複本集中大多數節點上後才確認，資料不會被復原。

  • 副本確認：等待寫操作被複製到複本集中指定數量的節點上後才確認。

  • 自訂確認：可以通過settings.getLastErrorModes參數指定其他自訂的帶tag確認方式。

Write Concern的使用說明如下：

• 您可以在任何寫操作或者事務中指定Write Concern，未顯示指定時會使用預設值。

  說明

  從MongoDB 5.0版本開始，標準3副本拓撲結構下，預設的全域Write Concern已經從之前的{w:1}調整為{w:"majority"}。這可能會導致您將資料庫版本升級至5.0及以上版本後出現效能退化問題。

• 複本集中的隱藏（Hidden）節點、延遲（Delayed）節點、或其他優先順序為0的可投票節點均可以視為"majority"中的一員。

• 您可以為不同的操作指定不同的Write Concern，4.4及以上版本也可以設定伺服器端預設的Write Concern，操作的Write Concern優先順序高於伺服器端設定的Write Concern。

• 當寫入local庫時，您指定的Write Concern會被忽略。

• 因果一致性會話裡，必須使用"majority"的Write Concern。

最佳實務