App Engine NDB 事务冲突答案

【问题标题】：App Engine NDB Transaction CollisionApp Engine NDB 事务冲突
【发布时间】：2014-12-17 04:18:28
【问题描述】：

在 App Engine 文档 (https://cloud.google.com/appengine/docs/python/ndb/transactions) 中，它说：“如果事务与另一个事务‘冲突’，它将失败；NDB 会自动重试此类失败的事务几次。” p>

这句话的意思对我来说并不完全清楚。如果事务 A 先开始，然后事务 B 在 A 的操作过程中开始，是否意味着 A 和 B 都会失败并重试？还是只有 B 失败，而 A 继续？

还有一个相关的问题：是否存在事务会部分完成然后回滚的情况？还是每次交易尝试都没有进入函数，直到有机会完成函数？

谢谢！

【问题讨论】：

【解决方案1】：

最有可能的是，其中一个事务会成功而另一个会失败（并被重试），但您无法提前知道哪个事务； 也有可能两者都失败（并单独重试）。

是的，fail 通常表示partly progresses but then gets rolled back。这是一种“乐观并发”的安排，而不是基于先发制人的locking。

请记住，在许多分布式机器上通常会请求潜在的冲突事务——通过“乐观并发”（检测冲突并回滚无法干净完成的冲突）以外的任何方式来协调它们是不可行的。

【讨论】：

感谢您的回复！从您所写的内容来看，这听起来像乐观并发控制并不能保证多个并发请求中的任何一个都将在不中断的情况下完成，而不是在锁定系统中（请求将按顺序进行，保证基线性能水平）。鉴于此，我不太明白你的最后一句话；似乎在具有许多并发请求的系统中，悲观控制系统会胜过乐观控制系统。你介意指出我推理中的错误吗？谢谢！
在一个有许多冲突几乎同时请求的分布式系统中，性能无论如何都会很糟糕——要么是由于多次重试，要么是由于建立分布式锁的巨大开销。这就是为什么例如建议按cloud.google.com/appengine/articles/sharding_counters shard 计数器。但是在基于锁定的系统中，即使在零需求的情况下，您也会付出同样高昂的代价——交易不会发生冲突——在乐观的系统中，您只需在需要时支付很少的费用。类比：TCP 指数退避；以太网战胜令牌环:-)。