接觸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