不是講線程模型嗎？和事件有什麼關系？實際上 Redis 是一個事件驅動程序，大白話理解一下：就是通過事件的方式來運行 Redis 的。比如客戶端向服務端發起一個 get 請求，在做好了建連、發送請求、響應請求、關閉連接等準備操作後，就觸發了一個事件。所以在了解線程模型之前，先來看看事件。

Redis 的事件分為兩種，分别是文件事件和時間事件兩種。

文件事件是 socket 的一個抽象，客戶端發送請求到服務端，會先建立連接，然後通過連接發送命令請求，其中每個連接就是一個 socket。對于一個 Redis 服務端，在同一時刻會有很多 socket 連接，每一個 socket 都可以理解成一個文件事件。

每産生一個文件事件後，就将其交給文件事件處理器去處理，文件事件處理器是由 I/O 多路複用處理器、文件事件分發器、事件處理器幾部分組成。服務端在接收到請求後，是怎麼工作的呢？

從上圖可以看出，當客戶端發送請求到服務端後；

1. 首先服務端通過 I/O 多路複用處理器接收文件事件（即一個一個的 socket），并将接收到的文件事件插入到事件隊列中。
2. 接收文件事件分發器将接收到的時間按照事件類型分發給不同的事件處理器去執行；比如客戶端發送了一個 get 請求，文件事件處理器就會将該請求發送給讀取事件處理器去執行。
3. 相應的事件處理器接收到請求後，就去執行相應的操作，然後将相應的結果返回。
4. 當一個事件處理完畢并返回相應的結果後，文件事件分發器繼續處理事件隊列中的下一個請求，重複上述的動作，直到沒有文件事件可以被處理。這個流程其實有點像生産者消費者的樣子。

I/O 對路複用處理器在 Redis 中用很多種實現，比如 epool、select、evport、kquene 等等，Redis 服務端在運行的時候會根據預先設定的 include 宏定義來選擇效率最高的模型去處理網絡事件。

以上基本上就是 Redis 的線程工作模型，不過還差一點就是文章開頭講到的另外一種事件類型，時間事件。

時間事件，顧名思義就是和時間相關的一些事件操作。舉個例子，在 Redis 中最不陌生的應該就是各種定時處理器，每隔一段時間就出發一個操作。具體的應用如 RDB 和 AOF 文件定時做持久化操作；如果集群是主從架構的，定時将主庫上的數據同步給從庫，定期發送心跳信息給集群内各個節點，檢查節點是否還在正常提供服務；定期檢查庫裡面設置了過期時間的 key 并将已過期的 key 從内存中提出等等一些實際應用。

時間事件是怎麼實現的？

Redis 将所有時間事件通過鍊表串聯起來，每個結點代表一個時間事件，每個結點上存儲着當前時間下一次要發生的時間點；每隔一段時間，該鍊表就會被遍曆一次，發現那個時間事件該執行就去執行對應的事件，然後更新其下一次應該執行的時間點。

文件事件和時間事件是怎麼配合工作的？

如上圖，文件事件和時間事件配合工作流程圖。

1. 服務器啟動後，開始監聽文件事件，如果在一段時間内有監聽到文件事件，則會執行文件事件，執行完文件事件後，開始遍曆時間事件，這裡需要注意的是，如果文件事件執行時間過長，不會讓其一直執行，而是暫停，等待下一個周期在繼續執行。
2. 文件事件執行完，開始遍曆執行時間事件，遇到需要執行的時間事件，比如定時持久化 RDB 和 AOF 等比較耗時的操作時，會 Fork 出一個子線程去執行，而不會夯住當前線程。
3. 依次循環上述流程，就完成了文件事件和時間事件的配合工作的流程了。

相信很多朋友已經知道了，2020 年 Redis 官方在 5 月份發布多了多線程版本，不過默認是不開啟的，可通過 conf 配置開啟。從目前 Redis 在實際生産環境中的使用情況看，其每秒鐘支持的吞吐量已經非常高了。Redis 發展到目前，其主要的性能瓶頸主要在網絡 I/O 和内存兩個方面。

1. 内存容量問題：如果采用集群部署的方式，可以通過部署多個端口，使得總容量得到提升，在一定程度上可以解決内存的問題。
2. 網絡 I/O 問題：在實際生産環境中，Redis 在執行命令時計算基于内存是可以在很快時間内完成的，但是數據傳輸過程中需要經過網絡 I/O 操作，這一步才是真正耗時所在。所以 Redis 在 6.0 版本引入了所謂的多線程，其主要是在做網絡 I/O 操作的時候采用了多線程的方式加快 I/O 操作，而命令的執行還是采用單線程進行工作的。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!