Redis學習之管道機制

Redis · 發表 2018-11-06 10:37:29

摘要： Redis客戶端執行一條命令：傳送命令命令排隊執行命令返回結果其中傳送命令和返回結果可以稱為 Round Trip Time (RTT,往返時間)。在Redis中提供了批量操作命令，例如mget、mset等，有效地節約了RTT。但是大部分命令是...

Redis客戶端執行一條命令：

傳送命令
命令排隊
執行命令
返回結果

其中傳送命令和返回結果可以稱為 Round Trip Time (RTT,往返時間)。在Redis中提供了批量操作命令，例如mget、mset等，有效地節約了RTT。但是大部分命令是不支援批量操作的。

為此Redis提供了一個稱為 管道(Pipeline) 的機制將一組Redis命令進行組裝，通過一次 RTT 傳輸給 Redis,再將這些 Redis 命令的執行結果按順序傳遞給客戶端。即使用pipeline執行了n次命令，整個過程就只需要一次 RTT。

對Pipeline進行效能測試

我們使用 redis-benchmark 對Pipeline進行效能測試，該工具提供了 -P 的選項，此選項表示使用管道機制處理 n 條Redis請求，預設值為1。測試如下：

# 不使用管道執行get set 100000次請求
[root@iz2zeaf3cg1099kiidi06mz ~]# redis-benchmark -t get,set -q -n 100000
SET: 55710.31 requests per second
GET: 54914.88 requests per second
# 每次pipeline組織的命令個數 為 100
[root@iz2zeaf3cg1099kiidi06mz ~]# redis-benchmark -P 100 -t get,set -q -n 100000
SET: 1020408.19 requests per second
GET: 1176470.62 requests per second
# 每次pipeline組織的命令個數 為 10000
[root@iz2zeaf3cg1099kiidi06mz ~]# redis-benchmark -P 10000 -t get,set -q -n 100000
SET: 321543.41 requests per second
GET: 241545.89 requests per second
複製程式碼

從上面測試可以看出，使用pipeline的情況下 Redis 每秒處理的請求數遠大於不使用 pipeline的情況。

當然每次pipeline組織的命令個數不能沒有節制，否則一次組裝Pipeline資料量過大，一方面會增加客戶端等待時間，另一方面會造成一定的網路阻塞。

從上面的測試中也可以看出，如果一次pipeline組織的命令個數為 10000，但是它對應的QPS 卻小於一次pipeline命令個數為 100的。所以每次組織 Pipeline的命令個數不是越多越好，可以將一次包含大量命令的 Pipeline 拆分為多個較小的 Pipeline 來完成。

Pipeline關於RTT的說明

在官網上有一段這樣的描述:

大致意思就是：

Pipeline管道機制不單單是為了減少RTT的一種方式，它實際上大大提高了Redis的QPS。原因是，在沒有使用管道機制的情況下，從訪問資料結構和產生回覆的角度來看，為每個命令提供服務是非常便宜的。但是從底層套接字的角度來看，這是非常昂貴的，這涉及read（）和write（）系統呼叫，從使用者態切換到核心態，這種上下文切換開銷是巨大。而使用Pipeline的情況下，通常使用單個read（）系統呼叫讀取許多命令，然後使用單個write（）系統呼叫傳遞多個回覆,這樣就提高了QPS

批量命令與Pipeline對比

批量命令是原子的，Pipeline 是非原子的
批量命令是一個命令多個 key,Pipeline支援多個命令
批量命令是 Redis服務端實現的，而Pipeline需要服務端和客戶端共同實現

使用jedis執行 pipeline

public class JedisUtils {
private static final JedisUtils jedisutils = new JedisUtils();

public static JedisUtils getInstance() {
return jedisutils;
}

public JedisPool getPool(String ip, Integer port) {
JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
jedisPoolConfig.setMaxIdle(RedisConfig.MAX_IDLE);
jedisPoolConfig.setMaxTotal(RedisConfig.MAX_ACTIVE);
jedisPoolConfig.setMaxWaitMillis(RedisConfig.MAX_WAIT);
jedisPoolConfig.setTestOnBorrow(true);
jedisPoolConfig.setTestOnReturn(true);
JedisPool pool = new JedisPool(jedisPoolConfig, ip, port,RedisConfig.TIMEOUT,RedisConfig.PASSWORD);
return pool;
}

public Jedis getJedis(String ip, Integer port) {
Jedis jedis = null;
int count = 0;
while (jedis == null && count < RedisConfig.RETRY_NUM) {
try {
jedis = getInstance().getPool(ip, port).getResource();
} catch (Exception e) {
System.out.println("get redis failed");
}
count++;
}
return jedis;
}

public void closeJedis(Jedis jedis) {
if (jedis != null) {
jedis.close();
}
}

public static void main(String[] args) throws InterruptedException {
Jedis jedis = JedisUtils.getInstance().getJedis("127.0.0.1", 6379);
Pipeline pipeline = jedis.pipelined();
pipeline.set("hello", "world");
pipeline.incr("counter");
System.out.println("還沒執行命令");
Thread.sleep(100000);
System.out.println("這裡才開始執行");
pipeline.sync();
}
}

複製程式碼

在睡眠100s的時候檢視 Redis，可以看到此時在pipeline中的命令並沒有執行，命令都被放在一個佇列中等待執行:

127.0.0.1:6379> get hello
(nil)
127.0.0.1:6379> get counter
(nil)

複製程式碼

睡眠結束後，使用 pipeline.sync()完成此次pipeline物件的呼叫。

127.0.0.1:6379> get hello
"world"
127.0.0.1:6379> get counter
"1"
複製程式碼

必須要執行pipeline.sync()才能最終執行命令，當然可以使用 pipeline.syncANdReturnAll 回撥機制將pipeline響應命令進行返回。

參考資料 & 鳴謝

ofollow,noindex">Redis開發與運維
Using pipelining to speedup Redis queries