1.之前用mongodb資料的時候，有時候會有丟失，一開始考慮到是mongodb的安全效能不行嗎，在網上看了一些資料，做了一些解釋：

MongoDB確實在其發展的過程中，有一些資料持久化的問題沒有處理好，特別是一些預設值的選定上。大部分使用者會拿來就用，直到遇到問題之後才發現他們應該在開始的時候做一些必要的配置。但是，所有這些已經被發現的問題也好，預設設定也好，已經在 MongoDB 2.6以後得到了妥善的解決。我可以負責任地告訴你，你看到的資料安全問題，基本上都是2.4或者之前版本的問題或者是使用者配置的問題。接下來我們來仔細分析一下MongoDB的資料安全機制，通過這個分析來更好地理解為什麼有丟資料問題的說法，以及如何來正確的配置MongoDB來保證資料的安全。
MongoDB的資料安全包括以下幾個概念：
恢復日誌（Journal）
寫關注（Write Concern)
恢復日誌
在MySQL， PostgreSQL，Oracle等關係型資料庫裡都有一個Write Ahead Log（Redo Log）的機制用來解決因為系統掉電或者崩潰時導致記憶體資料丟失問題。MongoDB 的journal就是實現這個目的的一種WAL日誌。在MongoDB 2.0之前，Journal沒有被支援或者不是一個預設開的選項。所以當你進行寫入操作時。在沒有Journal的情況下，MongoDB是這樣儲存資料的：

簡單來說，資料在寫入記憶體之後即刻返回給應用程式。而資料刷盤動作則在後臺由作業系統來進行。MongoDB會每隔60秒強制把資料刷到磁碟上。那麼大家可以想象得到，如果這個時候發生了系統崩潰或者掉電，那麼未刷盤的資料就會徹底丟失了。如果大家看到的部落格是2011年左右的，那基本上是碰到了這種情況。
自從2.0開始，MongoDB已經把Journal日誌設為預設開啟。

在上圖的情況下，MongoDB會先把資料更新寫入到Journal Buffer裡面然後再更新記憶體資料，然後再返回給應用端。Journal會以100ms的間隔批量刷到盤上。這樣的情況下，即使出現斷電資料尚未儲存到檔案，由於有Journal檔案的存在，MongoDB會自動根據Journal裡面的操作歷史記錄來對資料檔案重新進行追加。
有細心的同學可能注意到，Journal檔案是100ms 刷盤一次。那麼要是系統掉電正好發生在上一次刷journal的50ms之後呢？這個時候，我們就可以來看一下MongoDB持久化的下一個概念了：寫關注
寫關注(Write Concern)
寫關注（或翻譯為寫安全機制）是MongoDB特有的一個功能。它可以讓你靈活地指定你寫操作的持久化設定。這是一個在效能和可靠性之間的一個權衡。 寫關注有以下幾個級別：
{w: 0} Unacknowledged

Unacknowledged指的是對每一個寫入操作，MongoDB並不會返回一個是否成功的狀態值。這個級別是寫入效能最好但也是最不安全的級別。比如說，你試圖插入一個違反了唯一性的文件（重複的身份證號），那麼MongoDB會拒絕寫入並報錯。但是由於驅動端並沒有在乎你的報錯，應用程式還滿心歡喜以為一切都沒問題，下回再來查詢那條資料的時候就會出現資料缺失的情況。
有不少時候MongoDB用來儲存一些監控和程式日誌資料，這個時候如果你有1、2條資料丟失，是不會對應用程式有什麼影響的。基於這些MongoDB早些時候不成熟考量，MongoDB在2.2之前的預設設定就是 {w:0}。這是個讓MongoDB 悔恨無比的選擇，因為這個是很多人覺得MongoDB資料不安全的根本原因。
在MongoDB 2.4，這個設定已經被改為下面的 {w:1}
{w: 1} Acknowledged

Acknowledged 的意思就是對每一個寫入MongoDB都會確認操作的完成狀態，不管是成功還是失敗。當然這個確認只是基於主節點的記憶體寫入。但就是這個級別，可以偵測到重複主鍵， 網路錯誤，系統故障或者是無效資料等錯誤。
自2.4版本起，MongoDB的預設寫安全設定就是 {w:1} Acknowledged。在這種情況下，出現因為系統故障掉電原因而導致的資料丟失只會是我們早些提到的日誌沒有及時刷盤的情況。如果你不能接受因為系統崩潰而引起的可能的100ms的資料損失，那麼你可以選用下一個級別： {j:1} Journaled
{j:1} Journaled

