在对系统问题进行排查时，我发现了一个奇怪的现象：明明是对方断开请求，系统却报告一个查询失败的错误，但从用户角度来看请求的结果正常返回，没有任何问题。 对这个现象深入分析后发现，这是一个基于 epoll 的连接池实现上的问题，或者说是特性 :) 首先解释一下导致这个现象的原因。

    每个cs程序尤其是高并发的网络服务端程序都有自己的网络异步事件处理库，redis不例外。 事件库仅仅包括ae.c、ae.h，还有3个不同的多路复用（本文仅描述epoll）的wrapper文件，事件库封装了框架调用的主循环函数，暴露了时间、文件事件注册和销毁函数，典型的依赖反转模式。 网络操作都在networking.c里，封装了常见的socket操作。 我们从redis启动的main函数开始，从用户发出连接键入命令开始遍历网络事件库所涉及的函数，unix套接...

    最近遇到的一个问题，其实Linux 下的Too open many files 问题很普遍，我这里的情况还有些不一样，具体情况是，在项目中使用memcached作为缓存，同时使用xmemcached作为客户端包，程序中由于大量从网络机器中获取缓存数据，打开大量的IO，项目使用了5台机器负载均衡，唯独有一台机器报出以下异常，其他机器正常。

    Linux平台上，Nginx使用epoll完成事件驱动，实现高并发；本文将不对epoll本身进行介绍（网上一堆一堆的文章介绍epoll的原理及使用方法，甚至源码分析等），仅看一下Nginx是如何使用epoll的。 Nginx在epoll模块中定义了好几个函数，这些函数基本都是作为回调注册到事件抽象层的对应接口上，从而实现了事件驱动的具体化，我们看如下的一段代码：