前言
"redis是單執行緒的" 這句話我們耳熟能詳，但它有一定的前提，redis整個服務不可能只用到一個執行緒完成所有作業，它還有持久化、key過期洗掉、集群管理等其它模塊，redis會通過fork子行程或開啟額外的執行緒去處理，所謂的單執行緒是指從網路連接(accept) -> 讀取請求內容(read) -> 執行命令 -> 回應內容(write)，這整個程序是由一個執行緒完成的，至于為什么redis要設計為單執行緒，主要有以下原因：
- 基于記憶體，redis命令操作主要都是基于記憶體，這已經足夠快，不需要借助多執行緒，
- 高效的資料結構，redis底層提供了動態簡單動態字串(SDS)、跳表(skiplist)、壓縮串列(ziplist)等資料結構來高效訪問資料，
- 保持簡單，引入多執行緒會使redis變得復雜，例如需要考慮多執行緒并發訪問資源競爭問題，資料結構也會變得復雜，hash就不能是單純的hash，需要像java一樣設計一個ConcurrentHashMap，還需要考慮執行緒切換帶來的性能損耗，基于第一點，當程式執行已經足夠快，多執行緒并不能帶來正面收益，
按照redis官方介紹，單個節點的redis qps可以達到10w+，已經非常優秀，如果有更高的要求，則可以通過部署主從、集群方式進一步提升，
單執行緒不是沒有缺點的，我們需要辯證的看待問題，不然所有的組件都可以使用redis替代了，首先是基于記憶體的操作有丟失資料的風險，盡管你可以配置appendfsync always每次將執行請求通過aof檔案持久化，但這也會帶來性能的下降，另外單執行緒的執行意味著所有的請求都需要排隊執行，如果有一個命令阻塞了，其它命令也都執行不了，可以與之比較的是mysql，如果有一條sql陳述句執行比較慢，只要它不完全拖垮資料庫，其它請求的sql陳述句還是可以執行，最后，從上面可以看到從接收網路連接到寫回回應內容，對于網路請求部分的處理其實是可以多執行緒執行來提升網路IO效率的，
redis 6.0
從redis 6.0開始，網路連接(accept) -> 讀取請求內容(read) -> 執行命令 -> 回應內容(write) 這個程序中的“執行命令”這個步驟依然保持單執行緒執行，而對于網路IO讀寫是多執行緒執行的了，原因是這部分是網路IO的決議、回應處理，已經不是單純的記憶體操作，可以充分利用多核CPU的優勢提升性能，對于這部分的性能需求其實一直都存在，社區也有KeyDB這樣的產品，其核心就是在redis的基礎上對多執行緒的支持，這多redis來說無疑是一種挑戰，所有redis6.0開始在網路IO處理支持多執行緒就顯得非常必要了，
我們知道redis客戶端連接是可以有很多個的，最多可以有maxclients引數配置的數量，默認是10000個，那么redis是如何高效處理這么多連接的呢？以及6.0和之前的版本是如何具體處理從接收連接到回應整個程序的，或者說redis執行緒模型是怎么樣的，清楚的了解這些有助于我們更好的學習redis，其中的知識在以后學習其它中間件也可以很好的借鑒，
linux IO模型
在學習redis網路IO模型之前我們必須先了解一下linux的IO模型，以為redis也是基于作業系統去設計的，I/O是Input/Output的縮寫，是指作業系統與外部設備進行讀取、輸出的互動程序，外部設備可以是網卡、磁盤等，作業系統一般都分為內核和用戶空間兩部分，內核負責與底層硬體互動，用戶程式讀寫資料都需要經過內核空間，也就是資料會不斷的在內核-用戶空間進行復制，不同的IO模型在這個復制程序用戶執行緒有不同的表現，有的是阻塞，有的是非阻塞，有的是同步，有的是異步，
以linux為例，常見的IO模型有阻塞IO、非阻塞IO、IO多路復用、信號驅動IO、異步IO 5種，這次我們主要關注前3個，重點是IO多路復用，另外兩個在使用上有一些局限性，實際應用并不多，這5種IO模型我們在這一篇已經有詳細的介紹，這里簡單再復習一遍，
以一個最簡單例子，現在有兩個客戶端需要連接、發送資料到我們的服務端，看下服務端在各種IO模型下是如何接收、讀取請求的，
阻塞IO(Blocking IO)
假設服務端只開啟一個執行緒處理請求，第一個請求到來，開始呼叫內核read函式，然后就會發生阻塞，第二個請求到來時服務端將無法處理，只能等第一個請求讀取完成，這種方式的缺點很明顯，每次只能處理一個請求，無法發揮cpu多核優勢，性能低下，
為了解決這個問題，我們可以引入多執行緒，這樣就可以同時處理多個請求了，但服務端可能同時有成千上萬的請求需要處理，隨之而來的是執行緒數膨脹，頻繁創建、銷毀執行緒帶來的性能影響，當然我們可以使用執行緒池，但服務能處理的總體數量就會受限于執行緒池執行緒數量，
非阻塞IO(NON-Blocking IO)
相比阻塞IO，非阻塞IO會立即回傳，呼叫者不會阻塞，此時可以做一些其它事情，例如處理其它請求，但是非阻塞IO需要主動輪詢是否有資料需要處理，且這種輪詢需要從用戶態切換到內核態這，假如沒有資料產生就會有很多空輪詢，白白浪費cpu資源，
阻塞IO、非阻塞IO，要么需要開啟更多執行緒去處理IO，要么需要從用戶態切換到內核態輪詢IO事件，那么有沒有一種機制，用戶程式只需要將請求提交給內核，由內核用少量的執行緒去監聽，有事件就通知用戶程式呢？這就是IO多路復用，
IO多路復用(IO Multiplexing)
IO多路復用機制是指一個執行緒處理多個IO流，多路是指網路連接，復用指的是同一個執行緒，
如果簡單從圖上看IO多路復用相比阻塞IO似乎并沒有什么高明之處，假設服務只處理少量的連接，那么相比阻塞IO確實沒有太大的提升，但如果連接數非常多，差距就會立竿見影，
首先IO多路復用會提交一批需要監聽的檔案句柄（socket也是一種檔案句柄）到內核，由內核開啟一個執行緒負責監聽，把輪詢作業交給內核，當有事件發生時，由內核通知用戶程式，這不需要用戶程式開啟更多的執行緒去處理連接，也不需要用戶程式切換到內核態去輪詢，用一個執行緒就能處理大量網路IO請求，
redis底層采用的就是IO多路復用模型，實際上基本所有中間件在處理網路IO這一塊都會使用到IO多路復用，如kafka,rocketmq等，所以本次學習之后對其它中間件的理解也是很有幫助的，
select/poll/epoll
這三個函式是實作linux io多路復用的內核函式，我們簡單了解下，
linux最開始提供的是select函式，方法如下：
select(int nfds, fd_set *r, fd_set *w, fd_set *e, struct timeval *timeout)
該方法需要傳遞3個集合，r,e,w分別表示讀、寫、例外事件集合，集合型別是bitmap，通過0/1表示該位置的fd(檔案描述符，socket也是其中一種)是否關心對應讀、寫、例外事件，例如我們對fd為1和2的讀事件關心，r引數的第1,2個bit就設定為1，
用戶行程呼叫select函式將關心的事件傳遞給內核系統，然后就會阻塞，直到傳遞的事件至少有一個發生時，方法呼叫會回傳，內核回傳時，同樣把發生的事件用這3個引數回傳回來，如r引數第1個bit為1表示fd為1的發生讀事件，第2個bit依然為0，表示fd為2的沒有發生讀事件，用戶行程呼叫時傳遞關心的事件，內核回傳時回傳發生的事件，
select存在的問題：
- 大小有限制，為1024，由于每次select函式呼叫都需要在用戶空間和內核空間傳遞這些引數，為了提升拷貝效率，linux限制最大為1024，
- 這3個集合有相應事件觸發時，會被內核修改，所以每次呼叫select方法都需要重新設定這3個集合的內容，
- 當有事件觸發select方法回傳，需要遍歷集合才能找到就緒的檔案描述符，例如傳1024個讀事件，只有一個讀事件發生，需要遍歷1024個才能找到這一個，
- 同樣在內核級別，每次需要遍歷集合查看有哪些事件發生，效率低下，
poll函式對select函式做了一些改進
poll(struct pollfd *fds, int nfds, int timeout)
struct pollfd {
int fd;
short events;
short revents;
}
poll函式需要傳一個pollfd結構陣列，其中fd表示檔案描述符，events表示關心的事件，revents表示發生的事件，當有事件發生時，內核通過這個引數回傳回來，
poll相比select的改進：
- 傳不固定大小的陣列，沒有1024的限制了（問題1）
- 將關心的事件和實際發生的事件分開，不需要每次都重新設定引數（問題2），例如poll陣列傳1024個fd和事件，實際只有一個事件發生，那么只需要重置一下這個fd的revent即可，而select需要重置1024個bit，
poll沒有解決select的問題3和4，另外，雖然poll沒有1024個大小的限制，但每次依然需要在用戶和內核空間傳輸這些內容，數量大時效率依然較低，
這幾個問題的根本實際很簡單，核心問題是select/poll方法對于內核來說是無狀態的，內核不會保存用戶呼叫傳遞的資料，所以每次都是全量在用戶和內核空間來回拷貝，如果呼叫時傳給內核就保存起來，有新增檔案描述符需要關注就再次呼叫增量添加，有事件觸發時就只回傳對應的檔案描述符，那么問題就迎刃而解了，這就是epoll做的事情，
epoll對應3個方法
int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);
epoll_create負責創建一個背景關系，用于存盤資料，底層是用紅黑樹，以后的操作就都在這個背景關系上進行，
epoll_ctl負責將檔案描述和所關心的事件注冊到背景關系，
epoll_wait用于等待事件的發生，當有有事件觸發，就只回傳對應的檔案描述符了，
reactor模式
前面我們介紹的IO多路復用是作業系統的底層實作，借助IO多路復用我們實作了一個執行緒就可以處理大量網路IO請求，那么接收到這些請求后該如何高效的回應，這就是reactor要關注的事情，reactor模式是基于事件的一種設計模式，在reactor中分為3中角色：
Reactor：負責監聽和分發事件
Acceptor：負責處理連接事件
Handler：負責處理請求，讀取資料，寫回資料
從執行緒角度出發，reactor又可以分為單reactor單執行緒，單reactor多執行緒，多reactor多執行緒3種，
單reactor單執行緒
處理程序：reactor負責監聽連接事件，當有連接到來時，通過acceptor處理連接，得到建立好的socket物件，reactor監聽scoket物件的讀寫事件，讀寫事件觸發時，交由handler處理，handler負責讀取請求內容，處理請求內容，回應資料，
可以看到這種模式比較簡單，讀取請求資料，處理請求內容，回應資料都是在一個執行緒內完成的，如果整個程序回應都比較快，可以獲得比較好的結果，缺點是請求都在一個執行緒內完成，無法發揮多核cpu的優勢，如果處理請求內容這一塊比較慢，就會影響整體性能，
單reactor多執行緒
既然處理請求這里可能由性能問題，那么這里可以開啟一個執行緒池來處理，這就是單reactor多執行緒模式，請求連接、讀寫還是由主執行緒負責，處理請求內容交由執行緒池處理，相比之下，多執行緒模式可以利用cpu多核的優勢，單仔細思考這里依然有性能優化的點，就是對于請求的讀寫這里依然是在主執行緒完成的，如果這里也可以多執行緒，那效率就可以進一步提升，
多reactor多執行緒
多reactor多執行緒下，mainReactor接收到請求交由acceptor處理后，mainReactor不再讀取、寫回網路資料，直接將請求交給subReactor執行緒池處理，這樣讀取、寫回資料多個請求之間也可以并發執行了，
redis網路IO模型
redis網路IO模型底層使用IO多路復用，通過reactor模式實作的，在redis 6.0以前屬于單reactor單執行緒模式，如圖：
在linux下，IO多路復用程式使用epoll實作，負責監聽服務端連接、socket的讀取、寫入事件，然后將事件丟到事件佇列，由事件分發器對事件進行分發，事件分發器會根據事件型別，分發給對應的事件處理器進行處理，我們以一個get key簡單命令為例，一次完整的請求如下：
請求首先要建立TCP連接(TCP3次握手)，程序如下：
redis服務啟動，主執行緒運行，監聽指定的埠，將連接事件系結命令應答處理器，
客戶端請求建立連接，連接事件觸發，IO多路復用程式將連接事件丟入事件佇列，事件分發器將連接事件交由命令應答處理器處理，
命令應答處理器創建socket物件，將ae_readable事件和命令請求處理器關聯，交由IO多路復用程式監聽，
連接建立后，就開始執行get key請求了，如下：
客戶端發送get key命令，socket接收到資料變成可讀，IO多路復用程式監聽到可讀事件，將讀事件丟到事件佇列，由事件分發器分發給上一步系結的命令請求處理器執行，
命令請求處理器接收到資料后，對資料進行決議，執行get命令，從記憶體查詢到key對應的資料，并將ae_writeable寫事件和回應處理器關聯起來，交由IO多路復用程式監聽，
客戶端準備好接收資料，命令請求處理器產生ae_writeable事件，IO多路復用程式監聽到寫事件，將寫事件丟到事件佇列，由事件分發器發給命令回應處理器進行處理，
命令回應處理器將資料寫回socket回傳給客戶端，
reids 6.0以前網路IO的讀寫和請求的處理都在一個執行緒完成，盡管redis在請求處理基于記憶體處理很快，不會稱為系統瓶頸，但隨著請求數的增加，網路讀寫這一塊存在優化空間，所以redis 6.0開始對網路IO讀寫提供多執行緒支持，需要知道的是，redis 6.0對多執行緒的默認是不開啟的，可以通過 io-threads 4 引數開啟對網路寫資料多執行緒支持，如果對于讀也要開啟多執行緒需要額外設定 io-threads-do-reads yes 引數，該引數默認是no，因為redis認為對于讀開啟多執行緒幫助不大，但如果你通過壓測后發現有明顯幫助，則可以開啟，
redis 6.0多執行緒模型思想上類似單reactor多執行緒和多reactor多執行緒，但不完全一樣，這兩者handler對于邏輯處理這一塊都是使用執行緒池，而redis命令執行依舊保持單執行緒，如下：
可以看到對于網路的讀寫都是提交給執行緒池去執行，充分利用了cpu多核優勢，這樣主執行緒可以繼續處理其它請求了，
開啟多執行緒后多redis進行壓測結果可以參考這里，如下圖可以看到，對于簡單命令qps可以達到20w左右，相比單執行緒有一倍的提升，性能提升效果明顯，對于生產環境如果大家使用了新版本的redis，現在7.0也出來了，建議開啟多執行緒，
總結
本篇我們學習redis單執行緒具體是如何單執行緒以及在不同版本的區別，通過網路IO模型知道IO多路復用如何用一個執行緒處理監聽多個網路請求，并詳細了解3種reactor模型，這是在IO多路復用基礎上的一種設計模式，最后學習了redis單執行緒、多執行緒版本是如何基于reactor模型處理請求，其中IO多路復用和reactor模型在許多中間件都有使用到，后續再接觸到就不陌生了，
歡迎關注我的github：https://github.com/jmilktea/jtea
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/539692.html
標籤：其他