Redis管線怎么理解

Redis是一種典型的基于C/S模型的TCP服務器。在客戶端與服務器的通訊過程中，通常都是客戶端率先發(fā)起請求，服務器在接收到請求后執(zhí)行相應的任務，最后再將獲取的數(shù)據(jù)或處理結(jié)果以應答的方式發(fā)送給客戶端。在此過程中，客戶端都會以阻塞的方式等待服務器返回的結(jié)果。見如下命令序列：
    Client: INCR X
    Server: 1
    Client: INCR X
    Server: 2
    Client: INCR X
    Server: 3
    Client: INCR X
    Server: 4

在每一對請求與應答的過程中，我們都不得不承受網(wǎng)絡傳輸所帶來的額外開銷。我們通常將這種開銷稱為RTT(Round Trip Time)?，F(xiàn)在我們假設每一次請求與應答的RTT為250毫秒，而我們的服務器可以在一秒內(nèi)處理100k的數(shù)據(jù)，可結(jié)果則是我們的服務器每秒至多處理4 條請求。要想解決這一性能問題，我們該如何進行優(yōu)化呢？

Redis在很早的版本中就已經(jīng)提供了對命令管線的支持。在給出具體解釋之前，我們先將上面的同步應答方式的例子改造為基于命令管線的異步應答方式，這樣可以讓大家有一個更好的感性認識。
    Client: INCR X
    Client: INCR X
    Client: INCR X
    Client: INCR X
    Server: 1
    Server: 2
    Server: 3
    Server: 4

從以上示例可以看出，客戶端在發(fā)送命令之后，不用立刻等待來自服務器的應答，而是可以繼續(xù)發(fā)送后面的命令。在命令發(fā)送完畢后，再一次性的讀取之前所有命令的應答。這樣便節(jié)省了同步方式中RTT的開銷。

最后需要說明的是，如果Redis服務器發(fā)現(xiàn)客戶端的請求是基于管線的，那么服務器端在接受到請求并處理之后，會將每條命令的應答數(shù)據(jù)存入隊列，之后再發(fā)送到客戶端。

以下是來自Redis官網(wǎng)的測試用例和測試結(jié)果。需要說明的是，該測試是基于loopback(127.0.0.1)的，因此RTT所占用的時間相對較少，如果是基于實際網(wǎng)絡接口，那么管線機制所帶來的性能提升就更為顯著了。

1require'rubygems'
2require'redis'
3
4     def bench(descr)
5         start = Time.now
6         yield
7         puts "#{descr}#{Time.now-start} seconds"
8     end
9
10    def without_pipelining
11        r = Redis.new
1210000.times {
13            r.ping
14        }
15    end
16
17    def with_pipelining
18        r = Redis.new
19        r.pipelined {
2010000.times {
21                 r.ping
22            }
23        }
24    end
25
26    bench("without pipelining"){
27        without_pipelining
28     }
29    bench("with pipelining"){
30        with_pipelining
31     }
32    //without pipelining 1.185238 seconds
33    //with pipelining 0.250783 seconds