spring-boot - 如何处理和更新 Actor System 中的共享哈希映射？

Question

嗨，我有 meta-data 和 HashMap 对象，需要在我的 Actor 类中访问，并且需要查找。如果找到密钥，我应该在 Actor 业务逻辑中使用它。如果没有找到，我需要创建一个键和值并更新 HashMap 对象。

那么如何在 Actor System 中处理这个问题呢？如您所知，每个参与者实例都会同时生成一个未找到的密钥，这将导致重复和不稳定。那么处理这种情况的行业标准是什么？请提供您的建议如何处理它。

标签： spring-bootakkaactor

Answer 1

如果我对您的理解正确，您的情况是，您有一个可以在多个参与者中访问的哈希映射，并且您想知道如何在哈希映射中保持所有参与者的一致状态。

应该有一个发布者参与者和几个订阅者参与者。发布者持有哈希映射的规范副本。发布者首先将哈希映射的副本发送给所有订阅者参与者。这些订阅者开始在哈希映射上执行业务逻辑。

当订阅者 Actor 中的业务逻辑想要更新哈希映射时，它会向发布者 Actor 发送一条消息。订阅者不会更新其本地参与者状态中的哈希映射。相反，它等待发布者发布的哈希映射。

发布者参与者接受来自订阅者的键值对并使用它来更新其哈希映射的规范副本。然后它将更新的哈希映射发布给所有订阅者。

订阅者有两种方式将其键值对发送给发布者。一种是异步的，另一种是同步的。第一个使用tell，第二个使用ask。Tell 是轻量级的， ask 是重量级的。Ask 的优点是在将更新发送给发布者和接收更新的哈希映射之间没有间隙。当然，发出请求的订阅者会收到两份更新后的哈希图：第一次作为请求的响应，第二次是发布者将哈希图发布给所有订阅者。这不会导致任何问题，因为 Akka 保证首先发送的消息将首先被接收。由于这个原因，以及哈希映射上没有发生本地更新的事实，哈希映射的第二个发布版本永远不会导致从哈希映射中临时删除最近的写入。为了安全起见，您可能希望在发布的消息中包含一个标志，告诉订阅者参与者哪个订阅者可以忽略发布的哈希映射，因为它已经收到它作为对询问的响应。

此解决方案将保证一致的哈希映射状态，但此同步方法可能不足以满足您的应用程序。订阅者参与者可以覆盖彼此的更改，这可能不是您想要的。为了防止这种情况，可能需要在各个订阅者参与者中分离业务逻辑。