Redis为何这么快？

     接触Redis使用快一年多了，目前除了集群部署（非主从）尚未实际操做之外，对Redis的搭建，常规操做，基本原理，持久化方式等都比较熟悉；

     可是目前为止对于Redis为何快，都只知道由于是内存操做，因此快，通过查阅资料，具体有如下缘由，这里也针对几点详细探究下，以学习记录；

1. 纯内存访问，内存响应大约100纳秒，这也就是Redis快的基础
2. 非阻塞IO，Redis采用epoll做为多路复用技术的实现；
3. 单线程避免多线程切换，竞态而产生的消耗

 

     为何使用单线程？

     经过官方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的通俗理解。。。

           因对网络这一块不是很熟悉，因此借鉴别人的理解写出，快递例子就是出于下面的博客；

           http://www.javashuo.com/article/p-bfjmamzc-mt.html

           https://www.cnblogs.com/ajianbeyourself/p/5859989.html