Question

我正在创建一个程序，我需要通过不同的物理连接（串行端口，UDP）与多个设备（大约10-20个设备）进行通信。这些设备仅回复我对它们所做的请求，并且每个设备仅在允许新请求之前处理一个请求。应用程序可能每秒都要求每个值更新一次。

截至目前，我有一个界面IRequestReplyDevice

public interface IRequestReplyDevice
{
    T SendMessage<T>(IMessage message) where T : IMessage;
}

其中SendMessage是阻止调用，返回从设备收到的响应。在此接口的每个实现中，例如。 SerialPortDevice : IRequestReplyDevice，我在SendMessage锁定，确保在收到对上一个回复的响应并返回给调用者之前不会发送新消息。

我想在此基础上构建一个Web API，这可能会导致多个客户想要同时从同一设备请求某些内容。

这种方法是否健全甚至是理智的？你会采用不同的方法吗？

Answer 1

基于以上所述，我最初的想法是删除阻塞调用，而是在可能的情况下将请求和响应链与队列分离。

流程类似于以下

请求 - ＆gt; RequestQueue - ＆gt; RequestHandler - ＆gt; ResponseQueue - ＆gt; ResponseHandler所

这个建议背后的理由是阻塞调用和多个用户的固有并发性会导致很多复杂的锁定，锁定会有固有的瓶颈，可能无法很好地扩展。

然而，这个解决方案的问题在于它将涉及大量的额外工作和移动部件。这导致了一个真正的问题，即 实际上 需要从系统中采取什么行为？设计一个需要高吞吐量（1mb / s？1gb / s？）和低延迟（低于100ms？3ms以下？）的系统，可以很快地处理并发性。

如果系统能够容忍简单的块/锁设计背后的延迟，吞吐量和扩展要求，那么就可以使用它。如果您已经在负载下测试了基于锁的架构的性能，并且它没有充分执行，或者您有合理的期望系统将在不久的将来发展到不能满足要求的程度，那么我肯定会建议看看使用队列。