考虑以下情况:实体 A 有更新请求,要创建子实体 AB,A 上可能有很多 B,每个 B 都有唯一的电子邮件地址。实体 A 是一个共享实体,同一个请求可以在多个服务器上并行发生(可扩展的微服务)。
为了创建 AB,我们必须验证 B 不作为 A 上的子实体存在(根据 B 的电子邮件地址)。
处理此更新请求的服务应锁定 A(通过它的唯一 ID)以确保更新安全。
我的问题是概念性的,而不是技术性的:
在这种情况下锁定资源 A 是否是该更新任务的业务逻辑的一部分?
您是否考虑将资源锁放在一个单独的中间件中,而不是处理验证和更新过程的中间件?(另一种选择是将锁视为业务逻辑的一部分,直接放在负责业务逻辑的中间件中。)