Redis Pipeline管道命令使用

概述 目录

1.Redis单条命令使用场景
2.Redis单条命令执行耗时
3.Redis连接池
4.Redis Pipeline管道命令的使用
5.总结

本文源码地址：https://github.com/online-demo/redis-pipeline.git

第1节 Redis单条命令使用场景

Redis客户端连接到Redis服务端执行一条命令需要经历的步骤如下：

上过程称为Round Trip Time（RTT，往返时间），mget和mset命令节约了RTT，但是大部分指令不支持批量操作。

Redis通过TCP来对外提供服务，Client通过Socket连接发起请求，每个请求在命令发出后会阻塞等待Redis服务器进行处理，处理完毕后将结果返回给client。

Redis的Client和Server是采用一问一答的形式进行通信，请求一次给一次响应。而这个过程在排除掉Redis服务本身做复杂操作时的耗时的话，可以看到最耗时的就是这个网络传输过程。每一个命令都对应了发送、接收两个网络传输，假如一个流程需要0.1秒，那么1秒最多只能处理10个请求，将严重制约Redis的性能。

在很多场景下，我们要完成一个业务，可能会对redis做连续的多个操作，譬如库存减一、订单加一、余额扣减等等，这有很多个步骤是需要依次连续执行的。

第2节 Redis单条命令执行耗时

正常情况下，Redis单条命令的执行时间是毫秒级别的。大部分的Redis命令可以在2ms内返回。因此Redis的执行时间非常快的。但是在高并发场景下，同时操作大量的Redis KEY可能并不能满足高性能的要求。

假设有一个请求，需要批量校验某个用户能否参与现有的10000个返利活动，用户能否参与返利活动使用Redis KEY记录和存储的。正常情况下，需要使用for循环遍历每个活动，校验用户能否参加每一个活动。

假设每个Redis命令执行时间为1ms，校验10000个活动需要的时间=10000 * 1ms = 10s，即一个接口需要10s才能响应结果，这显然不能满足现实的需求。

第3节 Redis连接池

除了第2点中描述的接口响应时间较慢的问题外，还有一个问题：一个接口中进行多次Redis KEY的操作，造成Redis连接池的连接长时间得不到释放，因此可能会造成连接池中的连接很快就被前几个线程所占有，迟迟得不到释放，并发量较高时，大量线程得不到连接池中的连接而造成大量线程等待超时

第4节Redis Pipeline管道命令的使用

Pipeline命令原理如下图所示。

Redis是一种基于客户端-服务端模型以及请求/响应协议的TCP服务。这意味着通常情况下一个请求会遵循以下步骤：

1.客户端向服务端发送一个查询请求，并监听Socket返回，通常是以阻塞模式，等待服务端响应。
2.服务端处理命令，并将结果返回给客户端。

Redis管道技术可以在服务端未响应时，客户端可以继续向服务端发送请求，并最终一次性读取所有服务端的响应。这样可以最大限度的利用Redis的高性能并节省不必要的网络IO开销。

不使用Pipeline命令执行单条set命令100000次

/**
 * 不使用Pipeline命令
 * @param count 操作的命令个数
 * @return 执行时间
 */
@GetMapping("redis/no/pipeline/{count}")
public String testWithNoPipeline(@PathVariable("count") String count) {
   
  // 开始时间
  long start = System.currentTimeMillis();
  // 参数校验
  if (StringUtils.isEmpty(count)) {