使用這種方式意味著每一次的寫操作會在MongoDB實實在在的把journal落盤以後才會返回。當然這並不意味著每一個寫操作就等於一個IO。MongoDB並不會對每一個操作都立即刷盤，而是會等最多30ms，把30ms內的寫操作集中到一起，採用順序追加的方式寫入到盤裡。在這30ms內客戶端執行緒會處於等待狀態。這樣對於單個操作的總體響應時間將有所延長，但對於高併發的場景，綜合下來平均吞吐能力和響應時間不會有太大的影響。特別是你能給journal部署一個對順序寫有優化的IO頻寬足夠的專門的儲存系統的話，這個對效能的影響可以降到最低。
那麼使用 {j:1} 是不是就100% 安全了呢？如果是單機版本，這個基本上就是可以確保的了（除非硬碟損壞）。可是在複製集的場景下，我們還需要來考慮一種更高的級別： {w: “majority”}
{w: “majority”} 寫到多數節點
MongoDB 的預設部署是至少3個節點的複製集（Replicaset）。使用複製集的好處很多，最關鍵的就是提高系統的高可用性。另外一個好處就是提供資料的永續性。在複製集下哪怕你的整個主機連記憶體帶硬碟壞掉，你的資料還是健康的存在在第二臺或者第N臺從節點上。但是複製集作為一種分散式的架構也對我們資料一致性提出了新的挑戰。以上述的{w: 1} 寫安全配置為例，我們來分析一種比較複雜的場景。

01:00:00 網路故障，主從之間網路斷開
01:00:01 應用寫入一個文件： {ts: “01:00:01〃} 注意這個文件無法複製到B和C。此時主節點尚未完全確認網路已故障，所以按照{w:1}規則繼續接受並確認寫入。
01:00:02 主節點A意識到自己無法和從節點B，C 聯絡上，主動降級為從節點，停止接受寫操作
01:00:05 B,C 選舉結果成功，B升級為主節點。B開始接受寫操作。{ts: “01:00:06〃}
01:00:08 網路恢復，A重新加入叢集。這個時候A的oplog 和B的oplog已經有不一致了。A會主動把B上面不存在的寫操作回滾掉(rollback)，並寫入一個回滾檔案。
在這個時候應用如果再去查詢 {ts: “01:00:01〃}這個文件，MongoDB 將會說文件不存在！
怎麼辦怎麼辦? {w: “majority”} 就是我們的答案。 “majority” 指的是“大多數節點”。使用這個寫安全級別，MongoDB只有在資料已經被複制到多數個節點的情況下才會向客戶端返回確認。

我們來看一下在使用 {w: “majaority”} 之後，剛才的情況就變成了：
01:00:00 網路故障，主從之間網路斷開
01:00:01 應用要求寫入一個文件： {ts: “01:00:01〃} 文件會首先成功寫入主節點。但是由於網路斷開這個文件無法複製到B和C。因為無法滿足{w:”majority”}要求，從應用的角度這個文件並沒有寫入成功。
01:00:02 主節點A意識到自己無法和從節點B，C 聯絡上，主動降級為從節點，停止接受寫操作
01:00:05 B,C 選舉結果成功，B升級為主節點。B開始接受寫操作。{ts: “01:00:06〃}
01:00:08 網路恢復，A重新加入叢集。這個時候A會產生回滾，把{ts: “01:00:01〃}這個文件刪除。 此時叢集的資料狀態為一致和正確的。
至此，如果使用 {w: “majority”, j:1 }, 那麼MongoDB可以滿足所有級別資料永續性的要求。值得注意的是在2013年5月Kyle Kingsly 發表了一篇部落格 Call Me Maybe:http://aphyr.com/posts/284-call-me-maybe-mongodb在這片文章裡Kyle 彙報了一些關於 {w: “majority”} 的bug， 這些bug已經在2.6裡被解決了。當然像Sven那樣的譁眾取寵之流，估計並沒有去研究3.0裡面是否真的有問題，而是隨便google了一下幾年前的東西來做文章。
總結
一般來說，MongoDB建議在叢集中使用 {w: “majority”} 設定。在一個叢集是健壯的部署的情況下（如：足夠網路頻寬，機器沒有滿負荷），這個可以滿足絕大部分資料安全的要求，因為MongoDB的複製在正常情況下是毫秒級別的，往往在Journal刷盤之前已經複製到從節點了。如果你追求完美，那麼可以再進一步使用{j:1} 。兩者相結合，
傳說中MongoDB 丟資料的事情，確實已經成為傳說了。
後記：在我寫這篇文章之時，社群又有人彙報資料丟失的問題。說的是每一萬條記錄就會丟一兩條記錄。對於這種情況，我的第一反應就是：查查你的程式碼吧，很多時候往往問題出在程式上。果不其然，經過仔細檢查，原來是程式碼的問題。