为什么在为非HTTP服务器读取套接字时需要Async IO

Question

我正在设计一个C++客户端应用程序，它侦听多个端口以获取短消息流。在阅读ACE，POCO，boost :: asio和所有Proactor之类的设计模式之后，我即将开始使用boost :: asio。

有一件事我注意到它是使用异步套接字IO的一个常量主题，但还没有阅读异步io解决的好问题描述。所有这些设计模式都基于HTTP Web服务器设计的假设吗？由于网络服务器是复杂的延迟敏感的并发套接字编程最常见的应用程序，我开始怀疑大部分这些模式/习语是否适合这一个应用程序。

我的应用程序将收听少数几个插座，以获取短而频繁的消息。一个单独的线程将需要组合所有消息进行处理。我正在研究设计模式的一件事是将连接管理与数据处理分开。我希望有连接在断开连接后尝试重新连接，并让处理线程继续，如同没有任何事情发生。这里推荐什么设计模式？

我没有看到async io在我的情况下如何提高性能。

Answer 1

你在正确的轨道上。特别是在异步和事件驱动的所有宣传中，询问“为什么”是明智的。除了Web以外，还有其他应用程序。考虑消息队列和金融交易，如高频交易。基本上任何时候，等待费用或失去为客户提供服务的机会都是异步的候选人。网络是一个很好的例子，因为网络比数据库要快得多。一如既往，问“这是否有意义”为您的应用程序。如果你没有从中受益，异步增加了很多复杂性。

如果消息之间的平均时间与处理每条消息所需的时间相差无几，尤其是在处理包含持久性的情况下，您的简短快速消息实际上可能会从异步获益。但是你不必急于进入异步。检查你的阻止代码，看看你是否真的有瓶颈。

我希望这会有所帮助。

Answer 2

使用阻塞调用模式将需要：

1. Listening on a socket vector of size N 
2. When a message arrives, you wake up with a start in time K, find and start processing the message, employing a time T (it does not matter if the processing is offloaded to another thread: in this case T becomes your offloading time) 
3. You finish examining the vector and GOTO 1 

所以，你可能会说，如果M邮件到达，并在K + M * T调度时间的另一个消息到达时，M + 1个消息会发现自己在等待K + M * T时间。这是否可以接受你的K（常数），M（交通功能）和T（资源和系统负荷的功能）的期望值？

异步处理，实际上并不存在。总是会有一个“同步”的IO回路，只有它会很好地集成在内核（甚至是硬件）中，它会比你自己的速度快10-100倍，因此可能会更好地扩展M的值很大。延迟的形式仍然是K1 + M * T1，但是这次K1和T1要低得多。或者，也许K1稍高一些，T1明显较低：对于大数值的M，架构“可以更好地扩展”。

如果M的值通常很低，那么异步性的优势就会比较小。在荒谬的情况下，当您在应用程序生命周期中只有一条消息时，同步或异步使得几乎没有区别。

考虑到另一个因素：如果消息的数量变得非常大，异步性有其优势;但是如果消息本身是独立的（由消息A引起的变化不影响消息B的处理），那么你可以保持同步并且水平地缩放，准备数量为Z的“消息集中器”，每个消息集中器接收分数M/Z的总流量。

如果处理过程需要对其他服务执行其他调用（缓存，持久性，信息检索，认证...），增加T因子，那么转向多线程甚至异步就会更好。使用多线程技术，您可以将T刮至其价值的一小部分（仅限调度时间）。从某种意义上来说，异步处理是一样的，但是更多的是剃须，并且为您处理更多的编程样板文件。