concurrency - 业务应用程序 - 使用消息传递的悲观并发

Question

我们在我们的一个项目中使用消息传递来实现悲观并发。这意味着如果消息传递中断（通道中断），并发性就会下降。

• 这是在其他业务应用程序中完成的吗？
• 如果消息传递失败，您是否关闭应用程序（注销用户）？

我更多地考虑将乐观和悲观并发结合起来。那么如果悲观并发下降了，还有一个备用乐观并发......

谢谢，列文卡登

Answer 1

像往常一样，我认为答案取决于您正在构建的业务应用程序的性质。您的应用程序的 SLA 是什么？它的任务有多关键？

如果您的消息传递基础设施出现故障，除了锁定服务之外，应用程序是否继续运行？如果是这样，那么您可能有义务确保您的并发控制机制不是单点故障。

此外，实现真正分布式、容错的悲观锁定机制的主题需要解决共识问题。大多数悲观锁定算法依赖于可以响应锁定请求的单个序列化授权（即有一个“锁定”表或者可能有一个单例锁定服务器）。

这样的设计到处都是单点故障。要回答您的第一个问题——是的，我已经看到业务应用程序使用消息传递来提供悲观锁定。然而，对于我遇到的大多数业务应用程序来说，完全解决容错问题似乎有点过头了。

乐观并发控制本质上不存在这个问题，这就是为什么它在分布式、容错应用程序中通常是首选的原因。但是，我意识到业务需求经常胜过易于实施。

如果您对该主题感兴趣，Google 已经发表了一篇关于他们的Chubby Lock Service的文章，该服务利用了Paxos 共识协议。