在前面事務裏面講過Redis是一個單線程應用程序，當然我們比較有代表性的單線程還有Node.js、Nginx等。
那麼既然是單線程的爲什麼還這麼快呢？
Redis的數據都在內存裏面，所有的運算都是內存級別，處理數據是非常快速的，所以這裏得注意一些複雜度爲O(n)的指令，可能會導致服務器卡頓。
那麼Redis是一個單線程是如何處理併發客戶端的連接呢？
這就是接下來要講的非阻塞IO、多路複用和事件輪詢API。
非阻塞IO
那什麼是阻塞IO模型？即在讀寫數據過程中會發生阻塞現象。
當用戶線程發出IO請求之後，內核會去查看數據是否就緒，如果沒有就緒就會等待數據就緒，而用戶線程就會處於阻塞狀態，用戶線程交出CPU。當數據就緒之後，內核會將數據拷貝到用戶線程，並返回結果給用戶線程，用戶線程才解除block狀態。
####阻塞IO模型，如果數據沒有就緒，就會一直阻塞在read方法。data = socket.read();
非阻塞IO
當用戶線程發起一個read操作後，並不需要等待，而是馬上就得到了一個結果，不管你有沒有發送進來，會立即執行下一行代碼。如果結果是一個error時，它就知道數據還沒有準備好，於是它可以再次發送read操作。一旦內核中的數據準備好了，並且又再次收到了用戶線程的請求，那麼它馬上就將數據拷貝到了用戶線程，然後返回。
非阻塞IO有個問題，那就是線程要讀數據，結果讀了一部分就返回了，那麼線程如何知道何時才應該繼續讀，也就是說，當數據到來時，線程如何得到通知。寫也是一樣，如果緩衝區滿了，寫不完，剩下的數據何時才應該繼續寫，線程也應該得到通知。那麼事件輪詢API就是解決這個問題。
多路複用（事件輪詢）
最簡單的事件輪詢API是select函數，它是操作系統提供給用戶程序的API。輸入是讀寫描述符列表read_fds&write_fds，輸出是與之對應的可讀可寫事件。同時還提供了一個timeout參數，如果沒有任何事件到來，那麼就最多等待timeout的值的時間，線程處於阻塞狀態。一旦期間有任何事件到來，就可以立即返回。時間過了之後還是沒有任何事件到來，也會主即返回 。
因爲我們通過select系統調用同時處理多個通道描述待的讀寫事件，因此我們將這類系統調用稱爲多路複用API。現代操作系統的多路複用API已經不再使用select系統調用，而改用epoll（linux）和kqueue(FreeBSD）和（macosx），因爲select系統調用的性能在描述符特別多時會變得非常差。它們使用起來可能在形式上略有差異，但是本質上都是差不多的，都可以使用上面的僞代碼邏輯進行理解。
指令隊列
Redis會將每個客戶端套接字都關聯一個指令隊列。客戶端的指令通過隊列來排隊進行順序處理，先到先服務。
響應隊列
Redis同樣也會爲每個客戶端套接字關聯一個晌應隊列。Redis服務器通過響應隊列來將指令的返回結果回覆給客戶端。
如果隊列爲空，那麼意昧着連接暫時處於空閒狀態，不需要去獲取寫事件，也就是可以將當前的客戶端描述符從write_fds裏面移出來。等到隊列有數據了，再將描述符放進去，避免select系統調用立即返回寫事件，結果發現沒什麼數據可以寫，出現這種情況的線程會令CPU消耗飄升。
定時任務
服務器除了要響應IO事件外，還要處理其他事情。比如定時任務就是非常重要的一件事。如果線程阻塞在select系統調用上，定時任務將無法得到準時調度。那Redis是如何解決這個問題的呢？
Redis的定時任務會記錄在一個被稱爲“最小堆”的數據結構中。在這個堆中，
最快要執行的任務排在堆的最上方。在每個循環週期裏，Redis都會對最小堆裏面已經到時間點的任務進行處理。處理完畢後，將最快要執行的任務還需要的時間記錄下來，這個時間就是select系統調用的timeout參數。因爲Redis知道未來timeout的值的時間內，沒有其他定時任務需要處理，所以可以安心睡眠 timeout 的值的時間。
Nginx和Node的事件處理原理和Redis也是類似的。
一名正在搶救的coder
筆名：mangolove
CSDN地址：https://blog.csdn.net/mango_love
GitHub地址：https://github.com/mangoloveYu
