IOCP , kqueue , epoll ... 有多重要？

你的名字 2022-07-15 12:08 226阅读 0赞

设计 mmo 服务器，我听过许多老生常谈，说起处理大量连接时， select 是多么低效。我们应该换用 iocp (windows), kqueue(freebsd), 或是 epoll(linux) 。的确，处理大量的连接的读写，select 是够低效的。因为 kernel 每次都要对 select 传入的一组 socket 号做轮询，那次在上海，以陈榕的说法讲，这叫鬼子进村策略。一遍遍的询问“鬼子进村了吗？”，“鬼子进村了吗？”… 大量的 cpu 时间都耗了进去。（更过分的是在 windows 上，还有个万恶的 64 限制。）

使用 kqueue 这些，变成了派一些个人去站岗，鬼子来了就可以拿到通知，效率自然高了许多。不过最近我在反思，真的需要以这些为基础搭建服务器吗？

刚形成的一个思路是这样的：

我们把处理外部连接和处理游戏逻辑分摊到两个服务器上处理，为了后文容易表述，暂时不太严谨的把前者称为连接服务器，后者叫做逻辑服务器。

连接服务器做的事情可以非常简单，只是把多个连接上的数据汇集到一起。假设同时连接总数不超过 65536 个，我们只需要把每个连接上的数据包加上一个两字节的数据头就可以表识出来。这个连接服务器再通过单个连接和逻辑服务器通讯就够了。

那么连接服务器尽可以用最高效的方式处理数据，它的逻辑却很简单，代码量非常的小。而逻辑服务器只有一个外部连接，无论用什么方式处理都不会慢了。

进一步，我们可以把这个方法扩展开。假定我们逻辑以 10Hz 的频率处理逻辑。我们就让连接服务器以 10Hz 的脉冲把汇总的数据周期性的发送过去，先发一个长度信息再发数据包。即使一个脉冲没有外部数据，也严格保证至少发一个 0 的长度信息。额外的，连接服务器还需要控制每个脉冲的数据总流量，不至于一次发送数据超过逻辑服务器处理的能力。

那么，逻辑服务器甚至可以用阻塞方式调用 recv 收取这些数据，连 select 也省了。至于数据真的是否会被接收方阻塞，就由连接服务器的逻辑保证了。

说到阻塞接收，我跟一个同事讨论的时候，他严重担心这个的可靠性，不希望因为意外把逻辑服务器挂在一个 system call 上。他列举了许多可能发生的意外情况，不过我个人是不太担心的，原因不想在这里多解释。当然我这样设计，主要不是为了节省一个 select 的调用，而是希望方便调试。（当然，如果事实证明这样不可行，修改方案也很容易）

因为阻塞接收可以保证逻辑服务器的严格时序性，当我们把两个服务器中的通讯记录下来，以后可以用这些数据完全重现游戏逻辑的过程，无论怎么调试运行，都可以保证逻辑服务器的行为是可以完全重现的。即，每 0.1s 接受已知的数据包，然后处理它们。

这样做，逻辑服务器对网络层的代码量的需求也大大减少了，可以更专心的构建逻辑。

转自云风blog:[http://blog.codingnow.com/2006/04/iocp\_kqueue\_epoll.html][http_blog.codingnow.com_2006_04_iocp_kqueue_epoll.html]

Cloud Wu blog评论：  
1.我们现在的游戏古剑OL的后端架构跟云风大大说的一样，甚至逻辑服务器之间通信也要经过这个所谓的“连接服务器”（现在应该都叫gateway了），不过从客户端到服务端，各个组件之间通信都是事件驱动异步的（主程封装了iocp/epoll），其实我觉得后端组件之间绝逼是在一个高速网域内，其间的延时相对于复杂的异步逻辑的代价来讲真的可以忽略不计。  
而且现在很多都是分布式架构，单纯依赖单一节点的高性能没太大的意义，不如将节点的代码逻辑变得简单一点，专注于提供系统业务的分布能力和健壮性。

2.我公司也是样这架构的服务器，用libevent写的连接服务器，客户端和逻辑服务端的网络代码是同一套代码，都是用select实现的，现在发现select没必要了，直接阻塞也行的。反正是逻辑服务器单进程的。

[http_blog.codingnow.com_2006_04_iocp_kqueue_epoll.html]: http://blog.codingnow.com/2006/04/iocp_kqueue_epoll.html