基礎信息

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。

云數據庫 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。

最佳實踐