memcached多线程模型 & nginx 多进程模型

memcached和nginx的并发模型，一个是单进程多线程典范，一个是多进程单线程经典。通过对比来将加深一下对这两种并发模型的理解。

首先分析一下两者的应用场景。

共同点：

两个应用，一个是缓存服务，一个是web服务，都是连接暴多请求频繁，而且对响应时间比较敏感的的应用，在这一点上两者需求一样：大量请求，快速响应。服务端程序基本都这需求，逃也逃不掉。

不同点：

其实是废话，不同点就是一个是cache，一个是web，仔细想想两者的区别还是有点的，就是：不同的请求响应时间相差比较大。什么意思，就是说对于memcached来讲，绝大多数请求服务端处理所花的时间基本是相同的。而nginx就不一样了，一个客户端的请求有的立刻就可以响应，有的则牵涉到php解析，读文件啊什么的，有响应的几个字节，有的则几百K，相差巨大。

共同点：

因为都需要处理高并发的网络IO，所以都采用了异步模式。memcached使用libevent（memcached作者曾把libevent换成libev测了一下，结果性能只提升一点点，考虑到换库的成本，作罢了），而nginx则是自己封装了epoll（linux下）。其实效果是一样的，因为libevent在linux下也是封装了epoll。异步！异步是王道啊！

memcached下的线程关系跟nginx下的进程关系基本是一样的，都是Master-Worker模式。

不同点：

两者最主要的不同点在于连接的监听和分发上，memcached是主线程负责监听和分发，而nginx则是所有的进程都监听，不需要分发。我认为这两种模式恰恰对应了两者应用上的不同点。

对于memcached来说，绝大多数请求要处理的时间相当，所以主线程监听，然后平均分配连接，这样各个线程的负载基本差不多，而且监听连接的效率也高。这样memcached使用多线程而不用多进程也可以减少IPC的成本。而nginx则不一样，请求所需计算时间不定，如果还是简单的RR将连接平均分到各个worker上，可能会造成负载不平均，有的进程比较cpu闲，有的忙死。所以nginx让各个进程争锁来监听，再加上基本的负载处理，这样虽然增加了争锁的成本，但是能基本保证比较闲的进程更有机会接受新连接。nginx的连接处理有点抢占的味道。

其实linux下线程仅仅是默认共享内存的进程而已，仅仅！所以，memcached的线程和nginx的进程在调度上没什么区别。