1.redis是基於內存的，內存的讀寫速度非常快；
2.redis是單線程的，省去了很多上下文切換線程的時間；
3.redis使用多路復用技術，可以處理並發的連接；
簡單解釋下第二條：上下文切換就是cpu在多線程之間進行輪流執行（槍戰cpu資源），而redis單線程的，因此避免了繁瑣的多線程上下文切換。
重點解釋下多路復用：
多路-指的是多個socket連接，復用-指的是復用一個線程。
目前，多路復用主要有三種技術：select，poll，epoll。它們出現的順序是喲西按后的，越排后的技術改正了之前技術的缺點。epoll是最新的也是目前最好的多路復用技術。
舉個例子：一個酒吧服務員，前面有很多醉漢，epoll這種方式相當於一個醉漢吼了一聲要酒，服務員聽見之后就去給他倒酒，而在這些醉漢沒有要求的時候可以玩玩手機等。但是select和poll技術是這樣的場景：服務員輪流着問各個醉漢要不要倒酒，沒有空閑的時間。io多路復用的意思就是做個醉漢公用一個服務員。
-
select：
1.會修改傳入的參數，對於多個調用的函數來說非常不友好；
2.要是sock（io流出現了數據），select只能輪詢這去找數據，對於大量的sock來說開銷很大；
3.不是線程安全的，很恐怖；
4.只能監視1024個連接； -
poll：
1.還不是線程安全的...
2.去掉了1024個連接的限制；
3.不修改傳入的參數了； -
epoll：
1.線程安全了；
2.epoll不僅能告訴你sock有數據，還能告訴你哪個sock有數據，不用輪詢了；
3.however，只支持linux系統；
作者：superxcp
鏈接：https://www.jianshu.com/p/b08c1f3bb256
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
linux IO多路復用有epoll， poll, select，epoll性能比其他幾者要好。
名詞比較繞口，理解涵義就好。一個epoll場景：一個酒吧服務員（一個線程），前面趴了一群醉漢，突然一個吼一聲“倒酒”（事件），你小跑過去給他倒一杯，然后隨他去吧，突然又一個要倒酒，你又過去倒上，就這樣一個服務員服務好多人，有時沒人喝酒，服務員處於空閑狀態，可以干點別的玩玩手機。至於epoll與select，poll的區別在於后兩者的場景中醉漢不說話，你要挨個問要不要酒，沒時間玩手機了。io多路復用大概就是指這幾個醉漢共用一個服務員。
其實“I/O多路復用”這個坑爹翻譯可能是這個概念在中文里面如此難理解的原因。所謂的I/O多路復用在英文中其實叫 I/O multiplexing. 如果你搜索multiplexing啥意思，基本上都會出這個圖：
於是大部分人都直接聯想到"一根網線，多個sock復用" 這個概念，包括上面的幾個回答， 其實不管你用多進程還是I/O多路復用， 網線都只有一根好伐。多個Sock復用一根網線這個功能是在內核＋驅動層實現的。
重要的事情再說一遍： I/O multiplexing 這里面的 multiplexing 指的其實是在單個線程通過記錄跟蹤每一個Sock(I/O流)的狀態(對應空管塔里面的Fight progress strip槽)來同時管理多個I/O流. 發明它的原因，是盡量多的提高服務器的吞吐能力。
是不是聽起來好拗口，看個圖就懂了.
在同一個線程里面， 通過撥開關的方式，來同時傳輸多個I/O流， (學過EE的人現在可以站出來義正嚴辭說這個叫“時分復用”了）。
什么，你還沒有搞懂“一個請求到來了，nginx使用epoll接收請求的過程是怎樣的”， 多看看這個圖就了解了。提醒下，ngnix會有很多鏈接進來， epoll會把他們都監視起來，然后像撥開關一樣，誰有數據就撥向誰，然后調用相應的代碼處理。
-------------------------------------------------------------------------------------------------------------------------
了解這個基本的概念以后，其他的就很好解釋了。
select, poll, epoll 都是I/O多路復用的具體的實現，之所以有這三個鬼存在，其實是他們出現是有先后順序的。
I/O多路復用這個概念被提出來以后， select是第一個實現 (1983 左右在BSD里面實現的)。
一、select 被實現以后，很快就暴露出了很多問題。
- select 會修改傳入的參數數組，這個對於一個需要調用很多次的函數，是非常不友好的。
- select 如果任何一個sock(I/O stream)出現了數據，select 僅僅會返回，但是並不會告訴你是那個sock上有數據，於是你只能自己一個一個的找，10幾個sock可能還好，要是幾萬的sock每次都找一遍，這個無謂的開銷就頗有海天盛筵的豪氣了。
- select 只能監視1024個鏈接， 這個跟草榴沒啥關系哦，linux 定義在頭文件中的，參見FD_SETSIZE。
- select 不是線程安全的，如果你把一個sock加入到select, 然后突然另外一個線程發現，尼瑪，這個sock不用，要收回。對不起，這個select 不支持的，如果你喪心病狂的竟然關掉這個sock, select的標准行為是。。呃。。不可預測的， 這個可是寫在文檔中的哦.
“If a file descriptor being monitored by select() is closed in another thread, the result is unspecified”
霸不霸氣
二、於是14年以后(1997年）一幫人又實現了poll, poll 修復了select的很多問題，比如
- poll 去掉了1024個鏈接的限制，於是要多少鏈接呢， 主人你開心就好。
- poll 從設計上來說，不再修改傳入數組，不過這個要看你的平台了，所以行走江湖，還是小心為妙。
其實拖14年那么久也不是效率問題， 而是那個時代的硬件實在太弱，一台服務器處理1千多個鏈接簡直就是神一樣的存在了，select很長段時間已經滿足需求。
但是poll仍然不是線程安全的， 這就意味着，不管服務器有多強悍，你也只能在一個線程里面處理一組I/O流。你當然可以那多進程來配合了，不過然后你就有了多進程的各種問題。
於是5年以后, 在2002, 大神 Davide Libenzi 實現了epoll.
三、epoll 可以說是I/O 多路復用最新的一個實現，epoll 修復了poll 和select絕大部分問題, 比如：
- epoll 現在是線程安全的。
- epoll 現在不僅告訴你sock組里面數據，還會告訴你具體哪個sock有數據，你不用自己去找了。
可是epoll 有個致命的缺點，只有linux支持。比如BSD上面對應的實現是kqueue。
其實有些國內知名廠商把epoll從安卓里面裁掉這種腦殘的事情我會主動告訴你嘛。什么，你說沒人用安卓做服務器，尼瑪你是看不起p2p軟件了啦。
而ngnix 的設計原則里面， 它會使用目標平台上面最高效的I/O多路復用模型咯，所以才會有這個設置。一般情況下，如果可能的話，盡量都用epoll/kqueue吧。
詳細的在這里:
Connection processing methods
PS: 上面所有這些比較分析，都建立在大並發下面，如果你的並發數太少，用哪個，其實都沒有區別。 如果像是在歐朋數據中心里面的轉碼服務器那種動不動就是幾萬幾十萬的並發，不用epoll我可以直接去撞牆了。
==============================IO多路復用的實現=============================
三、IO多路復用(Reactor)
IO多路復用模型是建立在內核提供的多路分離函數select基礎之上的，使用select函數可以避免同步非阻塞IO模型中輪詢等待的問題。
圖3 多路分離函數select
如圖3所示，用戶首先將需要進行IO操作的socket添加到select中，然后阻塞等待select系統調用返回。當數據到達時，socket被激活，select函數返回。用戶線程正式發起read請求，讀取數據並繼續執行。
從流程上來看，使用select函數進行IO請求和同步阻塞模型沒有太大的區別，甚至還多了添加監視socket，以及調用select函數的額外操作，效率更差。但是，使用select以后最大的優勢是用戶可以在一個線程內同時處理多個socket的IO請求。用戶可以注冊多個socket，然后不斷地調用select讀取被激活的socket，即可達到在同一個線程內同時處理多個IO請求的目的。而在同步阻塞模型中，必須通過多線程的方式才能達到這個目的。
用戶線程使用select函數的偽代碼描述為：
{
select(socket);
while(1) {
sockets = select();
for(socket in sockets) {
if(can_read(socket)) {
read(socket, buffer);
process(buffer);
}
}
}
}
其中while循環前將socket添加到select監視中，然后在while內一直調用select獲取被激活的socket，一旦socket可讀，便調用read函數將socket中的數據讀取出來。
然而，使用select函數的優點並不僅限於此。雖然上述方式允許單線程內處理多個IO請求，但是每個IO請求的過程還是阻塞的（在select函數上阻塞），平均時間甚至比同步阻塞IO模型還要長。如果用戶線程只注冊自己感興趣的socket或者IO請求，然后去做自己的事情，等到數據到來時再進行處理，則可以提高CPU的利用率。
IO多路復用模型使用了Reactor設計模式實現了這一機制。
圖4 Reactor設計模式
如圖4所示，EventHandler抽象類表示IO事件處理器，它擁有IO文件句柄Handle（通過get_handle獲取），以及對Handle的操作handle_event（讀/寫等）。繼承於EventHandler的子類可以對事件處理器的行為進行定制。Reactor類用於管理EventHandler（注冊、刪除等），並使用handle_events實現事件循環，不斷調用同步事件多路分離器（一般是內核）的多路分離函數select，只要某個文件句柄被激活（可讀/寫等），select就返回（阻塞），handle_events就會調用與文件句柄關聯的事件處理器的handle_event進行相關操作。
圖5 IO多路復用
如圖5所示，通過Reactor的方式，可以將用戶線程輪詢IO操作狀態的工作統一交給handle_events事件循環進行處理。用戶線程注冊事件處理器之后可以繼續執行做其他的工作（異步），而Reactor線程負責調用內核的select函數檢查socket狀態。當有socket被激活時，則通知相應的用戶線程（或執行用戶線程的回調函數），執行handle_event進行數據讀取、處理的工作。由於select函數是阻塞的，因此多路IO復用模型也被稱為異步阻塞IO模型。注意，這里的所說的阻塞是指select函數執行時線程被阻塞，而不是指socket。一般在使用IO多路復用模型時，socket都是設置為NONBLOCK的，不過這並不會產生影響，因為用戶發起IO請求時，數據已經到達了，用戶線程一定不會被阻塞。
用戶線程使用IO多路復用模型的偽代碼描述為：
void UserEventHandler::handle_event() {
if(can_read(socket)) {
read(socket, buffer);
process(buffer);
}
}
{
Reactor.register(new UserEventHandler(socket));
}
用戶需要重寫EventHandler的handle_event函數進行讀取數據、處理數據的工作，用戶線程只需要將自己的EventHandler注冊到Reactor即可。Reactor中handle_events事件循環的偽代碼大致如下。
Reactor::handle_events() {
while(1) {
sockets = select();
for(socket in sockets) {
get_event_handler(socket).handle_event();
}
}
}
事件循環不斷地調用select獲取被激活的socket，然后根據獲取socket對應的EventHandler，執行器handle_event函數即可。
IO多路復用是最常使用的IO模型，但是其異步程度還不夠“徹底”，因為它使用了會阻塞線程的select系統調用。因此IO多路復用只能稱為異步阻塞IO，而非真正的異步IO。
四、異步IO(Proactor)
“真正”的異步IO需要操作系統更強的支持。在IO多路復用模型中，事件循環將文件句柄的狀態事件通知給用戶線程，由用戶線程自行讀取數據、處理數據。而在異步IO模型中，當用戶線程收到通知時，數據已經被內核讀取完畢，並放在了用戶線程指定的緩沖區內，內核在IO完成后通知用戶線程直接使用即可。
異步IO模型使用了Proactor設計模式實現了這一機制。
圖6 Proactor設計模式
如圖6，Proactor模式和Reactor模式在結構上比較相似，不過在用戶（Client）使用方式上差別較大。Reactor模式中，用戶線程通過向Reactor對象注冊感興趣的事件監聽，然后事件觸發時調用事件處理函數。而Proactor模式中，用戶線程將AsynchronousOperation（讀/寫等）、Proactor以及操作完成時的CompletionHandler注冊到AsynchronousOperationProcessor。AsynchronousOperationProcessor使用Facade模式提供了一組異步操作API（讀/寫等）供用戶使用，當用戶線程調用異步API后，便繼續執行自己的任務。AsynchronousOperationProcessor 會開啟獨立的內核線程執行異步操作，實現真正的異步。當異步IO操作完成時，AsynchronousOperationProcessor將用戶線程與AsynchronousOperation一起注冊的Proactor和CompletionHandler取出，然后將CompletionHandler與IO操作的結果數據一起轉發給Proactor，Proactor負責回調每一個異步操作的事件完成處理函數handle_event。雖然Proactor模式中每個異步操作都可以綁定一個Proactor對象，但是一般在操作系統中，Proactor被實現為Singleton模式，以便於集中化分發操作完成事件。
圖7 異步IO
如圖7所示，異步IO模型中，用戶線程直接使用內核提供的異步IO API發起read請求，且發起后立即返回，繼續執行用戶線程代碼。不過此時用戶線程已經將調用的AsynchronousOperation和CompletionHandler注冊到內核，然后操作系統開啟獨立的內核線程去處理IO操作。當read請求的數據到達時，由內核負責讀取socket中的數據，並寫入用戶指定的緩沖區中。最后內核將read的數據和用戶線程注冊的CompletionHandler分發給內部Proactor，Proactor將IO完成的信息通知給用戶線程（一般通過調用用戶線程注冊的完成事件處理函數），完成異步IO。
用戶線程使用異步IO模型的偽代碼描述為：
void UserCompletionHandler::handle_event(buffer) {
process(buffer);
}
{
aio_read(socket, new UserCompletionHandler);
}
用戶需要重寫CompletionHandler的handle_event函數進行處理數據的工作，參數buffer表示Proactor已經准備好的數據，用戶線程直接調用內核提供的異步IO API，並將重寫的CompletionHandler注冊即可。
相比於IO多路復用模型，異步IO並不十分常用，不少高性能並發服務程序使用IO多路復用模型+多線程任務處理的架構基本可以滿足需求。況且目前操作系統對異步IO的支持並非特別完善，更多的是采用IO多路復用模型模擬異步IO的方式（IO事件觸發時不直接通知用戶線程，而是將數據讀寫完畢后放到用戶指定的緩沖區中）。Java7之后已經支持了異步IO，感興趣的讀者可以嘗試使用。