使用消息总线替代演员之间的常规消息传递（例如，在scala中）

Question

我有一个Java Web服务，我将在Scala中从头开始重新实现。我有一个基于演员的新代码设计，大约有10-20个演员。其中一个用例有这样的流程：

  

Actor A获取消息a，创建数个b消息由Actor B处理（可能是多个实例，用于负载平衡），产生多个{ {1}}有关演员c的消息，依此类推。

在上面的场景中，一条消息C可能导致几千条消息来回发送，但我不希望每天发送少量a条消息（是的，目前这不是一项繁忙的服务。）

我有以下要求：

1. 不应丢失或重复留言。我的意思是如果系统在处理b消息的过程中重新启动，则应在重启后拾取未处理的系统。另一方面，不应该再次处理已处理的消息（这些消息最终将开始一些大的计算，并且重复它们是昂贵的）。
2. 它应该易于扩展。我的意思是在将来，我可能想要在系统中添加一些其他组件，这些组件可以读取所有通信（或部分通信），例如记录发生的事情，或计算处理了多少b条消息，或者用b消息做一些新的事情（在已经发生的事情旁边），等等。请注意，这些“组件”可以是用其他语言编写的独立应用程序。

我是消息总线技术的新手，但从我所看到的，这些要求听起来像“消息总线”提供的内容，如RabbitMQ，Kafka，Kestrel，但我也看到akka还提供了一些持久性的方法。 我的问题是，鉴于各种各样的可能性，我迷失了使用哪种技术。我读到像卡夫卡这样的东西可能对我的应用来说太过分了。但我也不确定akka持久性是否满足了我的两个要求（尤其是可扩展性）。

我的问题是：我应该选择企业短信总线吗？像卡夫卡这样的东西？或者类似akka持久性的东西会做什么？ 或者，如果我自己实现某些东西（支持AMQP以允许扩展性），它会更快更合适吗？

当然，如果您知道符合此目的的某些内容，也欢迎具体的技术建议。

Answer 1

像RabbitMQ这样的消息总线（通常称为消息代理）可以处理＆＃34;开箱即用＆＃34;您在问题中描述的所有消息传递机制。具体做法是：

RabbitMQ具备开箱即用的能力＆＃34;：

• 在不重复消息的情况下发送消息。
• 扩展系统并添加日志记录并拥有您描述的统计信息。