一、請求應答協議和RTT：
Redis是一種典型的基于C/S模型的TCP服務器。在客戶端與服務器的通訊過程中，通常都是客戶端率先發起請求，服務器在接收到請求后執行相應的任務，最后再將獲取的數據或處理結果以應答的方式發送給客戶端。在此過程中，客戶端都會以阻塞的方式等待服務器返回的結果。見如下命令序列：
復制代碼 代碼如下:
Client: INCR X
Server: 1
Client: INCR X
Server: 2
Client: INCR X
Server: 3
Client: INCR X
Server: 4
在每一對請求與應答的過程中，我們都不得不承受網絡傳輸所帶來的額外開銷。我們通常將這種開銷稱為RTT(Round Trip Time)。現在我們假設每一次請求與應答的RTT為250毫秒，而我們的服務器可以在一秒內處理100k的數據，可結果則是我們的服務器每秒至多處理4條請求。要想解決這一性能問題，我們該如何進行優化呢？
二、管線(pipelining)：
Redis在很早的版本中就已經提供了對命令管線的支持。在給出具體解釋之前，我們先將上面的同步應答方式的例子改造為基于命令管線的異步應答方式，這樣可以讓大家有一個更好的感性認識。
復制代碼 代碼如下:
Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4
從以上示例可以看出，客戶端在發送命令之后，不用立刻等待來自服務器的應答，而是可以繼續發送后面的命令。在命令發送完畢后，再一次性的讀取之前所有命令的應答。這樣便節省了同步方式中RTT的開銷。
最后需要說明的是，如果Redis服務器發現客戶端的請求是基于管線的，那么服務器端在接受到請求并處理之后，會將每條命令的應答數據存入隊列，之后再發送到客戶端。
三、Benchmark：
以下是來自Redis官網的測試用例和測試結果。需要說明的是，該測試是基于loopback(127.0.0.1)的，因此RTT所占用的時間相對較少，如果是基于實際網絡接口，那么管線機制所帶來的性能提升就更為顯著了。
復制代碼 代碼如下:
require 'rubygems'
require 'redis'
def bench(descr)
start = Time.now
yield
puts "#{descr} #{Time.now-start} seconds"
end
def without_pipelining
r = Redis.new
10000.times {
r.ping
}
end
def with_pipelining
r = Redis.new
r.pipelined {
10000.times {
r.ping
}
}
end
bench("without pipelining") {
without_pipelining
}
bench("with pipelining") {
with_pipelining
}
//without pipelining 1.185238 seconds
//with pipelining 0.250783 seconds
您可能感興趣的文章:- Redis教程(十四)：內存優化介紹
- Redis教程(十五)：C語言連接操作代碼實例
- Redis的LRU機制介紹
- Redis數據庫的應用場景介紹
- Redis的Python客戶端redis-py安裝使用說明文檔
- Redis list 類型學習筆記與總結
- Redis中實現查找某個值的范圍
- Redis禁用命令、危險命令及規避方法
- 簡介Lua腳本與Redis數據庫的結合使用
- 從MySQL到Redis的簡單數據庫遷移方法
- 在Node.js應用中讀寫Redis數據庫的簡單方法
- Redis sort 排序命令詳解
- 圖文介紹PHP添加Redis模塊及連接
- 詳解Redis中的雙鏈表結構
- Redis中的動態字符串學習教程
- 利用Redis實現SQL伸縮的方法
