资源锁定和业务逻辑

Question

考虑以下情况： 对实体A有更新请求，以创建子实体A.B. A上可能有很多B，每个B都有唯一的电子邮件地址。 实体A是共享实体，同一请求可以并行发生在多个服务器中（可扩展的微服务）。

为了创建A.B，我们必须验证B在A上是否已经作为子实体存在（根据B＆＃39的电子邮件地址）。

处理此更新请求的服务应锁定A（通过它的唯一ID）以使更新安全。

我的问题更具概念性而非技术性：

1. 在这种情况下锁定资源A是否是此更新任务的业务逻辑的一部分？

2. 您是否考虑将资源锁置于单独的中间件而不是处理验证和更新过程的中间件？ （另一种选择是将锁视为业务逻辑的一部分，并将其直接放在负责业务逻辑的中间件中。）

Answer 1

所选择的争用问题解决方案的技术实现显然不是业务逻辑，但选择正确的解决方案需要业务知识。

我的意思是，您必须了解业务的运作方式，以确定在并发方案中保护数据完整性的正确方法。并发冲突会发生多少次？可以自动解决冲突吗？应该有什么冲突？不仅如此，业务部门也可以很好地接受最终的一致性而非强烈的一致性。

简而言之，在并发方案中保护数据完整性的机制不应该是域的一部分。这些可能会在应用程序服务层或基础架构层中进行，但业务专家必须参与有关如何解决并发冲突以及这些冲突如何影响业务的讨论。

Answer 2

锁定不是与业务相关的问题（除非您的业务正在构建分布式数据库），因此永远不应将其视为业务逻辑的一部分。

此外，您不应该自己实现分布式锁定，而应该依赖于打包的解决方案，该解决方案最好是数据持久性解决方案的一部分。

这是一篇关于how to do this with Redis讨论称为Redlock的算法的文章。这是一篇链接到building concensus in Cassandra文章的博客文章。而且，这是一个关于concurrency in Mongo的链接。正如您将从这些文章中看到的那样，分布式锁定是一个大而复杂的问题，您可能不想自己解决。