消息系统的应用集成场景？

Question

我有一个场景，其中有一个后端系统和一个前端系统，它们之间有一个基于 .NET 的中间件。 后端系统提供前端系统使用的 REST API。

通信总是以 POST 请求开始。这将在后端系统上创建一个会话。所有后续请求都包含 SessionId。 许多客户端进行交互，并且都在该系统上获得自己的会话。 后端系统可以并行处理不同的会话，例如通过 HTTP GET API 返回信息。

但是有一个限制：每个session，读写请求都只能由后端系统依次处理。 以下屏幕截图说明了这一点： 这个限制使前端变得复杂，因为它实际上想要向后端系统发送并行请求。为了保持前端 很简单，我想通过消息系统将 .net 中间件层和后端分离。

有众所周知的模式，如竞争消费者等。不幸的是，我还没有为我的场景找到合适的标准模式。 有谁知道创建它的合适方法？如果可能，RabbitMQ 或 ActiveMQ/Artemis 是可能的。

场景必须在前提下工作，不能依赖特定的云技术。此外，该解决方案不应降低整体系统性能。

根据我的理解，我需要为每个 SessionId（从后端）动态创建一个消息队列。该会话上的所有请求都需要存储在此特定队列中并按顺序处理。结果，后端将存在与会话一样多的队列。下图说明了两个会话 A 和 B 的请求和响应队列的基本思想：

有人知道如何解决这个问题吗？提前致谢！

很多问候

Answer 1

一个简单的解决方案是在发送更多消息之前等待响应。但这可能会降低性能。

另一种选择是将几条消息打包成一条更大的消息。这种消息聚合将保证顺序。它可以在客户端或服务器端完成。

“恰好按顺序一次”政策 (EOIO) 会带来性能损失。在每条消息中写入严格递增的轨道 ID 可能会有所帮助。这将允许服务器检测乱序消息。这取决于整体需求，服务器应该等待延迟消息多长时间。