使用 Actors/AKKA 的面向会话的异步架构答案

【问题标题】：Session Oriented Asynchronous Architecture using Actors/AKKA使用 Actors/AKKA 的面向会话的异步架构
【发布时间】：2014-01-23 03:43:10
【问题描述】：

我们正在构建的应用程序有一个非常简单的概念：它接收来自数据库的传入事件，并且对于每个事件，它通过显示一个菜单与客户端（在事件中）打开一个交互式会话。根据客户的反应，我们进入下一个状态或采取一些具体行动（例如转移资金）。

会话彼此独立。例如，假设我们从数据库中获得两个事件，说明客户端 A 和 B 已达到零帐户余额状态。为了响应这个事件，我们建立了到 A 和 B 的两个连接，显示一个如下所示的菜单：

 Please select an option:
 1. Get $5
 2. Get $10
 3. Ignore

对于选项 1 和 2，我们要求以 second menu 的形式进行确认。

 Are you sure?
 1. yes
 2. no

在这种情况下，我们将有两个会话。客户端 A 可能选择选项 1 (1. Get $5)，而客户端 B 选择选项 3 [在第一个菜单中]。对于客户 A，我们将显示 第二个菜单（上图），如果响应为 1. yes，我们将采取一些具体行动，例如转移资金和关闭会话。

所有客户端通信均由第 3 方系统完成，该系统采用 JSON 格式，包括客户端地址、菜单文本并将响应返回给我们。它负责在线上实际维护会话，而我们只需要进行响应关联和处理会话状态。

我们预计会同时处理 50,000 个此类会话。

之前，我们使用 SEDA 模型在 Java 中设计了系统。听说过 Actors，我们愿意检查一下并编写一个快速的 PoC 项目（Java/AKKA）。我的问题是：

有没有人有过构建此类应用程序的经验？ AKKA 处理 50,000 个同时会话是否太多？（注意，我们只是在等待响应。当响应到来时，根据答案跳转到下一个阶段，所以应该是可以的）。
哪种架构风格/范式最适合 AKKA 中的这个问题？有没有解决这类问题的框架？

【问题讨论】：

首先，Akka 不是首字母缩写词。其次，如果您避免使用全局状态，则扩展 Akka 很简单。它使水平扩展变得非常简单，并且很可能不会成为您的瓶颈（几乎肯定会成为数据库）。

标签： java scala session akka actor

【解决方案1】：

这实际上是 Akka 集群的一个相当简单的用例。 50K 会话表示为每个 Actor 实例的负载不是很高。使用集群的原因只是为了容错。

架构背后的想法是有一个 Web 层来处理与会话相对应的 RESTful 请求。这些请求将被发送到 Akka 集群并通过会话 ID 路由到适当的会话 Actor，或者将创建一个新的。会话完成后，您将停止与其关联的参与者。

请注意，会话参与者应通过调度程序向自己发送超时消息。处理完一条新消息后，actor 应通过 ActorSystem 调度程序为自己安排一条消息 15 分钟（或任何您的超时时间）。当收到新的会话消息时，应取消该计划任务，处理新的更新，然后计划新的超时。这里有一个合理的竞争条件，因为超时消息可能在会话消息之后出现在会话参与者的邮箱队列中，但是如果您的超时消息包含计划的时间（15 分钟前），您可以检查并忽略它并重新安排另一个（就像避免内存泄漏的安全机制）。如果时间大于 15 分钟前，则停止演员。

要了解如何将工作分配给会话参与者，请参阅 Typesafe 的 Activator 中的“使用 Akka 和 Java 的分布式工作人员”模板。您将拥有一个完全运行的集群 Akka 应用程序，您可以定制它来执行我上面描述的会话管理。然后，您可以导出项目并在 Eclipse/IntelliJ/Sublime/TextMate/etc 中处理它。要下载激活器，请参阅here。

【讨论】：