AKKA是否尝试在内存中执行与Azure Service Bus Queue在磁盘上相同的操作?

won*_*rld 5 azure akka azureservicebus akka.net

像AKKA.net这样的演员模型带来很多好处,如可伸缩性,反应性,内存缓存等...当我尝试将AKKA与Azure服务总线队列进行比较时,我看到了几乎相同的主要好处Azure服务总线,但内存缓存的好处除外.

在生产环境中,AKKA需要具有更多内存的多个VM,处理能力以处理内存中的数百万个actor.对于Azure Service Bus Queues,不需要强大的主机.即使我们使用演员模型,也不需要进行监督或创建演员系统来管理数百万演员.Azure Service Bus可自动实现可伸缩性.

从长远来看,我认为Azure Service Bus Queues具有成本效益.随着负载的增加,无需IT管理员进行管理.对于多核,也不需要功能强大的系统.

AKKA演员模型是否适用于具有多核系统的本地数据中心,并且在考虑成本效益时不适合可以使用Azure服务的应用程序?

Kar*_*rie 6

我会说,Akka.net的邮箱组件的工作类似于Azure Service Bus Queues(或MSMQ的那个事实)原则上可能类似的工作.如果服务总线队列(或MSMQ)将持续存在(或者在MSMQ的情况下,持久队列 - 而不是内存队列),存储和Akka的邮箱开箱即用的消息将不会.

但这就是相似之处的结束...... Service Bus没有Actors,处理器,发行版的概念 - 它只是一个消息传递解决方案.

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

我很早就把Azure Table Storage视为一个很好的事件存储,但我会使用服务总线(MassTransit,nServiceBus),如果你想保留一个命令记录,就像你有更多的需求"事务性" "作为"近实时"和"多处理器"的性质.

我的个人意见,

  • 我们在RabbitMQ之上使用MassTransit用于类似目的,它非常棒.性能非常高,可扩展性高. (2认同)