使用阻塞调用模式需要:
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 减少到其值的一小部分(仅调度时间)。从某种意义上说,异步也是如此,但剃须更多,并为您处理更多的编程样板。