此文已由作者溫正湖授權網易雲社區發布。
歡迎訪問網易雲社區，了解更多網易技術產品運營經驗。
MongoDB中WiredTiger的參數配置主要通過 wiredtiger_open （http://source.wiredtiger.com/2.9.1/group__wt.html#ga9e6adae3fc6964ef837a62795c7840ed）進行配置。
checkpoint檢查點：
默認60s或2G redo觸發checkpoint，也可以通過syncPeriodSecs調整，但官方強烈建議不調整；WT可通過checkpoint_sync（未在MongoDB中暴露）來調整checkpoint時的行為，默認會將數據持久化到存儲介質中。
journal：
即redo日志，默認開啟redo，每50ms刷新一次，時間無法設置。與MySQL的InnoDB redo不同，wt的redo類似MySQL Binlog文件，大約每寫滿100MB就會創建新的redo文件，此時會刷新舊的redo文件，最后一次檢查點前的redo日志文件會被自動刪除。
MongoDB wt的崩潰恢復大概流程為：查找wt元數據，先將數據恢復到最近一個已完成的checkpoint點，由於wt數據插入和更新采用COW(copy on write)機制，所以該恢復過程非常快；之后，在redo文件中查找是否有checkpoint點之后的日志，若有，則回放這些日志。
WT層持久性
從上可以看出，MongoDB中的wt並未設置為commit-level的數據持久性，而僅僅是checkpoint-level的持久性，但由於每50ms都會flush redo，所以雖有數據丟失，但由於每50ms一刷新，正常情況下丟失數據量很少，最多也不會超過100MB。由於生產環境中，MongoDB一般配置為replica set，丟失的那部分數據，也可以通過oplog復制從其他節點補上。
WT層IO方式
此項在MongoDB中沒有顯式配置，所以使用默認值。
WT可通過direct_io來調整打開文件時的行為，可配置data、log文件或checkpoint時走DirectIO，默認為空，也就是說這三種IO都走Buffer IO模式，即使用Linux內核的page cache；可通過mmap配置項來設置是否盡可能走MMAP內存訪問模式，默認開啟；
此外，還可為每次事務定義IO行為，通過transaction_sync進行配置，包括詳細可參考（http://source.wiredtiger.com/2.9.1/tune_durability.html），默認在事務提交的時候不flush日志，僅在checkpoint的時候，或sync的時候刷。刷日志的行為可選擇fsync或dsync（官方說區別不大）。
MongoDB層持久性
雖然MongoDB在wt設置層面沒有做到commit-level的持久性。但對於MongoDB插入和更新操作，如果write concern中設置j:true，則確保了每次操作內容都會持久化到redo中。而且MongoDB 3.2復制集協議protocolVersion: 1（類raft）時，如果開啟了journal，則write concern中的j為true，除非用戶修改了驅動/復制集設置，或者在操作時顯式指定j:false。
所以，從MongoDB整體上看，實現了操作級別（事務級別）的數據持久性。如果復制集配置write concern的w為majority，則能夠確保插入和更新操作成功返回用戶后，數據已經持久化到大多數節點。
網易雲免費體驗館，0成本體驗20+款雲產品！
更多網易技術、產品、運營經驗分享請點擊。
相關文章：
【推薦】 網易易盾驗證碼的核心指標和系統兼容性認知大全