Redis 管道技術深度解析：原理、基準測試與腳本對比

Redis 管道技術深度解析：原理、基準測試與腳本對比

Redis 基於 TCP 的 Request/Response 協議，每條命令需經歷「發送 → 排隊 → 執行 → 返回」完整 RTT。管道化允許客戶端一次性發送多條命令、最後統一讀取回覆，大幅降低網絡開銷。本文從協議層面剖析原理、實戰基準測試、與 Lua 腳本的差異選型。

1. 協議層面的 RTT 問題

• 單命令流程：Client 發送 → 網絡傳輸 → Server 處理 → 網絡返回 → Client 讀取。
• RTT (Round Trip Time) 在跨機房/公網環境可達數十毫秒，嚴重限制吞吐。
• 例：RTT 250ms 時，理論 100k ops/s 僅能跑 4 ops/s。

2. 管道化原理

# 非管道：串行等待
Client: INCR X
Server: 1
Client: INCR X
Server: 2
...

# 管道：批量發送，一次性讀取回覆
Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4

• Server 強制隊列緩存回覆，消耗內存。
• 建議分批發送（如每批 10k 命令），平衡速度與內存。

3. 實戰基準測試

require 'redis'
def bench(desc)
  start = Time.now
  yield
  puts "#{desc} #{Time.now - start} 秒"
end

r = Redis.new
bench("without pipelining") { 10000.times { r.ping } }
bench("with pipelining")    { r.pipelined { 10000.times { r.ping } } }

結果 (Mac 本地回環)：

without pipelining: 1.185 秒
with pipelining:    0.251 秒
# 提升 ~4.7 倍

4. 管道 vs Lua 腳本：選型指南

5. 進階：管道中調用 EVALSHA

# 預先載入腳本獲取 SHA
SCRIPT LOAD "return redis.call('set', KEYS[1], ARGV[1])"
# 管道中批量調用
EVALSHA  1 key1 value1
EVALSHA  1 key2 value2
...

Redis 保證 SCRIPT LOAD 後 EVALSHA 不會因腳本未載入而失敗。

6. 最佳實踐總結

1. 高頻獨立寫入 → Pipeline（批量 1k-10k）。
2. 讀-算-寫強一致性 → Lua 腳本。
3. 混合場景 → Pipeline 批量發送 EVALSHA。
4. 監控 slowlog、INFO clients 觀察管道積壓情況。