我们正在构建的应用程序有一个非常简单的概念：它接收来自数据库的传入事件，并通过显示菜单为每个事件打开与客户端的交互式会话。根据客户的反应，我们进入下一个状态或采取一些具体行动(例如转移资金)。
会话是相互独立的。例如，假设我们从数据库中得到两个事件，表示客户端A和B已达到零帐户余额状态。为了响应此事件，我们建立了到A和B的两个连接。显示如下菜单：
Please select an option:
1. Get $5
2. Get $10
3. Ignore
对于选项1和2，我们要求以第二菜单的形式进行确认。
Are you sure?
1. yes
2. no
在这种情况下，我们将举行两次会议。客户端A可能选择选项1(1. Get $5)，而客户端B选择选项3(在第一个菜单中)。在客户A的情况下，我们将显示第二菜单(如上)，如果响应为1. yes，我们将采取一些具体行动，如转移资金和关闭会话。
所有客户端通信都是由第三方系统完成的，该系统接收JSON，包括客户端地址、菜单文本并向我们返回响应。它负责实际维护网络上的会话，而我们只需要进行响应关联和处理会话状态。
我们预计将并行处理50000个此类会话。
之前，我们使用SEDA模型在Java中设计了该系统。听说了Actors，我们愿意看看他们，并编写一个快速的PoC项目(Java/AKKA)。我的问题是：
有人有构建此类应用程序的经验吗？50000个同时会话对AKKA来说太多了吗？(注意，我们只是在等待回应。当回应到来时，根据答案，我们会跳到下一阶段，所以这应该是可能的)。
在AKKA中，哪种体系结构风格/范式最适合这个问题？有没有针对这类问题的框架？
这实际上是Akka集群的一个相当简单的用例。对于每个实例，表示为Actor实例的50K会话的负载不是很高。使用集群的原因只是为了容错。
该体系结构背后的想法是有一个web层来处理与会话相对应的RESTful请求。这些请求将被发送到Akka集群，并通过会话ID路由到适当的会话参与者，或者创建一个新的会话参与者。当一个会话完成时，你会停止与它相关联的参与者
请注意，会话参与者应该通过调度程序向自己发送超时消息。在处理完一条新消息后，参与者应该通过ActorSystem调度程序为自己安排一条消息15分钟(或者不管您的超时时间是多少)。当收到新的会话消息时，应取消该计划任务，处理新的更新，然后安排新的超时。这里有一个合理的竞争条件，即在会话消息之后，超时消息可能在会话参与者的邮箱队列中，但如果您的超时消息包括计划的时间(15分钟前)，您可以检查并忽略它，然后重新安排另一个(作为避免内存泄漏的安全机制)。如果时间超过15分钟，则停止该演员。
要了解如何将工作分配给会话参与者，请参阅Typesafe的Activator中的"使用Akka和Java的分布式工作者"模板。您将拥有一个完全运行的集群Akka应用程序，您可以定制它来进行会话管理，正如我上面所描述的那样。然后，您可以导出项目并在Eclipse/InIntelliJ/Sublime/TextMate/等中进行操作。要下载Activator，请参阅此处。