mongodb 的交易担保
Transactional guarantee in mongodb
因此，我正在对 MongoDB 进行研究，以符合高层管理人员决定采用开源并将现有产品数据库从 SQL 服务器迁移到 MongoDB 并改造整个事情。请注意，我们的数据库应该关注数据一致性和交易保证。
我发现了这个 post：Click here。 post总结如下：
MongoDB claims to be strongly consistent, but a lot of evidence
recently has shown this not to be the case in certain scenarios (when
network partitioning occurs, which can happen under heavy load). This
means that you can potentially lose records that MongoDB has
acknowledged as "successfully written".
In terms of your application, if you have a need to have transactional
guarantees (meaning if you can't make a durable write, you need the
transaction to fail), you should avoid MongoDB. Example scenarios
where strong consistency and durability are essential include "making
a deposit into a bank account" or "creating a record of birth". To put
it another way, these are scenarios where you would get punched in the
face by your customer if you indicated an operation succeeded and it
didn't.
那么，我的问题如下：
1) "lost data" 在当前版本的 MongoDB 中仍然有效到什么程度？
2) 在MongoDB?
中可以采取什么方法保证交易保障
我很确定如果像 PayPal 这样的公司确实使用 MongoDB，肯定有办法克服这些问题。
写关注参考
Write concern describes the level of acknowledgement requested from MongoDB for write operations to a standalone mongod or to replica sets or to sharded clusters. In sharded clusters, mongos instances will pass the write concern on to the shards.
post 中的参考资料已经在这里讨论过（例如，这里有一个：MongoDB: Does Write Concern guarantee the write on primary plus atleast one secondary）。无需重复您的问题。
博客 "Aphyr" 主要使用这些文章来宣传它自己的技术（如果您阅读了整个博客，您会发现他们有自己的数据库并在市场上销售）。他们显示的每个数据库都会丢失数据，除了他们自己的。
2) What approach can be take to ensure transactional guarantee in MongoDB?
我同意您应该在客户端代码中处理数据库问题，否则您的客户端如何在分区事件中保持一致？
因为你不是哈利波特（是吗？）我会说你需要检查客户端代码中抛出的异常并根据需要对它们做出反应。
1) To what extend does "lost data" still valid in current version of MongoDB?
至于他在 2.4.3 中提到的错误：他没有（正如我在链接 post 中提到的那样）再次说明错误参考，仍然没有评论。
除了 2 写入 6,000？这比我在分区 MySQL 中看到的数据丢失要少！所以不要太寒酸。
我没有在我自己的应用程序中注意到这种行为，而且从小型网站到超大网站，我没有注意到有人重现那篇文章中显示的基准类型场景，我很怀疑你会。
I am pretty sure that if company like PayPal do use MongoDB, there is certainly a way of overcoming these issue.
他们会进行严格的编码以确保分布式环境中的一致性。
当然，他们会根据情况选择合适的技术...
因此，我正在对 MongoDB 进行研究，以符合高层管理人员决定采用开源并将现有产品数据库从 SQL 服务器迁移到 MongoDB 并改造整个事情。请注意，我们的数据库应该关注数据一致性和交易保证。
我发现了这个 post：Click here。 post总结如下：
MongoDB claims to be strongly consistent, but a lot of evidence recently has shown this not to be the case in certain scenarios (when network partitioning occurs, which can happen under heavy load). This means that you can potentially lose records that MongoDB has acknowledged as "successfully written".
In terms of your application, if you have a need to have transactional guarantees (meaning if you can't make a durable write, you need the transaction to fail), you should avoid MongoDB. Example scenarios where strong consistency and durability are essential include "making a deposit into a bank account" or "creating a record of birth". To put it another way, these are scenarios where you would get punched in the face by your customer if you indicated an operation succeeded and it didn't.
那么，我的问题如下：
1) "lost data" 在当前版本的 MongoDB 中仍然有效到什么程度？
2) 在MongoDB?
我很确定如果像 PayPal 这样的公司确实使用 MongoDB，肯定有办法克服这些问题。
写关注参考
Write concern describes the level of acknowledgement requested from MongoDB for write operations to a standalone mongod or to replica sets or to sharded clusters. In sharded clusters, mongos instances will pass the write concern on to the shards.
post 中的参考资料已经在这里讨论过（例如，这里有一个：MongoDB: Does Write Concern guarantee the write on primary plus atleast one secondary）。无需重复您的问题。
博客 "Aphyr" 主要使用这些文章来宣传它自己的技术（如果您阅读了整个博客，您会发现他们有自己的数据库并在市场上销售）。他们显示的每个数据库都会丢失数据，除了他们自己的。
2) What approach can be take to ensure transactional guarantee in MongoDB?
我同意您应该在客户端代码中处理数据库问题，否则您的客户端如何在分区事件中保持一致？
因为你不是哈利波特（是吗？）我会说你需要检查客户端代码中抛出的异常并根据需要对它们做出反应。
1) To what extend does "lost data" still valid in current version of MongoDB?
至于他在 2.4.3 中提到的错误：他没有（正如我在链接 post 中提到的那样）再次说明错误参考，仍然没有评论。
除了 2 写入 6,000？这比我在分区 MySQL 中看到的数据丢失要少！所以不要太寒酸。
我没有在我自己的应用程序中注意到这种行为，而且从小型网站到超大网站，我没有注意到有人重现那篇文章中显示的基准类型场景，我很怀疑你会。
I am pretty sure that if company like PayPal do use MongoDB, there is certainly a way of overcoming these issue.
他们会进行严格的编码以确保分布式环境中的一致性。
当然，他们会根据情况选择合适的技术...