注意:redis 单线程指的是网络请求模块使用了一个线程,即一个线程处理全部网络请求,其余模块仍用了多个线程。react
由于CPU不是Redis的瓶颈。Redis的瓶颈最有多是机器内存或者网络带宽,既然单线程容易实现,并且CPU不会成为瓶颈,那就瓜熟蒂落地采用单线程的方案了。关于redis的性能,官方网站也有,普通笔记本轻松处理每秒几十万的请求redis
一、彻底基于内存,绝大部分请求是纯粹的内存操做,很是快速。数据存在内存中,相似于HashMap,HashMap的优点就是查找和操做的时间复杂度都是O(1);服务器
二、数据结构简单,对数据操做也简单,Redis中的数据结构是专门进行设计的;网络
三、采用单线程,避免了没必要要的上下文切换和竞争条件,也不存在多进程或者多线程致使的切换而消耗 CPU,不用去考虑各类锁的问题,不存在加锁释放锁操做,没有由于可能出现死锁而致使的性能消耗;数据结构
四、使用多路I/O复用模型,非阻塞IO;多线程
五、使用底层模型不一样,它们之间底层实现方式以及与客户端之间通讯的应用协议不同,Redis直接本身构建了VM 机制 ,由于通常的系统调用系统函数的话,会浪费必定的时间去移动和请求;并发
3、多路IO复用模型,非阻塞IOsocket
下面举一个例子,模拟一个tcp服务器处理30个客户socket。
假设你是一个监考老师,让30个学生解答一道竞赛考题,而后负责验收学生答卷,你有下面几个选择:tcp
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 多路复用函数,而后转发到相应的事件处理器。