MongoDB寫入資料策略

上篇文章介紹了Mongo讀取資料的策略（MongoDB讀資料策略），主要是readconcern、readpreference兩引數，其中readconcern作用於服務端，決定了什麼時候能讀取到資料；readpreference在客戶端配置，決定讀哪個節點的資料。本文將要介紹Mongo的寫入策略，在介紹寫入策略前，先簡單說明MongoDB的Journaling特性。

MongoDB也有防carsh能力，和MySQL類似，也是透過預先寫日誌(WAL)到檔案實現，這檔案就是Journaling功能。To provide durability in the event of a failure, MongoDB uses write ahead logging to on-disk journal files.

◀日誌檔案▶

開啟Journaling功能後，Mongo 會在資料庫目錄下建立 journal目錄，用來存放journal日誌，以WiredTiger引擎為例，檔案格式是WiredTigerLog.<sequence>，其中<sequence>是從0000000001開始的零填充數字。journal日誌檔案預設大小為100 MB，超過該限制後，將建立一個新的日記檔案，並會自動刪除舊的日誌檔案，僅保留從上一個檢查點恢復所需的檔案。所以journal日誌檔案一般情況下只會生成兩三個，除非每秒有大量的寫操作發生。

◀日誌記錄▶

journal記錄有這幾個特點：

• 它包括由初始寫入引起的任何內部寫入操作。例如，對集合中文件的更新可能會導致對索引的修改；WiredTiger建立單個日誌記錄，其中包含更新操作及其關聯的索引修改。

• 每個記錄都有一個唯一的識別符號。

• WiredTiger的最小日誌記錄大小為128位元組。

另外，為了提高儲存效率，MongoDB犧牲了一些CPU效能，對WiredTiger引擎對日誌資料使用壓縮儲存，預設壓縮方式是snappy壓縮，也支援其他壓縮方式，比如：zstd、zlib等，可以透過下面方式設定。

storage.wiredTiger.engineConfig.journalCompressor

總之，Journaling 是MongoDB中非常重要的一項功能，類似於關聯式資料庫中的事務日誌。Journaling能夠使MongoDB由於意外故障後快速恢復。在2.0版本後，預設開啟了該功能。和MySQL一樣，Mongo 例項啟動時會檢查journal日誌檔案，確認是否有需要恢復的資料。不過由於提交journal日誌會產生寫入阻塞，所以它對寫入的操作有效能影響，但在生產環境中通常還是開啟Journaling的。

writeconcern 是Mongo針對寫操作的引數，表示寫請求對 mongod 例項的確認級別，決定資料的永續性。它可以用下面三個選項表示。

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

◀writeconcern 選項▶

w指定寫操作需要應用到多少個資料節點才能返回成功，可以為0、1、2、3或者majority。

• w: 0 表示客戶端不需要收到任何有關寫操作，就直接返回成功。
• w: 1 表示寫主成功，就直接返回成功。
• w: majority 需要收到多數節點（含主節點）關於操作執行成功的確認，具體個數根據複製集配置自動得出。比如，一主兩從3節點的叢集，則需要2個節點確認寫入成功即可。
• w: N（N > 1）表示N個資料節點確認才返回成功。

  
  

  w 值越大，對客戶端來說，資料的安全性保證越強，同時寫操作的延遲越大。

  w 設定的節點數越多，等待的延遲也就越大。如果 w 等於總節點數，那麼一旦其中某個節點出現故障就會導致整個寫入失敗，這也是有風險的。另外，針對Hidden、delayed和priority為0的資料節點，官方也特別做了說明，如下：

NOTE

Hidden, delayed, and priority 0 members can acknowledge w: <number> write operations.

Delayed secondaries can return write acknowledgment no earlier than the configured slaveDelay.

注意：

a、副本集中Hidden、delayed和priority為0的成員，可以確認w: <number>的寫操作。

b、延遲節點的返回寫ack，不會早於配置的slavedelay值  。

如果叢集有 3 三個資料節點，在w: majority模式下 ，只需要寫入兩個資料節點即可返回，流程如下：

j表示寫操作是否要被持久化，只能選填 true 或 false。

• j:false 表示寫操作到cache即算作成功。

• j:true 表示寫操作到檔案中才算成功。

從3.2版本後，如果指定j:true，即使 w:0 ，只有在請求的成員數(包括主成員)寫入日誌後才返回資料。因此，j:true設定保證了MongoDB的資料持久化。

Changed in version 3.2: With j: true, MongoDB returns only after the requested number of members, including the primary, have written to the journal.

另外，僅僅j:true 不保證叢集 failover 時發生回滾的寫操作。

j: true does not by itself guarantee that the write will not be rolled back due to replica set primary failover.

wtimeout：返回確認的超時時間，單位為毫秒。

如果寫入操作超過該值，則返回錯誤，即使最終寫入是成功了，但資料庫不會撤銷超時寫入的資料。如果沒有指定 wtimeout 值，則寫入操作將無限期阻塞，wtimeout:0 等同於該選項未設定值。同時，這個引數和 WriteConncern 的w值有關，並且只適用於w大於0的情況。比如：w:0，表示可以超時無限大，則不返回錯誤；w:1，只和主節點確認的超時時間；w:majority，表示需要和多數節點確認超時時間。

◀資料提交策略▶

MongoDB也有和MySQL有類似的提交策略，是由 commitIntervalMs 引數控制，它是日誌持久化的間隔時間(以毫秒為單位)。如果想要更好的資料安全，可以設為每毫秒對cache中的資料做硬碟層面的sync；如果需要更好的寫入效能，最大可以改為每500毫秒做一次sync。它的取值範圍是1 ~ 500毫秒，預設值是100毫秒，不支援in-memory 儲存引擎。

• w：指定寫入資料後需要在多少個節點上同步寫入成功後，才返回確認資訊。
• j：設定 j:true 會將資料寫入日誌中，可以在節點當機時恢復資料。但是 j:true 並不保證資料已經寫入磁碟檔案中。
• wtimeout：指定寫入超時時間。當寫入操作達到超時時間時，即使最終成功寫

  入也會返回錯誤資訊。
  
  

  
  

在實際使用中，可以根據具體的業務需求和系統環境來選擇適合的寫入策略，以達到最佳的效能和可靠性。例如，在資料一致性要求高的場景中，可以使用 majority 寫入確認來保證資料同步的可靠性。而在效能要求高、資料不敏感的場景中，可以使用 w 值較小的寫入關注點來提高寫入效能。