redis執行緒模型-學習小結

前言：最近寫的一個專案用到了redis中的list實現一個簡單的佇列去非同步執行計算任務，開發的過程中想起了redis的執行緒模型天然保證了list中的訊息不會被多次/重複消費，但又有點生疏了，藉此複習一下redis的執行緒模型。

redis執行緒模型概覽：

① 由多個socket接收來自客戶端的各種請求，例如：建立通道，返回data，傳送redis指令等。
② socket由I/O多路複用程式進行監聽，redis中的I/O多路複用機制採用的是非阻塞的epoll模型。
③ 將執行命令順序壓入佇列，由檔案事件分派器將分派給相應的處理器處理完畢後返回結果（或資料）。

重點強調：
① redis內部實現的檔案事件處理器為單執行緒的，這也是為什麼redis經常被稱為但單執行緒的原因，但實際上並不是整個redis例項都只有一個執行緒，例如從4.0開始就有的多執行緒在後臺刪除物件，以及從6.0開始的多執行緒網路I/O。具體可看：https://www.cnblogs.com/javastack/p/12848446.html

② 整個redis執行緒模型基於Reactor模型，命令經I/O多路複用程式被存入佇列中後，檔案事件分派器單執行緒處理命令，所以客戶端命令不一定是順序的，但不會有兩條命令被同時執行，也就不會有併發問題（天然解決了開頭說的重複消費的問題，當然要在程式碼里加一些判斷，避免取回空值）

最後：
問：redis為什麼單執行緒也能抗住高併發？
① 基於純記憶體訪問
② 內建時間複雜度低，專門應對高速場景的資料結構
③ 非阻塞I/O：基於epoll模型
④ 單執行緒避免了多執行緒上下文的切換問題：本身使用多執行緒的一大原因就是當一個執行緒I/O時，另一個執行緒可以使用CPU，充分利用資源。但因為redis基於記憶體並沒有I/O，它的執行效率瓶頸並不在I/O上，所以採用多執行緒反而會浪費資源在沒必要的上下文切換中。