英文:
ActiveMQ Artemis MQTT Protocol Handler Threading
问题
我正在将Artemis嵌入到我的Java应用程序中，作为MQTT代理，并注意到MQTTProtocolHandler在异步处理消息时使用Actor类，但这似乎像OrderedExecutor一样具有任务队列，只使用单个线程来处理此任务队列（我猜这是为了维护顺序的明显原因）。
我看到的一个大问题是，我们从多线程的Netty接收TCP消息转变为单线程的MQTT消息处理器；然后，MQTT代理的吞吐量受限于这个单线程能够处理的内容；例如，如果在消息处理期间执行了任何阻塞的IO操作（即在身份验证和/或授权期间），性能会受到严重限制。
能否有Artemis团队的成员来解释一下这个问题，因为我很难看出这如何能成为一个可以处理大量传入流量的MQTT代理。
消息的顺序只在给定客户端ID的范围内相关，因此我希望在客户端ID之间支持多线程处理传入的MQTT发布消息（即基于客户端ID进行消息分组）。
英文:
I'm using Artemis in embedded mode within my java application as an MQTT broker and have noticed that the MQTTProtocolHandler uses the Actor class to process the messages asynchronously but this (like OrderedExecutor) seems to have a task queue and only ever utilises a single thread to process this task queue (I guess this is for the obvious reason of maintaining order).
The big issue I see here is that we go from multithreaded Netty ingestion of TCP messages to a single threaded MQTT message processor; the MQTT broker throughput is then limited to whatever this single thread can handle; so for example if any blocking IO is performed during message processing (i.e. during authentication and/or authorisation) then the performance is severely limited.
Can someone from the Artemis team shed some light on this as I am struggling to see how this can ever be an MQTT broker that can handle serious amounts of incoming traffic.
Order of messages is only relevant within the scope of a given client ID so I would expect multithreaded support of incoming MQTT publish messages across client IDs (i.e. message grouping based on client ID).
答案1
得分: 1
我认为你可能忽略了的一点是，每个MQTT连接都会有自己的MQTTProtocolHandler实例，因此也会有自己的Actor。这意味着可以同时为多个MQTT连接提供服务。据我所知，MQTTProtocolHandler或Actor上没有真正的瓶颈。
就其价值而言，通过ARTEMIS-2985添加了Actor机制，实际上是为了通过释放Netty来服务更多的连接来_提高_性能。
大多数MQTT用例涉及许多小型设备（例如IoT），每个设备都有自己的连接。代理应该能够同时处理这些连接。一般而言，鉴于其非阻塞核心，代理在并发增加时可以很好地扩展。
英文:
I think the piece that you may be missing is that each MQTT connection gets its own instance of the MQTTProtocolHandler and therefore its own Actor. This means that multiple MQTT connections can be serviced concurrently. As far as I can tell there is no real bottleneck on the MQTTProtocolHandler or the Actor.
For what it's worth, the Actor mechanism was added via ARTEMIS-2985 to actually increase performance by freeing Netty to service more connections.
Most MQTT use-cases involve lots of small devices (e.g. IoT) each with their own connection. The broker should be able to handle such connections concurrently. Generally speaking the broker scales pretty well as concurrency increases given the non-blocking core.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论