我有这些操作：
所以在这种情况下，我必须确保这些操作是原子的，因为更新 doc.prop 必须基于当前值。
这里有两种方法： 1.在doc中添加“valueKey”(Number)属性，更新doc时确保valueKey匹配。更新后增加 valueKey。如果 valueKey 不匹配，则将此更新标记为失败并重试。 2.在操作过程中，使用MongoDB提供的“fsyncLock”锁定整个mongod实例。
我上面提到的第一种方法很好，但是当同时面对大量这些操作时，“失败”和“重试”会很频繁。
第二种方法，我没有尝试过，我认为它是用于备份数据库的，在这种情况下并不好。
所以我想知道还有其他有效的方法吗？
【问题讨论】：
标签： mongodb locking atomic consistency
第一种方法称为optimistic lock。乐观锁假设发生冲突的概率很低，否则，正如您已经指出的那样，有很多重试。这些重试也可能具有破坏性 - 如果文本被编辑，合并编辑可能有意义，但对于电话号码几乎没有意义。
锁定整个数据库是悲观（离线）锁定的一种极端形式，它故意降低系统的并发性。但是，这是有问题的，因为 clients don't know what's going on - 他们的编辑将简单地失败，这是最糟糕的用户体验。
所以悲观锁只有在客户端有机会真正知道某些东西被锁定时才有意义。例如，您需要以某种方式通知用户无法编辑她想要编辑的项目，因为其他人已经处于该项目的编辑模式。这也有问题，尤其是当另一个用户离开屏幕并阻止所有其他用户时。
但是，如果您想使用悲观锁，则绝对不应该通过全局数据库锁之类的东西来实现：只需锁定项目本身并在代码中实现锁定的业务逻辑。
士气：这不是技术问题，而是逻辑问题。 Google Docs 演示了一种允许同时编辑多个用户的方法，但它很难实现，在其他类型的应用程序中的使用有限，并且仍然被一些用户认为是烦人的。 Git 等展示了另一种方法，其中分支、合并和冲突的逻辑也暴露给用户，但是是异步的（多版本并发控制）。
【讨论】：