接觸Redis使用快一年多了，目前除了集群部署（非主從）還沒有實際操作以外，對Redis的搭建，常規(guī)操作，基本原理，持久化方式等都已經(jīng)很熟練了。
但是目前為止對于Redis為什么快，都只知道因為是內(nèi)存操作，所以快，經(jīng)過查閱資料，具體有以下原因，這里也針對幾點詳細探究下，以學(xué)習(xí)記錄；
- 純內(nèi)存訪問，內(nèi)存響應(yīng)大約100納秒，這也就是Redis快的基礎(chǔ)
- 非阻塞IO，Redis采用epoll作為多路復(fù)用技術(shù)的實現(xiàn)；
- 單線程避免多線程切換，競態(tài)而產(chǎn)生的消耗
-
為什么使用單線程
通過官方FAQ了解到CPU并不是Redis的瓶頸，最有瓶頸的可能是內(nèi)存的大小或者網(wǎng)絡(luò)；例如一般linux系統(tǒng)下每秒可以發(fā)送一百萬個請求，所以如果應(yīng)用程序主要使用O（N）或O（log（N））命令，很難使用到太多的CPU；不過也提到在4.0版本中，將會加入多線程，目前僅限于后臺刪除對象，及阻止通過Redis實施的命令；這里也說明了Redis快的基礎(chǔ)；并不是不用，而是因為太快了，沒必要用。。就是這么傲嬌。。
image -
Redis單線程模型
Redis客戶端對服務(wù)端的每次調(diào)用，都需經(jīng)歷發(fā)送命令、執(zhí)行命令、返回命令三個過程，因為Redis是單線程來處理命令的，所以在執(zhí)行階段，每一條到達服務(wù)端的命令都不會執(zhí)行，而是先進入隊列，然后逐個執(zhí)行；但是多個客戶端發(fā)送的命令執(zhí)行順序是不確定的，但是確定不會有兩條命令被同時執(zhí)行，不會產(chǎn)生并發(fā)問題；
-
多路復(fù)用IO技術(shù)-epoll
多路復(fù)用目前有以下幾個技術(shù)：select，poll，epoll
-
select
select==>時間復(fù)雜度O(n)
它僅僅知道了，有I/O事件發(fā)生了，卻并不知道是哪那幾個流（可能有一個，多個，甚至全部），我們只能無差別輪詢所有流，找出能讀出數(shù)據(jù)，或者寫入數(shù)據(jù)的流，對他們進行操作。所以select具有O(n)的無差別輪詢復(fù)雜度，同時處理的流越多，無差別輪詢時間就越長。 -
poll
poll==>時間復(fù)雜度O(n)
poll本質(zhì)上和select沒有區(qū)別，它將用戶傳入的數(shù)組拷貝到內(nèi)核空間，然后查詢每個fd對應(yīng)的設(shè)備狀態(tài)， 但是它沒有最大連接數(shù)的限制，原因是它是基于鏈表來存儲的. -
epoll
poll可以理解為event poll，不同于忙輪詢和無差別輪詢，epoll會把哪個流發(fā)生了怎樣的I/O事件通知我們。所以我們說epoll實際上是事件驅(qū)動（每個事件關(guān)聯(lián)上fd）的，此時我們對這些流的操作都是有意義的。（復(fù)雜度降低到了O(1)）
可以使用快遞的例子來通俗的解釋一下
收快遞，你不知道什么時候快遞來，然后沒別的事干，就去睡覺等快遞主動打電話你了，這就是阻塞了；
還有一種就是你主動每分鐘給快遞員打電話問到了沒，這就是非阻塞忙輪詢；
忙輪詢下如果快遞員一直沒到，則會消耗話費啊，時間等資源；
select,poll感覺就是監(jiān)控，快遞沒來的時候，空閑的時候，就會讓你睡覺，當來了的時候會把你弄醒；但是有一個缺點，如果你有好多個快遞，那他不知道是哪個快遞，只會告訴你快遞來了，然后你又得挨個打電話輪詢一遍，這就是無差別輪詢，同樣會造成不必要的浪費
epoll則不會，他會告訴你是哪個快遞到了，這樣的話我們就可以直接打電話拿快遞了。。
-
最后
epoll并不是銀彈，還是要根據(jù)自身的業(yè)務(wù)去進行選型，如果連接數(shù)少且十分活躍的情況下，使用select會比epoll要好
參考地址：
