redispipeline使用方法（redisson pipeline）

本篇文章给大家谈谈redispipeline使用方法，以及redisson pipeline对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Redis pipeline以及批量优化
• 2、Redis的pipeline
• 3、redis cluster模式 使用pipeline批量操作
• 4、关于redis批量获取数据pipeline
• 5、(15)redis Pipeline详解
• 6、redis pipeline 是做什么用的

Redis pipeline以及批量优化

Redis基于Request/Response 协议。通常情滚租况下一次请求的步骤如下

1 客户端通过tcp 协议发送指令到服务端，等待redis服务端返回结果

2 redis服务端执行命令，返回响应到客户端。

客户端发送请求到接受到服务端返回的响应被称为一次RTT(Round Trip Time). 在不考虑redis 服务端处理耗时的情况下，数据传输的耗时是最要的开销。且redis client 必须等待上一次响应结果才能发送下一个指令，会长时间处于阻塞的状态。

为解决提升reids服务端的吞吐量，redis提供了如下几种解决方案。

redis实现了HMGET/HMSET/MSET/MGET等一系列批量指令。区别与普通指大旦兆令如GET， MGET可以一次性发送key数组，然后redis服务端一次性返回结果数组。

很明显这种方式可以使用一次RTT处理完多个指令。这种方式的在性能上是最好的，缺点在于

1. 指令类型必须一致，批量指令依赖于Redis的实现，有些指令如setbit 没有批量实现的，就无法使用这种方案。

2. 不能混合指令发送，需要发送的指令必须在一次请求中确定。灵活性比pipeline差。

pipelining 是Request/迟敬Reponse协议的一种实现方式。客户端连续发送请求，而不用等待上一次的response返回。最终通过一次读取之前所有的Response。Redis服务支持这种实现方式。

我们通过redis-benchmark对比下普通cs模型和pipleline的性能。

从上面测试结果可以看出pipleline的性能远高于普通的请求方式。

1. pipeline的RTT交互次数，从而减少延迟，在网络延迟比较大的环境下。吞吐量提高会特别明显。

2. redis客户端/服务端减少了sys_call调用次数，减少了用户态到内核态的切换开销。

3. redis客户端发送无需等待上一次response请求结果，减少了阻塞时间。

Pipelining is not just a way in order to reduce the latency cost due to the round trip time, it actually improves by a huge amount the total operations you can perform per second in a given Redis server. This is the result of the fact that, without using pipelining, serving each command is very cheap from the point of view of accessing the data structures and producing the reply, but it is very costly from the point of view of doing the socket I/O. This involves calling the read() and write() syscall, that means going from user land to kernel land. The context switch is a huge speed penalty.

Redis-Bloomfilter在1.0.0版本时，操作redis是基于标准的request/response模式， 但是Bloomfilter 在精度和预计插入数量大的情况，需要做多次hash操作。这样一次bloomfilter操作需要进行几十次redis setbit/getbit。这种情况下会严重影响Bloomfilter的吞吐量。由于setbit/getbit 不支持批量操作，所以采用pipeline来优化redis的性能开销。具体可以参考 的实现方式。 另外增加对于基于redistemplate的支持。

[img]

Redis的pipeline

pipeline：可将命令合并为一次IO，可滑喊降低延迟。

本机测试redis-pipeline

测试结果：

在本机测试中旁搭，pipeline性能运让拿比普通set高出很多

redis cluster模式 使用pipeline批量操作

1.将需要操作的key计算出对应的solt，得到hostAndPort，分组存放在一个map中。(MapJedisPool, ListString node2keys = new HashMap卖脊中闭渗())

2.通过得到的JedisPool,分开使态扮用jedis的pipeline执行

3.将返回数据组装返回

1.先得到一个JedisCluster

2.实现key的分组

调用示例

关于redis批量获取数据pipeline

Redis是建立在TCP协议上的CS架构,客户端client对redis server采取请求响应的方式交互.每次交互会有网络延迟,大约30ms.

假设有这样一个场景,redis中存储上千个key值,获取每个key对应field的value,那么要向redis请求上千次 hget(key, field),获取响应也是对应的次数.如果能一次性将所有请求提交给server端,执行完成后答派袭批量获取响应,只需向redis请求1次,性能获大幅提升

没有用pipeline之前,基本上获取所有数据需要90多s,现在只需0.3s,性能提升清晰可见

