Redis管道pipelining的示例分析

這篇文章將為大家詳細講解有關Redis管道pipelining的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

在講解管道前，我們首先來了解一下redis的交互，redis的一次交互是由客戶端發起，由服務端接收，那么我們連續操作一些指令，如下圖所示：

客戶端請求一個指令到服務器到服務器返回數據這個過程非常復雜，既要保證數據能夠快速傳到也要保證不丟包，那么每次請求響應這個過程中數據傳輸和客戶端接收數據的網絡消耗非常大，那么我們怎么來提升這個性能呢？

上面說了，我們來回幾次消耗大，那么可以一次性請求，一次性接收嗎？當然是可以的，redis可以利用管道來提高性能。

Redis客戶端與服務器之間使用TCP協議進行通信，并且很早就支持管道（pipelining）技術了。Redis 管道 (Pipeline) 本身并不是 Redis 服務器直接提供的技術，這個技術本質上是由客戶端提供的，跟服務器沒有什么直接的關系。

這里值得注意的是，管道空間也有上限，合理利用才是最好的選擇。

接下來我們測試一下管道的性能，Redis自帶了一個壓力測試工具redis-benchmark，使用這個工具就可以進行管道測試。 

首先我們對一個普通的set指令進行壓測，QPS大約5w/s。 

> redis-benchmark -t set -q SET: 53975.05 requests per second

我們加入管道選項-P參數，它表示單個管道內并行的請求數量，看下面 P=2，QPS達到了9w/s。 

> redis-benchmark -t set -P 2 -q SET: 94240.88 requests per second

再看看 P=3，QPS達到了 10w/s。 

> redis-benchmark -t set -P 2 -q SET: 102354.15 requests per second

但如果再繼續提升 P 參數，發現 QPS 已經上不去了。這是為什么呢？ 

因為這里CPU處理能力已經達到了瓶頸，Redis的單線程CPU已經飆到了 100%，所以無法再繼續提升了

接下來我們深入分析一個請求交互的流程

上圖就是一個完整的請求交互流程圖： 

    1、客戶端進程調用write將消息寫到操作系統內核為套接字分配的發送緩沖send buffer。 

    2、客戶端操作系統內核將發送緩沖的內容發送到網卡，網卡硬件將數據通過「網關路由」送到服務器的網卡。 

    3、服務器操作系統內核將網卡的數據放到內核為套接字分配的接收緩沖 recv buffer。 

     4、服務器進程調用read從接收緩沖中取出消息進行處理。 

    5、服務器進程調用write將響應消息寫到內核為套接字分配的發送緩沖 send buffer。 

    6、服務器操作系統內核將發送緩沖的內容發送到網卡，網卡硬件將數據通過「網關路由」送到客戶端的網卡。 

    7、客戶端操作系統內核將網卡的數據放到內核為套接字分配的接收緩沖 recv buffer。 

    8、客戶端進程調用read從接收緩沖中取出消息返回給上層業務邏輯進行處理。 

    9、結束。 

我們開始以為write操作是要等到對方收到消息才會返回，但實際上不是這樣的。write操作只負責將數據寫到本地操作系統內核的發送緩沖然后就返回了。剩下的事交給操作系統內核異步將數據送到目標機器。但是如果發送緩沖滿了，那么就需要等待緩沖空出空閑空間來，這個就是寫操作IO操作的真正耗時。我們開始以為read操作是從目標機器拉取數據，但實際上不是這樣的。read操作只負責將數據從本地操作系統內核的接收緩沖中取出來就了事了。

所以對于value=redis.get(key)這樣一個簡單的請求來說，write操作幾乎沒有耗時，直接寫到發送緩沖就返回，而read就會比較耗時了，因為它要等待消息經過網絡路由到目標機器處理后的響應消息,再回送到當前的內核讀緩沖才可以返回。這才是一個網絡來回的真正開銷。 而對于管道來說，連續的write操作根本就沒有耗時，之后第一個read操作會等待一個網絡的來回開銷，然后所有的響應消息就都已經回送到內核的讀緩沖了，后續的 read 操作直接就可以從緩沖拿到結果，瞬間就返回了。 

這就是管道的本質了，它并不是服務器的什么特性，而是客戶端通過改變了讀寫的順序帶來的性能的巨大提升。 

關于“Redis管道pipelining的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。