Redis学习之管道机制

时间 2019-11-16

标签 redis 学习管道机制栏目 Redis 繁體版

原文原文链接

原文博客地址： pjmike的博客java

前言

如下是对 Redis管道机制的一个学习记录git

Pipeline简介

Redis客户端执行一条命令：github

发送命令
命令排队
执行命令
返回结果

其中发送命令和返回结果能够称为 Round Trip Time (RTT,往返时间)。在Redis中提供了批量操做命令，例如mget、mset等，有效地节约了RTT。可是大部分命令是不支持批量操做的。redis

为此Redis提供了一个称为管道(Pipeline) 的机制将一组Redis命令进行组装，经过一次 RTT 传输给 Redis,再将这些 Redis 命令的执行结果按顺序传递给客户端。即便用pipeline执行了n次命令，整个过程就只须要一次 RTT。bash

对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响应命令进行返回。