接触Redis使用快一年多了，目前除了集群部署（非主从）还没有实际操作以外，对Redis的搭建，常规操作，基本原理，持久化方式等都比较熟悉；
但是目前为止对于Redis为什么快，都只知道因为是内存操作，所以快，经过查阅资料，具体有以下原因，这里也针对几点详细探究下，以学习记录；
- 纯内存访问，内存响应大约100纳秒，这也就是Redis快的基础
- 非阻塞IO，Redis采用epoll作为多路复用技术的实现；
- 单线程避免多线程切换，竞态而产生的消耗
为什么使用单线程？
通过官方FAQ了解到CPU并不是Redis的瓶颈，最有瓶颈的可能是内存的大小或者网络；例如一般linux系统下每秒可以发送一百万个请求，所以如果应用程序主要使用O（N）或O（log（N））命令，很难使用到太多的CPU；不过也提到在4.0版本中，将会加入多线程，目前仅限于后台删除对象，及阻止通过Redis实施的命令；这里也说明了Redis快的基础；并不是不用，而是因为太快了，没必要用。。就是这么傲娇。。
Redis单线程模型：
Redis客户端对服务端的每次调用，都需经历发送命令、执行命令、返回命令三个过程，因为Redis是单线程来处理命令的，所以在执行阶段，每一条到达服务端的命令都不会执行，而是先进入队列，然后逐个执行；但是多个客户端发送的命令执行顺序是不确定的，但是确定不会有两条命令被同时执行，不会产生并发问题；
非阻塞IO技术-epoll：
查了一下有几个概念，阻塞、非阻塞忙轮询；
例如收快递，你不知道什么时候快递来，然后没别的事干，就去睡觉等快递主动打电话你了，这就是阻塞了；
还有一种就是你主动每分钟给快递员打电话问到了没，这就是非阻塞忙轮询；
忙轮询下如果快递员一直没到，则会消耗话费啊，时间等资源；
这时候可以引进一个代理了，了解到的有三种：select，poll，epoll（详细原理需要自行百度）;
select,poll感觉就是监控，快递没来的时候，空闲的时候，就会让你睡觉，当来了的时候会把你弄醒；但是有一个缺点，如果你有好多个快递，那他不知道是哪个快递，只会告诉你快递来了，然后你又得挨个打电话轮询一遍，同样会造成不必要的浪费
epoll则不会，他会告诉你是哪个快递到了，这样的话我们就可以直接打电话拿快递了。。
这就是目前个人对epoll的通俗理解。。。
因对网络这一块不是很熟悉，所以借鉴别人的理解写出，快递例子就是出于下面的博客；
https://blog.csdn.net/shenya1314/article/details/73691088
https://www.cnblogs.com/ajianbeyourself/p/5859989.html