实现以下场景:定时任务每隔1s执行任务函数,但是任务函数执行完成的时间比1s要长,此时启动定时任务要清兄加上两个参数,否则会报错

可允许的实例个数,如果没有设置,则默认为1,表示id相同的任务实例数

像上面的例子中,会报skipped: maximum number of running instances reached (1)的错误,意思APScheduler试图重新执行作业，但前一个仍在运行。

这个参数可以理解为任务羡大的超时容错配置，给executor 一个超时时间，这个时间范围内要是该跑的还没跑完，就别再跑了

像上面的例子中,会报Run time of job …… next run at: ……)” was missed by的错误

(15)redis Pipeline详解

redis客户端执稿让行命令4个过程： 发送命令－〉命令排队－〉命令执行－〉返回结果

过程称为 Round trip time (简称RTT, 往返时间)，mget mset有效节约RTT，但大部分命令（如hgetall，并没有mhgetall）不支持批量操作，需要 消耗N次RTT ，pipeline解决

比逐条执键宽局行要快，特别是客户端与服务端的 网络延迟越大，体能越明显

原生批命令： 原子性 ，            pipeline： 非原子性

原生批命令： 一命令多个key    pipeline： 支持多命令（存在事务）

原生批命令： 服务端 实现，     pipeline：服务端与客户端 共同完成

pipeline组装命令不能太多，不然数据量过大，增加客户端的等待时间，造成网络阻塞，可将 大量命令的拆分多个小pipeline命令：

redis提供 mset 、 mget 方法，但没提供 mdel 方法，如想实现，可借助pipeline

mset： 同时设置一个或多个 key-value 对。redis 127.0.0.1:6379 MSET key1 value1 key2 value2 .. keyN valueN

1）获取jedis对象 （一般从连接池中获取）

2） 获取jedis对象 的pipeline对象

3）添加、执行指令

用pipeline提交所有操作并返回执行结果：

为了保证pipeline原子性，redis提供了简单的事务。

1、redis的简单事务 ：放multi和exec命令之间，multi代表事务开始，exec代表事务结束

2、停止事务discard：

3、命令错误，语法不正确，导致 事务不能正常结束

4、运行错误，语法正确，但 类型错误，事务可以正常结束

5、watch命令：用watch后， multi失效，事务失效

WATCH机制： 事务EXEC执行时，Redis检查被WATCH的key，只有被WATCH的key从 WATCH起始时至今没有发生过变更，EXEC才会被执行 ，变化则失败。

小结：redis提供简单事务，不支巧耐持事务回滚

redis pipeline 是做什么用的

Redis本身是一个cs模式的tcp server, client可以通过指锋一个socket连续发起多个请求命令。 每个请求命令发出后client通常会阻塞并等待redis服务端处理，redis服务端处理完后将结果返回给client。

redis的pipeline(管道)功能在命令行中没有，但redis是支持pipeline的，而且在各个语言版的client中都有相应的实现。 由于网络开销延迟，即算redis server端有很强的处理能力，也由于收到的client消息少，而造成吞吐量小。当client 使用pipelining 发送命令时，redis server必须部分请求放到队列中（使用内存）执行完毕后一次性发送结果；如果发送的命名很多的话，建议对返回的结果加标签，当然这也会增加使用的内存；

Pipeline在某些场景下非常有用，比如有多个command需要被“及时的”提交，而且他们对相应结果没有互相依赖，而且对结果响应也无需立即获得，那么pipeline就可以充当这种“批处理”的工具；而察虚且在一定程度上，可以较大的提升性能,性能提升的原因主要是TCP链接中较少了“交互往返”的时间。不过在编码时请注意，pipeline期间将“独占”链接，此期间将不能进行非“管道”类型的其他操作，直到pipeline关闭；如果你的pipeline的指令集很庞大，为了不干扰链接中的其他操作，你可以为pipeline操作新建Client链接，让pipeline和其他正常操作分离在2个client中。不过pipeline事实上所能容忍的操作个数，和socket-output缓冲区大小/返回结果的数据尺寸都有很大唯没晌的关系；同时也意味着每个redis-server同时所能支撑的pipeline链接的个数，也是有限的，这将受限于server的物理内存或网络接口的缓冲能力。

关于redispipeline使用方法和redisson pipeline的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。