一、Redis为什么采用单执行绪
Redis的瓶颈最有可能是机器内存或者网络带宽，既然单执行绪容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单执行绪的方案了。关于redis的效能，官方网站也有，普通笔记本轻松处理每秒几十万的请求
二、Redis为什么这么快
1、完全基于内存，绝大部分请求是纯粹的内存操作，非常快速。资料存在内存中，类似于HashMap，HashMap的优势就是查询和操作的时间复杂度都是O(1)；
2、资料结构简单，对资料操作也简单，Redis中的资料结构是专门进行设计的；
3、采用单执行绪，避免了不必要的上下文切换和竞争条件，也不存在多程序或者多执行绪导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的效能消耗；
4、使用多路I/O复用模型，非阻塞IO；
5、使用底层模型不同，它们之间底层实现方式以及与客户端之间通讯的应用协议不一样，Redis直接自己构建了VM 机制 ，因为一般的系统呼叫系统函式的话，会浪费一定的时间去移动和请求；
三、多路I/O复用模型，非阻塞IO
下面举一个例子，模拟一个tcp服务器处理30个客户socket。
假设你是一个监考老师，让30个学生解答一道竞赛考题，然后负责验收学生答卷，你有下面几个选择：
1. 第一种选择：按顺序逐个验收，先验收A，然后是B，之后是C、D。。。这中间如果有一个学生卡住，全班都会被耽误。
这种模式就好比，你用循环挨个处理socket，根本不具有并发能力。
2. 第二种选择：你建立30个分身，每个分身检查一个学生的答案是否正确。 这种类似于为每一个使用者建立一个程序或者执行绪处理连线。
3. 第三种选择，你站在讲台上等，谁解答完谁举手。这时C、D举手，表示他们解答问题完毕，你下去依次检查C、D的答案，然后继续回到讲台上等。此时E、A又举手，然后去处理E和A。。。
这种就是IO复用模型，Linux下的select、poll和epoll就是干这个的。将使用者socket对应的fd注册进epoll，然后epoll帮你监听哪些socket上有讯息到达，这样就避免了大量的无用操作。此时的socket应该采用非阻塞模式。
这样，整个过程只在呼叫select、poll、epoll这些呼叫的时候才会阻塞，收发客户讯息是不会阻塞的，整个程序或者执行绪就被充分利用起来，这就是事件驱动，所谓的reactor模式。
针对上面的举例在Redis中表现为
有30个redis客户端（考生）与redis服务器的网络连线模组（监考老师）保持TCP连线，客户端会不定时的传送请求给服务器，当有一个redis客户端发起请求，会触发unix系统像epoll这样的系统呼叫，Redis的I/O 多路复用模组封装了底层的epoll这样的 I/O 多路复用函式，然后转发到相应的事件处理器。
最后多路I/O复用模型图
档案事件处理器使用 I/O 多路复用模组同时监听多个 FD（档案描述符），当 accept、read、write 和 close 档案事件产生时，档案事件处理器就会回拨 FD 系结的事件处理器。
虽然整个档案事件处理器是在单执行绪上执行的，但是通过 I/O 多路复用模组的引入，实现了同时对多个 FD 读写的监控，提高了网络通讯模型的效能，同时也可以保证整个 Redis 服务实现的简单。
关于redis的话题今天就探讨到这里，更多分享尽请关注。
