共计 3285 个字符，预计需要花费 9 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 Redis 中管道机制的示例分析，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
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 中管道机制的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
