Redis學習之管道機制

原文博客地址： pjmike的博客

前言

如下是對 Redis管道機制的一個學習記錄

Pipeline簡介

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響應命令進行返回。

參考資料 & 鳴謝

• Redis開發與運維
• Using pipelining to speedup Redis queries