mongodb中的交易擔保

Question

因此，我正在對MongoDB進行研究，以符合高層管理人員的決策，即采用開放源代碼並將現有產品數據庫從SQL Server遷移到MongoDB並進行整體改進。 請注意，我們的數據庫應側重於數據一致性和事務保證 。

我發現這篇文章： 單擊此處 。 帖子摘要如下：

MongoDB聲稱是高度一致的，但是最近有大量證據表明，在某些情況下（當發生網絡分區時，這可能會在高負載下發生）並非如此。 這意味着您可能會丟失MongoDB確認為“成功寫入”的記錄。

就您的應用程序而言，如果您需要事務保證（這意味着如果無法進行持久寫入，則需要使事務失敗），則應避免使用MongoDB。 強一致性和持久性至關重要的示例方案包括“在銀行帳戶中存款”或“創建出生記錄”。 換句話說，在這些情況下，如果您指示操作成功而沒有成功，那么您的客戶就會被打在臉上。

因此，我的問題如下：
1）在當前版本的MongoDB中，“丟失的數據”仍然有效到什么程度？
2）可以采取什么方法來確保MongoDB中的交易擔保？

我非常確定，如果像PayPal這樣的公司確實使用MongoDB，肯定有解決這些問題的方法。

Answer 1

該帖子中的參考資料之前已經在這里進行了討論（例如，這里是其中之一： MongoDB：Write Concern是否保證在primary上至少寫入一個Secondary上的內容 ）。 無需重復您的問題。

博客“ Aphyr”主要使用這些文章來宣傳自己的技術（如果您閱讀了整個博客，您將意識到他們擁有自己的數據庫，他們正在營銷）。 他們顯示的每個數據庫都會丟失自己的數據庫。

2）可以采取什么方法來確保MongoDB中的交易擔保？

我同意您應該在客戶端代碼中處理數據庫問題，如果不能，那么在發生分區的情況下客戶端將如何保持一致？

由於您不是Harry Potter（是嗎？），我會說您需要檢查客戶端代碼中引發的異常，並根據需要對它們做出反應。

1）在當前版本的MongoDB中，“丟失的數據”仍然有效到什么程度？

至於他在2.4.3中提到的錯誤：正如我在鏈接文章中提到的那樣，他未能再次陳述該錯誤參考，所以仍然沒有評論。

另外2寫6,000？ 這比我在分區上的MySQL中看到的數據丟失少！ 所以不要太破舊。

我沒有在自己的應用程序中注意到這種行為，並且從小型站點到超大型站點，我都沒有注意到有人復制了該文章中顯示的基准類型方案，我非常懷疑您會這樣做。

我非常確定，如果像PayPal這樣的公司確實使用MongoDB，肯定有解決這些問題的方法。

他們將使用嚴格的編碼來確保分布式環境中的一致性。

當然，他們會從針對情況選擇合適的技術開始...

Answer 2

寫關注參考

寫關注描述了MongoDB請求對獨立mongod或副本集或分片群集進行寫操作的確認級別。 在分片群集中，mongos實例會將寫關注事項傳遞給分片。

https://docs.mongodb.org/v3.0/reference/write-concern/