經過多線程處理提升Redis性能

Redis一般被稱爲單進程單線程模型。

這不是真的！

Redis還運行多個後端線程來執行後端清理工做，例如清理髒數據和關閉文件描述符。在Redis中，主線程負責主要任務，包括但不限於：接收來自客戶端的鏈接，處理鏈接讀/寫事件，解析請求，處理命令，處理定時器事件和同步數據。只有一個CPU核心運行單個進程和單個線程。

對於小數據包，Redis服務器能夠處理80,000到100,000 QPS。更大的QPS超出了Redis服務器的處理能力。常見的解決方案是在分佈式架構中對數據進行分區並採用多個服務器。

然而，該解決方案也具備許多缺點。例如，要管理的Redis服務器太多; 某些適用於單個Redis服務器的命令不適用於數據分區; 數據分區沒法解決熱點讀/寫問題; 數據偏斜，從新分配和放大/縮小變得更加複雜。因爲單進程和單線程的限制，咱們但願能夠重構多線程以充分利用SMP多核架構的優點，從而提升單個Redis服務器的吞吐量。

要使Redis成爲多線程，最簡單的思考方式是每一個線程都執行I / O和命令處理。可是，因爲Redis處理的數據結構很複雜，多線程須要使用鎖來確保線程安全。鎖定粒度的不正確處理可能會下降性能。

咱們建議增長I / O線程的數量，以使獨立的I / O線程可以讀取/寫入鏈接，解析命令和回覆數據包中的數據，而且仍讓單個線程處理命令並執行計時器事件。這樣，能夠增長單個Redis服務器的吞吐量。

單進程和單線程模型

好處

1. 因爲單進程和單線程模型的限制，耗時的操做（例如dict rehash和過時的密鑰刪除）被分解爲多個步驟並在Redis實現中逐個執行。這防止了操做長時間執行，所以避免了操做對系統的長時間阻塞。單進程和單線程代碼易於編譯，這減小了由多進程和多線程引發的上下文切換和鎖定佔用。

缺點

1. 只能使用一個CPU內核，沒法利用多核優點。

2. 對於繁重的I / O應用程序，網絡I / O操做會消耗大量CPU容量。使用Redis做爲緩存的應用程序一般是繁重的I / O應用程序。這些應用程序基本上具備高QPS，使用相對簡單的命令（例如get，set和incr），可是對RT敏感。它們一般具備高帶寬使用率，甚至可能達到數百兆比特。因爲10 GB和25 GB網絡適配器的普及，網絡帶寬再也不是瓶頸。所以，咱們須要考慮的是如何利用多核的優點和網絡適配器的性能。

多線程模型與實現

線程模型

有三種線程類型，即：

1. 主線程

2. I / O線程

3. 工人線程

5. 1. 主線程：接收鏈接，建立客戶端，並轉發到I / O線程的鏈接。

   2. I / O線程：處理鏈接讀/寫事件，解析命令，將完整解析的命令轉發到工做線程進行處理，發送響應數據包並刪除鏈接。

   3. 工做線程：處理命令，生成客戶端響應數據包，並執行計時器事件。

   4. 主線程，I / O線程和工做線程分別由事件驅動。

   5. 線程經過無鎖隊列交換數據，並經過隧道發送通知。

   多線程模型的好處

   提升讀/寫性能

   壓力測試結果代表，在小數據包場景中，讀/寫性能可提升約三倍。

6. 提升主/從同步速度

   當主設備將同步數據發送到從設備時，數據將在I / O線程中發送。從主站讀取數據時，從站從工做線程讀取完整數據，從I / O線程讀取增量數據。這能夠有效地提升同步速度。

   後續任務

   第一項任務是增長I / O線程數並優化I / O讀/寫功能。接下來，咱們能夠分解工做線程，以便每一個線程完成I / O讀取，以及工做線程的工做。

   設置I / O線程數

   1. 測試結果代表I / O線程的數量不該超過6.不然，工做線程將成爲簡單操做的瓶頸。

   2. 在啓動進程時，必須設置I / O線程的數量。進程運行時，沒法修改I / O線程數。根據當前的鏈接分配策略，修改I / O線程的數量涉及從新分配鏈接，這很是複雜。

   注意事項

   1. 隨着10 GB和25 GB網絡適配器的普及，必須仔細考慮如何充分利用硬件性能。咱們能夠使用技術，例如用於networkI / O的多線程和內核繞過用戶模式協議棧。

   2. I / O線程可用於實現無阻塞數據遷移。I / O線程對數據進程進行編碼或轉發命令，而目標節點對數據進行解碼或執行命令。

   ————————————————————

   推薦閱讀：

   老王講架構：負載均衡

   支付寶系統架構內部剖析

   大數據Spark與Storm技術選型

   【贊】用Python實現Zabbix-API 監控

   程序員怎麼留住健康？

   大數據智慧平臺技術方案

   大數據聚合平臺解決方案