资源锁定和业务逻辑

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

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

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

我的问题是不是技术更概念化：

是否锁定资源A在这种情况下是这样的更新任务的业务逻辑的一部分？
你会考虑把资源锁放在一个单独的中间件中，而不是处理验证和更新过程的中间件吗？（另一个选项是把锁作为业务逻辑的一部分，并把它直接负责业务逻辑中间件。）

2016-11-22 user132440

锁定是不是企业相关的问题（除非你的业务是建立分布式数据库），因此不应被视为业务逻辑的一部分。另外，您不应该自己实现分布式锁定，而应该依赖于打包的解决方案，该解决方案最好是您的数据持久性解决方案的组成部分。

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

来源

2016-11-22 19:00:45

感谢您的评论。由于我知道并确定它很复杂，我当然不打算自己做 - 但使用redis。我的问题是关于代码中我们希望获得资源锁定的地方：在主代码流中 - 将代码中的代码段指向需要锁定并在本节中锁定和解锁的代码段，或者将代码段设置为预处理动作，即在之前专门用于锁定的中间件中。 – user132440

顺便说一句：它可能是这种情况下，一致性是不可能的redis –

哦，就像我说的，它不是业务逻辑，因此它应该是持久性逻辑的一部分。最好不要编写获取和释放锁代码 - 它应该是你正在使用的框架的一部分。 –

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

我的意思是，您必须了解业务是如何工作的，才能确定在并发场景中保护数据完整性的正确方法。并发冲突发生的频率如何？冲突可以自动解决吗？什么应该是冲突？不仅如此，业务部门可能会很好地接受最终的一致性而非强大的一致性。

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

来源

2016-11-22 21:56:26 plalx

资源锁定和业务逻辑

回答

相关问题