你们是怎么处理 MongoDB 的 WriteConflict 的？

資深大佬 : JasonLaw 5

如javascript – A lot of WriteConflict errors with MongoDB transactions – Stack Overflow中所示，假设一个事务所做的操作是“read-modify-write”，那么在多线程的环境下会出现 WriteConflict 。它介绍了两种解决方案，一种是排队系统，另一种是重新运行系统。个人觉得重新运行系统是不适合在竞争激烈的情况下使用的，那样只能让情况变得更糟。想问一下大家是怎么处理 MongoDB 的 WriteConflict 的？

额外阅读

Limitations in MongoDB Transactions – Database Trends and Applications

大佬有話說 (7)

資深大佬 : guyeu

避免 WriteConflict ？

主資深大佬 : JasonLaw

@guyeu #1 排队系统其实就是避免的一种方法，而重新运行系统更像是“在避免不了或者不避免的情况下，应该怎么做”。但是在竞争激烈的环境下，重新运行系统真的是种好的解决方案吗？

資深大佬 : Nillouise

跟 arp 解决冲突思路那样，重新运行系统需要等待一个随机时间，怎么样？

資深大佬 : guyeu

@JasonLaw #2 重新运行有一个缺陷，无法预期事务执行的顺序，所以我更倾向于在业务层面进行设计，采用一些手段（包括不仅限于分布式锁）避免数据库层面的写冲突。

主資深大佬 : JasonLaw

@guyeu #4 “ 重新运行有一个缺陷，无法预期事务执行的顺序”是什么意思？可以举个例子解释一下吗？

資深大佬 : guyeu

@JasonLaw #5 你的文章倒数第二段

> MongoDB does lock a document that is being modified by a transaction. However, other sessions that attempt to modify that document do not block. Rather, their transaction is aborted, and they are required to retry the transaction. This is potentially wasteful since other operations in the transaction will need to be re-executed, and also results in requests being serviced in a non-deterministic order.

主資深大佬 : JasonLaw

@guyeu #6 其实“请求被服务的顺序是不确定的”会更加准确一点。

> results in requests being serviced in a non-deterministic order.