原文地址：http://blog.csdn.net/kyfxbl/article/details/12402651 原文地址：http://www.mongoing.com/archives/1723
##基本機制 恢復日志（Journal） 寫保證級別（Write Concern)
##journal MongoDB先把數據更新寫入到Journal Buffer->>更新內存數據->>返回結果給應用端 Journal會以100ms的間隔批量刷到盤上
##write concern 所有的mongodb driver，在執行一個寫操作（insert、update、delete）之后，都會立刻調用db.getLastError()方法。這樣才有機會知道剛才的寫操作是否成功，如果捕獲到錯誤，就可以進行相應的處理。處理邏輯也是完全由client決定的，比如寫入日志、拋出錯誤、等待一段時間再次嘗試寫入等。作為mongodb server並不關心，server只負責通知client發生了錯誤 對寫操作的保證，級別越高，可靠性越高但是性能越低
###write concern:0（Unacknowledged） 
driver調用了getLastError()之后，mongod立刻返回結果，然后才實際進行寫操作。所以getLastError()的返回值一定是null，即使之后的Apply發生了錯誤，driver也不知道。使用這個級別的write concern，driver的寫入調用立刻返回，所以性能是最好的，但是可靠性是最差的，因此並不推薦使用。 其實還有一個w:-1的級別，是error ignored，基本上和w:0差不多。區別在於，w:-1不會捕獲任何錯誤，而w:0可以捕獲network error
###write concern:1（acknowledged） 
和Unacknowledged的區別是，現在mongod只有在Apply（實際寫入操作）完成之后，才會返回getLastError()的響應。所以如果寫入時發生錯誤，driver就能捕獲到，並進行處理。這個級別的write concern具備基本可靠性，也是目前mongodb的默認設置級別
###write concern:1 & journal:true（Jounaled） 
mongodb的Apply操作，是將數據寫入內存，定期通過fsync寫入硬盤。如果在Apply之后，fsync之前mongod掛了，那持久化實際上是失敗的。但是在w:1的級別下，driver無法捕獲到這種情況下的error（因為response在apply之后就已經返回到driver） 使用Journal機制:寫操作在寫入內存之后，還會寫到journal文件中,實實在在的把journal落盤以后才會返回。 MongoDB並不會對每一個操作都立即刷盤，而是會等最多30ms，把30ms內的寫操作集中到一起，采用順序追加的方式寫入到盤里。在這30ms內客戶端線程會處於等待狀態。這樣對於單個操作的總體響應時間將有所延長，但對於高並發的場景，綜合下來平均吞吐能力和響應時間不會有太大的影響
###write concern:2（Replica Acknowledged） 這個級別只在replica set的部署模式下生效 
這個級別下，只有secondary從primary完成了復制之后，getLastError()的結果才會返回。也可以同時設置journal:true或j:true，則還要等journal寫入也成功后才會返回。但是注意，只要primary的journal寫入就會返回，而不需要等待secondary的journal也寫入。類似的也可以設置w:3，表示至少要有3個節點有數據；或者w:majority，表示>1/2的節點有數據
###注意 wtimeout: 寫入超時時間，僅w的值大於1時有效。 當指定時，數據需要成功寫入number個節點才算成功，如果寫入過程中有節點故障，可能導致這個條件一直不能滿足，從而一直不能向客戶端發送確認結果，針對這種情況，客戶端可設置wtimeout選項來指定超時時間，當寫入過程持續超過該時間仍未結束，則認為寫入失敗。
journal無論如何都是建議打開的，設置j:true，只是說driver調用getLastError()之后是否要等待journal寫入完成再返回。並不是說不設置j:true就關閉了server端的journal
一般來說，MongoDB建議在集群中使用 {w: “majority”} 設置。在一個集群是健壯的部署的情況下（如：足夠網絡帶寬，機器沒有滿負荷），這個可以滿足絕大部分數據安全的要求，因為MongoDB的復制在正常情況下是毫秒級別的，往往在Journal刷盤之前已經復制到從節點了。如果你追求完美，那么可以再進一步使用