云风的 BLOG

先来看一个最直接的服务器实现的伪代码：

while true do
  local req = get_request(fd)
  local resp = handle_request(req)
  put_response(fd, resp)
end

即用一个死循环，依次获取网络请求，针对请求生成回应数据，然后将回应数据经网络发回。

看似符合协议，但若你这么实现，则很有可能不能正常工作。

假设 get_request 是阻塞读网络，put_response 是阻塞写网络，那么就要求客户端也是严格的配合：客户端也必须提起一个请求后，等待回应，然后再提下一个请求。否则，若客户端连续提两个请求，服务器在处理第一个请求后，推送的回应客户端不去接收（因为客户端还在提第二个请求），就可能会死锁。

死锁发生时，客户端在推送第二个请求（写操作），而服务器在推送第一个回应（写操作）；两边都没在收取对方的数据，两侧的 api 都等待在写网络上（因为对端不读）。

但现代服务器框架一般会将网络读写分离到独立线程中，死锁不会发生。服务器收到新请求就能处理，产生出回应数据。而回应数据将缓存在网络线程中，等待客户端接收，而不会阻塞住上面的业务循环。那里的 put_response 是非阻塞的。

但这却非常容易产生 OOM （内存溢出）的问题。因为请求和回应是不对等的，客户端可以轻易的发起大量的 GET 请求，一条几十字节的 GET 请求，很可能需要几十上白兆的回应包。巨量的回应包积压在网络线程的发送队列中，很快就会吃光所有的内存。

所以，put_response 这个函数必须在内存耗光前阻塞住，前面的问题就会回来。所以，合理的服务器设计必须分离 get_request 和 put_response 到两个执行序列里。

我看过早期的 unity 官方 cacheserver 的实现，只有一个简单的 js 文件，跑在 nodejs 服务中。nodejs 是基于回调机制的，请求处理放在了 socket 的 data 事件回调中，每个请求都会生成一个新的对象，这个对象会进入一个队列，由 socket 的可写事件触发出队列操作，将文件 pipe 到 socket 上。

因为回应操作是由文件的 pipe 到 socket 依次完成的，这个过程可能很慢（取决于对端的接收进度），那么新请求非常可能积压在队列中。假设客户端一直推送请求，而疏于处理回应的话，这个队列将一直增长，直到 OOM 发生。

现在的 cacheserver 版本已经变得非常复杂，不太容易看清楚。我简单浏览了一下，觉得依旧存在这个隐患：在 server/command_processor.js 文件中，_onGet 函数会把要回应的 item 压入队列（this[kSendFileQueue].push(item);) 这个队列可能无限增长。

我们现在的实现也是类似的机制，伪代码如下：

-- request thread
while true do
  local req = get_request(fd)
  push_queue(q, req)
end

-- response thread
while true do
  local req = pop_queue(q)
  local resp = handle_request(req)
  put_response(fd, resp)
end

这里的 push_queue 在达到队列预设的容量后，是会阻塞等待另一个线程的 pop_queue 取走再继续工作的。

我们在做此修改后，把 queue 的容量设置为 8192 ，实际运行时，客户反馈以前正常的打包过程（其实会让服务器濒临 OOM 崩溃），现在有时会卡在和 cache server 的通讯上。经过线上观察（使用 skynet 预留的 debug console 的 debug 功能进入服务查看内部状态），发现这个 queue 很容易就满了，等待 pop_queue ；而能执行 pop_queue 的线程却阻塞在 put_response 上，也就是 unity 客户端拒绝接收前面那 8000 个请求产生的回应。

针对这种情况的合理推测是， unity 在某些极端情况下，一口气发了上万（甚至十万个）请求，它在这些请求全部从网络发出之前，没有跑网络接收的业务，导致数据全部堵在网络层；而服务器为了避免自己内存耗尽，只能暂停接收新的请求，结果就卡了。

换句话说，针对客户端不合理的使用：不断地发送请求，拒绝处理回应，那么服务器若想一直服务下去，只能在内存耗尽和卡住间二选一。当然还有拒绝服务的第三条路，即在异常情况（卡住）后，踢掉客户端。客户端发现断线，就会重连服务器再来一次。

我们最终的对策是，优化队列，让队列中保存的数据足够的少（这里可以只讲客户端请求 id 保留在队列中，每个请求所需内存在 100 字节以下）然后增加队列的容量上限到百万级；当队列满时踢掉客户端。

最近两天似乎工作平稳了。