點擊上方☝Java編程技術樂園，輕鬆關注！及時獲取有趣有料的技術文章
做一個積極的人
編碼、改bug、提升自己
我有一個樂園，面向編程，春暖花開！
上一篇回顧：
面試官：Redis為什麼設計成單線程的？
一、Redis為什麼是單線程
注意：redis 單線程指的是網絡請求模塊使用了一個線程，即一個線程處理所有網絡請求，其他模塊仍用了多個線程。
因為CPU不是Redis的瓶頸。Redis的瓶頸最有可能是機器內存或者網絡帶寬，既然單線程容易實現，而且CPU不會成為瓶頸，那就順理成章地採用單線程的方案了。關於redis的性能，官方網站也有，普通筆記本輕鬆處理每秒幾十萬的請求。
二、Redis為什麼這麼快
1、完全基於內存，絕大部分請求是純粹的內存操作，非常快速。數據存在內存中，類似於HashMap，HashMap的優勢就是查找和操作的時間複雜度都是O(1)；
2、數據結構簡單，對數據操作也簡單，Redis中的數據結構是專門進行設計的；
3、採用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的性能消耗；
4、使用多路I/O複用模型，非阻塞IO；
5、使用底層模型不同，它們之間底層實現方式以及與客戶端之間通信的應用協議不一樣，Redis直接自己構建了VM 機制 ，因為一般的系統調用系統函數的話，會浪費一定的時間去移動和請求；
三、多路I/O複用模型，非阻塞IO
下面舉一個例子，模擬一個tcp服務器處理30個客戶socket。
假設你是一個監考老師，讓30個學生解答一道競賽考題，然後負責驗收學生答卷，你有下面幾個選擇：
1. 第一種選擇：按順序逐個驗收，先驗收A，然後是B，之後是C、D。。。這中間如果有一個學生卡住，全班都會被耽誤。
這種模式就好比，你用循環挨個處理socket，根本不具有併發能力。
2. 第二種選擇：你創建30個分身，每個分身檢查一個學生的答案是否正確。這種類似於為每一個用戶創建一個進程或者線程處理連接。
3. 第三種選擇，你站在講臺上等，誰解答完誰舉手。這時C、D舉手，表示他們解答問題完畢，你下去依次檢查C、D的答案，然後繼續回到講臺上等。此時E、A又舉手，然後去處理E和A。。。
這種就是IO複用模型，Linux下的select、poll和epoll就是幹這個的。將用戶socket對應的fd註冊進epoll，然後epoll幫你監聽哪些socket上有消息到達，這樣就避免了大量的無用操作。此時的socket應該採用非阻塞模式。
這樣，整個過程只在調用select、poll、epoll這些調用的時候才會阻塞，收發客戶消息是不會阻塞的，整個進程或者線程就被充分利用起來，這就是事件驅動，所謂的reactor模式。
針對上面的舉例在Redis中表現為
有30個redis客戶端（考生）與redis服務器的網絡連接模塊（監考老師）保持TCP連接，客戶端會不定時的發送請求給服務器，當有一個redis客戶端發起請求，會觸發unix系統像epoll這樣的系統調用，Redis的I/O 多路複用模塊封裝了底層的epoll這樣的 I/O 多路複用函數，然後轉發到相應的事件處理器。
最後多路I/O複用模型圖
文件事件處理器使用 I/O 多路複用模塊同時監聽多個 FD（文件描述符），當 accept、read、write 和 close 文件事件產生時，文件事件處理器就會回調 FD 綁定的事件處理器。
雖然整個文件事件處理器是在單線程上運行的，但是通過 I/O 多路複用模塊的引入，實現了同時對多個 FD 讀寫的監控，提高了網絡通信模型的性能，同時也可以保證整個 Redis 服務實現的簡單。
持續推送Redis相關技術，歡迎關注~ 後臺回覆【秘籍】，獲取珍藏的武功秘籍!一起來修煉
閱讀更多 Java武學祕籍 的文章
