分布式系统中的竞赛条件

Question

我们有一组功能依赖的、相互交织的验证逻辑的微服务。例如“信用卡”服务和“贷款”服务。当用户有信用卡时，就不应该发放贷款，反之亦然。因此，在处理请求时，我们使用API调用对这些服务进行验证，并考虑批准请求。当两者同时在分布式系统中启动时，如何处理这两个场景。

我们如何防止客户同时获得贷款和信用卡。我正在考虑使用分布式锁来实现解决方案。想知道除了锁之外是否还有其他的可能性。

Answer 1

这种问题在分布式系统中很常见。最简单的解决方案是将检查是否允许更改与请求进行更改结合起来。这种技术在许多情况下都很有用。例如，让我们暂时忘记贷款，只关注信用卡。假设您有一个包含活动信用卡应用程序的表，并且正在运行多个服务实例。您希望防止某人同时拥有两个活动应用程序(例如，它们刷新页面并提交两次)。在服务无状态的情况下，每个提交都可能以服务的不同实例结束。因为一个服务不知道另一个服务在做什么，所以我们必须查找数据库来解决这个问题。

一种方法是有条件地进行插入或更新。例如，只有当活动应用程序的计数为零时，才会将应用程序状态更新为active。这是作为DB上的一个原子语句完成的。然后检查更新的记录数量。如果为零，则该更新被抢占，如果是其他的，则调用成功。这有点像乐观锁定，它比悲观锁定的问题要小。即使您使用悲观锁，我所描述的那种方法也需要用来获取锁。你最好跳过这个额外的一层，说到重点。

两种不同服务的情况基本上是相同的问题。问题是您是否对每个存储都有不同的存储，以及它们是否具有强大的一致性保证。如果您对每个服务都有单独的DB解决方案(正如在微服务体系结构中所期望的那样)，您可能希望引入第三个服务作为此类场景的仲裁器。这将允许您选择具有强一致性保证的存储。

最后，您需要平衡这一成本与其发生的可能性。事后做些检查就足够了吗？如果它几乎从来没有出现，联系客户，告诉他们他们的应用程序都被拒绝，他们需要选择一个从业务的角度来看可能就足够了。

Answer 2

我想你在你的第一句话中说过了--当你把相互交织或分布的验证逻辑交织在一起时，解决方案就变得更加复杂了。我的第一步是将验证逻辑重构为客户验证服务(因为缺少更好的语言)。大多数国家都有类似的评级服务，公司内部也有黑名单和客户信息。对于大多数业务来说，确定是否应该与客户做生意将是一项非常相似的任务。

现在，您还将遇到一个检查时间到使用时间问题。客户可以同时通过两次检查，而期望的行为是拒绝第二次检查。

理想情况下，我们希望避免跨微服务的事务处理系统。第一步是在检查时暂时暂停客户验证检查系统。这不是一个确定性的修复，但将是一个伟大的第一道防线。

支票可能会发出一个时间型OTP。这将关闭循环，因为密码只会是好的，而临时块将拒绝进一步的请求。

我找到了一篇有趣的文章，为最终一致性提供了一个案例。现在，这种方法的安全性取决于在授予用户任何特权之前，您的进程是否有另一个检查点。例如。信用卡需要打印，贷款需要处理。你能负担得起“批准”贷款或信用卡，但不发行卡或资金，利用处理时间，以弥补政策失败？