具有响应时间限制的异步请求响应算法
我正在为 ebXML 消息传递应用程序编写消息处理程序。该消息遵循请求-响应模式。该过程很简单：发送者发送消息，接收者接收消息并发回响应。到目前为止，一切都很好。
接收方收到消息后，会设置对该消息的响应时间 (TTR)。这可能是从几秒到几小时/天的任何时间。
我的问题是：发送方应该如何处理TTR？我需要这是一个异步过程，因为 TTR 可能会很长（几天）。我怎样才能以某种方式倒计时计时器，但又不会长时间占用系统资源。可能有大量消息。
我最初的想法是有一个“等待”集合，其中添加消息 Id 及其 TTR 到期时间。然后我会定期对集合进行调查。当计时器到期时，消息 ID 将被移至“到期”集合，并且消息事务将被终止。
当发送方收到响应时，它可以检查“等待”集合中是否有与其匹配的已发送消息，并确认是否及时收到了响应。然后，该消息将从集合中删除，以进行下一阶段的处理。
这听起来像是一个强大的解决方案吗？我确信这是一个已解决的问题，但有关此类算法的信息很少。我计划用 C# 实现它，但我认为现阶段实现语言有点无关紧要。
感谢您的意见
I am writing a Message Handler for an ebXML message passing application. The message follow the Request-Response Pattern. The process is straightforward: The Sender sends a message, the Receiver receives the message and sends back a response. So far so good.
On receipt of a message, the Receiver has a set Time To Respond (TTR) to the message. This could be anywhere from seconds to hours/days.
My question is this: How should the Sender deal with the TTR? I need this to be an async process, as the TTR could be quite long (several days). How can I somehow count down the timer, but not tie up system resources for large periods of time. There could be large volumes of messages.
My initial idea is to have a "Waiting" Collection, to which the message Id is added, along with its TTR expiry time. I would then poll the collection on a regular basis. When the timer expires, the message Id would be moved to an "Expired" Collection and the message transaction would be terminated.
When the Sender receives a response, it can check the "Waiting" collection for its matching sent message, and confirm the response was received in time. The message would then be removed from the collection for the next stage of processing.
Does this sound like a robust solution. I am sure this is a solved problem, but there is precious little information about this type of algorithm. I plan to implement it in C#, but the implementation language is kind of irrelevant at this stage I think.
Thanks for your input
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
根据客户端的数量，您可以使用持久 JMS 队列。每个客户端 ID 一个队列。该消息将保留在队列中，直到客户端连接到它来检索它。
我不明白 TTR 的目的。这是否更像是一种客户端措施，意味着如果无法在一定时间内返回响应，那么就不必发送它？或者是在服务器上使用它来安排工作并执行现在所需的操作并推送稍后响应时间的请求以稍后完成？
这是一个广泛的问题...
Depending on number of clients you can use persistent JMS queues. One queue per client ID. The message will stay in the queue until a client connects to it to retrieve it.
I'm not understanding the purpose of the TTR. Is it more of a client side measure to mean that if the response cannot be returned within certain time then just don't bother sending it? Or is it to be used on the server to schedule the work and do what's required now and push the requests with later response time to be done later?
It's a broad question...