redis 内部使用文件事件解决器 file event handler，这个文件事件解决器是单线程的，所以 redis 才叫做单线程的模型。
它采用 IO 多路复用机制同时监听多个 socket，根据 socket 上的事件来选择对应的事件解决器进行解决。
文件事件解决器的结构包含 4 个部分：
- 多个 socket
- IO 多路复用程序
- 文件事件分派器
- 事件解决器（包括：连接应答解决器、命令请求解决器、命令回复解决器）
多个 socket 可能会并发产生不同的操作，每个操作对应不同的文件事件，但是 IO 多路复用 程序会监听多个 socket，会将 socket 产生的事件放入队列中排队，事件分派器每次从队列中取出一个事件，把该事件交给对应的事件解决器进行解决。
来看用户端与 redis 的一次通信过程：
redis-single-thread-model
用户端 socket01 向 redis 的 server socket 请求建立连接，此时 server socket 会产生一个 AE_READABLE 事件，IO 多路复用程序监听到 server socket 产生的事件后，将该事件压入队列中。文件事件分派器从队列中获取该事件，交给连接应答解决器。连接应答解决器会创立一个能与用户端通信的 socket01，并将该 socket01 的 AE_READABLE 事件与命令请求解决器关联。
假设此时用户端发送了一个 set key value 请求，此时 redis 中的 socket01 会产生 AE_READABLE 事件，IO 多路复用程序将事件压入队列，此时事件分派器从队列中获取到该事件，因为前面 socket01 的 AE_READABLE 事件已经与命令请求解决器关联，因而事件分派器将事件交给命令请求解决器来解决。命令请求解决器读取 socket01 的 key value 并在自己内存中完成 key value 的设置。操作完成后，它会将 socket01 的 AE_WRITABLE 事件与命令回复解决器关联。
假如此时用户端准备好接收返回结果了，那么 redis 中的 socket01 会产生一个 AE_WRITABLE 事件，同样压入队列中，事件分派器找到相关联的命令回复解决器，由命令回复解决器对 socket01 输入本次操作的一个结果，比方 ok，之后解除 socket01 的 AE_WRITABLE 事件与命令回复解决器的关联。
这样便完成了一次通信。
为啥 redis 单线程模型也能效率这么高？
- 纯内存操作
- 核心是基于非阻塞的 IO 多路复用机制
- 单线程反而避免了多线程的频繁上下文切换问题
