背景
上回說到小楓在接受面試官的拷打，所幸第一個問題回答的還不錯，因此面試官對於小楓的初步印象還行。我們接着來看看小楓是怎麼和麪試官繼續過招的吧，他還能扛得住面試官幾個連環炮呢？
面試官考察目的分析
面試官：Redis瞭解嗎？說說爲什麼單線程的Redis可以支持高併發訪問？
面試官考察目的分析：
1、考察候選同學對於Redis原理的理解程度；
2、考察候選同學對於網絡連接的理解程度；
面試題分析
面試官的問題中包含了兩個關鍵詞，一個是單線程一個是高併發訪問，因此我們在回答問題的時候主要從兩個方面出發，先解釋清楚爲什麼Redis選擇單線程的實現方式，再解釋清楚爲什麼Redis能支持高併發訪問。
小楓：（內心OS：根據面試官的問題，決定從兩方面來進行闡述，先整理下回答思路）
從Redis自身特性來說，Redis是基於內存的數據庫，所以數據處理速度非常快。另外它的底層使用了很多效率很高的數據結構，如哈希表和跳錶等。另外Redis從狹義上面來說他是單線程的，網絡請求解析與數據讀寫都是由主線程完成。因此它內部就省去了很多多線程訪問共享數據資源的繁瑣設計，同時也避免了頻繁的線程上下文切換因此減少了多線程的系統開銷。
從IO模型角度來說，Redis使用的是IO多路複用模型，使得它可以在網絡IO操作併發處理數十萬的客戶端網絡連接，實現非常高的網絡吞吐率。這也是Redis可以實現高併發訪問的最主要的原因。
面試官：剛纔你提到了IO多路複用模型，能詳細說下Redis的IO多路複用的原理嗎？
小楓：（內心OS：當時爲了搞清楚這個問題，還特意扒了Redis源碼來看，對於一個Java程序猿來說，看c真的頭暈啊）
好的。首先要明確的是Redis依賴Linux操作系統實現的高性能IO，剛剛提到的多路複用IO模型實際也是傳統阻塞型IO模型演化而來的。在傳統的網絡IO操作中，accept() 和 recv()函數都是阻塞型的，一旦發生阻塞，影響其他網絡連接。但是在多路複用IO模型中，可以實現同時存在多個socket，內核監聽socket中的是否有數據請求或者連接請求，如果有請求，那麼內核就會交給Redis進行處理，因此Redis的主線程，也就是單線程的Redis可以處理多個IO連接。
整個過程涉及到epoll_create、epoll_ctl以及epoll_wait三個系統調用，具體的過程大致是這樣的：
1、當Redis啓動的時候，會調用內核的epoll_create創建epoll對象，在這個過程中包含初始化紅黑樹cache以及雙向鏈表，紅黑樹中主要存儲了需要進行狀態監控的FD，實際就是epitem結構體，雙向鏈表中存儲了需要返回給用戶已經處於就緒狀態的事件。
2、調用epoll_ctl()，通過epoll_ctl註冊要監聽的事件類型，將客戶端FD以及需要監聽的事件添加到紅黑樹cache中，添加時進行檢查，如果已存在則返回，如果不存在則添加到節點當中，同時註冊相應的事件回調函數，如果存在連接事件或者讀寫事件，那麼就會通過回調函數將就緒的事件加入到雙向鏈表中，實際就是紅黑樹的節點。
3、Redis調用epoll_wait獲取已經就緒的事件的fired數組，fire數組的事件中存儲了就緒的FD以及事件類型，遍歷數組中的事件，根據事件類型處理函數繼續後續的處理。如果是讀事件那就調用讀事件處理函數進行處理。對於Redis來說它只要關注鏈表中有沒有數據就好，有數據就會進行讀取，沒有數據則阻塞超過timeout之後再進行調用。在大多數情況下，返回的數組中包含的事件並不多。通過這樣的設計，Redis不需要一直輪訓檢查到底有沒有實際的請求發生，避免了CPU資源的浪費。因此及時是單線程的Redis，藉助於epoll機制，它也可以實現數十萬連接的併發處理。
面試官：（內心OS：小夥子回答的不錯，看來常見的面試題難不倒你啊，那麼我就來問問陷阱題吧，嘿嘿）
總結
程序猿小楓這次表現不錯，抗住了面試官關於Redis的連環炮，那麼接下來的問題他還能回答出來嗎？請大家繼續拭目以待哦。
