考虑以下情况： 实体 A 上有一个更新请求，以创建子实体 A.B。 A 上可能有很多 B，每个 B 都有唯一的电子邮件地址。 实体 A 是一个共享实体，同一个请求可以在多个服务器上并行发生（可扩展的微服务）。
为了创建 A.B，我们必须验证 B 不作为 A 上的子实体存在（根据 B 的电子邮件地址）。
处理此更新请求的服务应锁定 A（通过它的唯一 ID）以确保更新安全。
我的问题更多的是概念性而非技术性：
在这种情况下锁定资源 A 是否是此更新任务的业务逻辑的一部分？
您是否考虑将资源锁放在一个单独的中间件中，而不是放在处理验证和更新过程的中间件中？ （另一种选择是将锁作为业务逻辑的一部分，直接放在负责业务逻辑的中间件中。）
【问题讨论】：
标签： locking domain-driven-design middleware distributed-lock
所选择的争用问题解决方案的技术实现显然不是业务逻辑，但选择正确的解决方案需要业务知识。
我的意思是，您必须了解业务的运作方式，才能确定在并发场景中保护数据完整性的正确方法。并发冲突多久会发生一次？冲突可以自动解决吗？应该有什么矛盾？不仅如此，企业很可能会接受最终一致性而不是强一致性。
简而言之，在并发场景中保护数据完整性的机制不应该是领域的一部分。这些可能会在应用程序服务层或基础架构层进行，但业务专家必须参与有关如何解决并发冲突以及这些冲突如何影响业务的讨论。
【讨论】：
锁定不是与业务相关的问题（除非您的业务正在构建分布式数据库），因此永远不应将其视为业务逻辑的一部分。
此外，您不应该自己实现分布式锁定，而应该依赖打包的解决方案，这最好是您的数据持久性解决方案的一部分。
这是how to do this with Redis 上的一篇文章，讨论了一种称为 Redlock 的算法。这是一篇博客文章，链接到有关 building concensus in Cassandra 的文章。而且，这里有一个关于concurrency in Mongo 的链接。正如您将从这些文章中看到的那样，分布式锁定是一个您可能不想自己解决的大而复杂的问题。
【讨论】：