Redis處理客戶端請求所採用的處理結構，稱為Redis的IO模型。不同版本的Redis採用的IO模型是不同的。
單執行緒模型
Redis 3.0 及 以前的版本，Redis IO模型採用的是純粹的單執行緒模型，即所有的客戶端請求全部有一個執行緒處理。
混合執行緒模型
從Redis 4.0 版本開始，Redis 中就開始加入了多執行緒元素，處理客戶端請求的仍是單執行緒模型，但對於一些比較耗時但有不影響客戶端響應的操作，交由後臺其它執行緒處理。例如，持久化、對AOF的rewrite、對失效連線的清理等。
多執行緒模型
Redis 從6.0 版本開始，支援了多執行緒模型；之前版本採用的是單執行緒模型。
第一部分 單執行緒模型
1.1 單執行緒模型示意圖
1.2 優、缺點
優點:
可維護性高-- 不存在併發讀寫的情況、無執行緒切換的問題與開銷；沒有執行順序不確定性問題，不存在 加鎖、釋放鎖、死鎖等問題。
缺點
效能有些影響，資源浪費（單執行緒只能使用一個處理器）。
1.3 多路複用（事件輪詢）
Redis的單執行緒模型採用了多路複用技術。
多路複用技術的多路選擇演算法常見的有三種：select模型、poll模型、epoll模型。
select模型的選擇演算法：最簡單的事件輪詢。輸入是讀寫描述符列表read_fds & write_fds, 輸出是與之對應的可讀可寫事件。同時還提供了一個timeout引數，如果沒有任何事件到來，那麼就最多等待timeout的值的時間，執行緒處於阻塞狀態。一旦期間有任何事件的到來，那麼就立即返回。時間過了之後，還是沒有任何事件到來，也會立即返回。每個客戶端套接字socket都有對應的讀寫檔案描述符。
poll模型的選擇演算法：採用的是輪詢演算法。該模型的缺點是對客戶端（scoket連線）處理有延遲。
epoll模型的選擇演算法：採用的是回撥方式。
現在作業系統的多路複用已經不再使用select模型，而是使用epool(linux)。（select 的缺點：呼叫的效能在描述符多的情況下，會變得很差。）
第二部分 多執行緒
2.1 多執行緒模型示意圖
多執行緒IO模型中的”多執行緒“，僅用於接受、解析客戶端的請求，而後寫入到任務佇列。而對具體任務（命令）的處理，仍是由主執行緒處理。這樣做使得使用者無需考慮執行緒安全問題，無需考慮事務控制，無需考慮像LPUSH 、LPOP等命令的執行順序。
【注意：並非是一個真正意義上的”多執行緒“，因為真正處理”任務“的執行緒仍是單執行緒。】
學習參閱宣告
【Redis影片從入門到高階，redis影片教程詳解，Redis一課在手，別無所求】
https://www.bilibili.com/video/BV1U24y1y7jF?p=11&vd_source=0e347fbc6c2b049143afaa5a15abfc1c】