Redis 单线程为什么还能这么快?
因为它所有的数据都在内存中，所有的运算都是内存级别的运算。
正因为 Redis 是单线程，所以要小心使用 Redis 指令，对于那些时间复杂度为 O(n) 级别的指 令，
一定要谨慎使用，一不小心就可能会导致 Redis 卡顿。
Redis 单线程如何处理那么多的并发客户端连接?
多路复用
非阻塞 IO
套接字读写流程:
事件轮询 (多路复用)
非阻塞 IO 有个问题，那就是线程要读数据，结果读了一部分就返回了，线程如 何知道何时才应该继续读。
也就是当数据到来时，线程如何得到通知。
写也是一 样，如果缓冲区满了，写不完，剩下的数据何时才应该继续写，线程也应该得到 通知。
事件轮询 API 就是用来解决这个问题的，最简单的事件轮询 API 是 select 函 数，它是操作系统提供给用户程序的 API。
输入是读写描述符列表 read_fds & write_fds ，输出是与之对应的可读可写事件。
同时还提供了一个 timeout 参 数，如果没有任何事件到来，那么就最多等待 timeout 时间，线程处于阻塞状 态。
一旦期间有任何事件到来，就可以立即返回。
时间过了之后还是没有任何事 件到来，也会立即返回。
拿到事件后，线程就可以继续挨个处理相应的事件。
处理完了继续过来轮询。
于是线程就进入了一个死循环，我们把这个死循环称为事件循环，一个循环为一个周期。
每个客户端套接字 socket 都有对应的读写文件描述符。
read_events, write_events = select(read_fds, write_fds, timeout)
for event in read_events:
handle_read(event.fd)
for event in write_events:
handle_write(event.fd)
handle_others() # 处理其它事情，如定时任务等
因为我们通过 select 系统调用同时处理多个通道描述符的读写事件，因此我们 将这类系统调用称为多路复用 API。现代操作系统的多路复用 API 已经不再使用select 系统调用，而改用 epoll(linux) 和 kqueue(freebsd & macosx) ，因为 select 系统调用的性能在描述符特别多时性能会非常差。它们使用起来可能在形式上略有差异，但是本质上都是差不多的，都可以使用上面的伪代码逻辑进行理解。
服务器套接字 serversocket 对象的读操作是指调用 accept 接受客户端新连接。
何时有新连接到来，也是通过 select 系统调用的读事件来得到通知的。
事件轮询 API 就是 Java 语言里面的 NIO 技术
Java 的 NIO 并不是 Java 特有的技术，其它计算机语言都有这个技术，只不过 换了一个词汇，不叫 NIO 而已。
指令队列
Redis 会将每个客户端套接字都关联一个指令队列。客户端的指令通过队列来排 队进行顺序处理，先到先服务
响应队列
Redis 同样也会为每个客户端套接字关联一个响应队列。
Redis 服务器通过响应 队列来将指令的返回结果回复给客户端。
如果队列为空，那么意味着连接暂时 处于空闲状态，不需要去获取写事件，
也就是可以将当前的客户端描述符从write_fds 里面移出来。
等到队列有数据了，再将描述符放进去。
避免 select 系统调用立即返回写事件，结果发现没什么数据可以写。
出这种情况的线程会飙 高 CPU。
定时任务
服务器处理要响应 IO 事件外，还要处理其它事情。比如定时任务就是非常重要 的一件事。
如果线程阻塞在 select 系统调用上，定时任务将无法得到准时调 度。那 Redis 是如何解决这个问题的呢?
Redis 的定时任务会记录在一个称为 最小堆 的数据结构中。
这个堆中，最快要执 行的任务排在堆的最上方。在每个循环周期，Redis 都会将最小堆里面已经到点 的任务立即进行处理。
处理完毕后，将最快要执行的任务还需要的时间记录下 来，这个时间就是 select 系统调用的 timeout 参数。
因为 Redis 知道未来timeout 时间内，没有其它定时任务需要处理，所以可以安心睡眠 timeout 的时 间。
Nginx 和 Node 的事件处理原理和 Redis 也是一样的