AKKA 是否尝试在内存中执行与 Azure 服务总线队列在磁盘上执行的操作相同的操作？答案

【问题标题】：Is AKKA trying to do in memory the same as Azure Service Bus Queue does on disk?AKKA 是否尝试在内存中执行与 Azure 服务总线队列在磁盘上执行的操作相同的操作？
【发布时间】：2015-08-01 14:26:48
【问题描述】：

像 AKKA.net 这样的 Actor 模型带来了很多好处，比如可扩展性、反应性、内存缓存等......当我尝试将 AKKA 与 Azure Service Bus Queues 进行比较时，我看到几乎相同的主要除了内存缓存的好处之外，Azure 服务总线的好处。

在生产环境中，AKKA 需要多个具有更多内存和处理能力的虚拟机来处理内存中的数百万演员。对于 Azure 服务总线队列，不需要强大的主机。即使我们使用actor模型，也不需要进行监督或创建actor系统来管理数百万个actor。 Azure 服务总线自动实现可伸缩性。

从长远来看，我认为 Azure 服务总线队列具有成本效益。随着负载的增加，不需要 IT 管理员来管理它。也不需要多核的强大系统。

AKKA 参与者模型是否适合具有多核系统的本地数据中心，而不适合在考虑成本效益时可以使用 Azure 服务的应用程序？

【问题讨论】：

我认为您是在比较苹果和橙子。 Akka（从未使用过，只是读过它）是一个演员模型框架。服务总线用于持久消息传递和发布/订阅。另外：这个问题没有正确的答案，因为您要比较许多主观或特定于项目的事物：功能集、定价等。我认为这是一个征求意见的问题。
根据此链接doc.akka.io/docs/akka/2.0.2/modules/durable-mailbox.html AKKA 使用持久存储提供消息的持久性。对我来说，如果我们将业务领域分开，两者都提供相同的基础设施优势。在actor模型中，域可以作为actor存在，基础设施的好处也是内置的。在Azure SB的情况下，没有业务域。
我的意思是您将参与者模型框架与消息传递基础架构服务进行比较。它们不可互换，因为它们提供不同的功能，一个是具有 SLA 的服务等。而且你想知道 akka 是否是一个合适的框架，这是一个离题的问题，因为它是一个意见问题。如果它适合您的应用程序，请使用它。此外，服务总线在 Windows Server 中工作。你应该用那个吗？同样，取决于您，特定于应用程序。
我使用在 Windows 上运行并在 Azure 上托管的 AKKA.NET。持久性方面是我正在努力解决的问题。
啊 - 那将是一个不同类型的问题。 :) 鉴于 akka 具有文件系统持久性，并且 Azure 具有基于 SSD 和非 SSD 的持久附加磁盘存储，因此可以轻松回答。

标签： azure akka azureservicebus akka.net

【解决方案1】：

我会说 Akka.net 的邮箱组件所做的工作类似于 Azure 服务总线队列（或实际上是 MSMQ）在原则上可能类似的工作。服务总线队列（或 MSMQ）将持久保存（或者在 MSMQ 的情况下，持久队列 - 不是内存队列）存储的消息和 Akka 开箱即用的邮箱不会。

但这就是相似之处的结束......服务总线没有演员、处理器、分发的概念 - 它只是一个消息传递解决方案。

如果您希望实现可能以持久性（和事务性“演员”）为目标的演员，那么我建议您不要使用 Akka.net，而是使用 MassTransit 或 nServiceBus。两者都是非常有能力的产品，虽然它们的性能不及 Akka.net（MT 和 nSB 序列化并持久化到磁盘，Akka.net 没有），但它们非常有能力和坚固，并且当一个 Actor/Node 崩溃时可以透明地恢复整个工作项将在一个事务中，这将导致消息被重新插入/重新处理为默认行为。

长期以来，我一直将 Azure 表存储视为一个很好的事件存储，但如果您希望保留命令记录，我会使用服务总线（MassTransit、nServiceBus），因为对我来说，这感觉就像您有以下需求本质上更像是“事务性”的“近实时”和“多处理器”。

个人意见

【讨论】：

我们在 RabbitMQ 之上使用 MassTransit 来实现类似的目的，这非常棒。非常高性能和高度可扩展。