nginx_redis 高并发

Apache与Nginx：
Apache与Nginx的性能谁更高效，取决于其服务器的并发策略以及其面对的场景：

并发策略：

我们目前使用的 Apache是基于一个线程处理一个请求的非阻塞IO并发策略 。这种方式允许一个进程中通过多个线程来处理多个连接，其中每个线程处理一个连接。Apache使用其worker模块实现这种方式，目的是减少perfork模式中太多进程的开销，使得apache可以支持更多的并发连接。

至于，非阻塞IO的实现，是通过一个子进程负责accept()，一旦接收到连接后，便将任务分配给适当worker的线程。

由于apache的线程使用的是内核进程调度器管理的轻量级进程，因此与perfork模式比较，进程上下文切换的开销依然存在，性能提升不是很明显。

而 Nginx使用的是一个进程处理多个连接、非阻塞IO模式 ，这种模式最特别的是设计了独立的listener进程，专门负责接收新的连接，再分配给各个worker，当然为了减少任务调度的开销，一般都是由worker进程来进行接收。

而IO模型层面，Nginx选择epoll，此方式高效主要在于其基于事件的就绪通知机制，在高连接数的场景下，epoll通知方式更具优势。另外，epoll方式只关注活跃连接，而不像select方式需要扫描所有的文件描述符，这样在大量连接的场景下，epoll方式优势会更加明显。

Redis快的主要原因是：
完全基于内存
数据结构简单，对数据操作也简单
使用多路 I/O 复用模型

和Memcached不同，Redis并没有直接使用Libevent，而是自己完成了一个非常轻量级的对select、epoll、evport、kqueue这些通用的接口的实现。在不同的系统调用选用适合的接口，linux下默认是epoll。因为Libevent比较重更通用代码量也就很庞大，拥有很多Redis用不上的功能，Redis为了追求“轻巧”并且去除依赖，就选择自己去封装了一套。

单进程单线程好处
代码更清晰，处理逻辑更简单
不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗
不存在多进程或者多线程导致的切换而消耗CPU
单进程单线程弊端
无法发挥多核CPU性能，不过可以通过在单机开多个Redis实例来完善；
其他一些优秀的开源软件采用的模型
多进程单线程模型：Nginx
单进程多线程模型：Memcached