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