异步IO网络服务器设计(二) 读操作

针对一个连接，是同时投递N个读操作好，还是只投递一个读操作，待其出列了，再进行下一个读操作好？

网上针对这个问题也是众说纷纭，甚至恶语相加口舌相对的都是大有人在。本人无意引发口水战，只在此说说自己的理解。

 

一，针对一个连接同时投递N个读操作。

采用这种方式，据说比一次投递一个读操作更高效。但我们要知道，线程的切换是无法确定的。也就是说，对端发出了A、B、C三段数据，在不同的IO线程中被多个读操作出列后（在完成队列出列时，数据仍然是有序的），由于线程切换的不确定性，最终在进行拼包时（针对同一个连接，拼包毫无疑问是串行的）可能逻辑顺序就变成了B、A、C，这样就乱序了。有人提出了解决方案，在投递读操作时进行编号，那么在出列后，我们可以根据投递时的编号，把出列后产生的乱序再纠正过来。假设：

按递增顺序分别投递3个读操作，编号为1、2、3。虽然仍然是按1、2、3的顺序分别被不同的IO线程出列，但由于线程切换的原因，在调用拼包函数时顺序被打乱变成了2、1、3，但我们仍然可以根据投递编号将其重新排序。这样就保证了接收到的数据有序。

 

二，针对一个连接，在同一时刻有且仅有一个读操作。

毫无疑问上面所说的数据乱序现象将不存在（线程再怎么切换，我也只有一个读操作被出列）。但有人说效率上低于第一种方法，因为针对同一个连接，读操作实际上是阻塞的。我个人是这么认为的：就算同时投递N个读操作，在拼包这一步，仍然是串行阻塞的（针对同一个连接）。而且考虑到乱序的情况，针对每一个连接还要做纠正数据包顺序，一般需要一个指针来维持投递顺序（通过链表什么的，把投递插入到链表中正确的位置），对该指针或者链表的操作，有锁竞争（可以用原子锁代替，或者放到拼包函数中处理，共用拼包函数的锁）。

本人两种方法都使用过。在boost.asio的例子中，包括libtorrent等等在内的很多知名开源代码，发现大多数（几乎是所有）场合，都是使用的方法二。至于效率，在上层业务逻辑一样的情况下，效率上几乎没有差异（有时方法一效率略高，有时方法二效率略高，测试数据有很大的偶然性）。