Redis線程IO模型的示例分析

小編給大家分享一下Redis線程IO模型的示例分析，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

那么既然是單線程的為什么還這么快呢？

Redis的數據都在內存里面，所有的運算都是內存級別，處理數據是非常快速的，所以這里得注意一些復雜度為O(n)的指令，可能會導致服務器卡頓。

那么Redis是一個單線程是如何處理并發客戶端的連接呢？

這就是接下來要講的非阻塞IO、多路復用和事件輪詢API。

那什么是阻塞IO模型？即在讀寫數據過程中會發生阻塞現象。

當用戶線程發出IO請求之后，內核會去查看數據是否就緒，如果沒有就緒就會等待數據就緒，而用戶線程就會處于阻塞狀態，用戶線程交出CPU。當數據就緒之后，內核會將數據拷貝到用戶線程，并返回結果給用戶線程，用戶線程才解除block狀態。

####阻塞IO模型，如果數據沒有就緒，就會一直阻塞在read方法。data = socket.read();

非阻塞IO

當用戶線程發起一個read操作后，并不需要等待，而是馬上就得到了一個結果，不管你有沒有發送進來，會立即執行下一行代碼。如果結果是一個error時，它就知道數據還沒有準備好，于是它可以再次發送read操作。一旦內核中的數據準備好了，并且又再次收到了用戶線程的請求，那么它馬上就將數據拷貝到了用戶線程，然后返回。

最簡單的事件輪詢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也是類似的。

以上是“Redis線程IO模型的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！