[Redis]pipeline 和multi

1. Redis 管道 Pipeline

在某些场景下我们在一次操作中可能需要执行多个命令，而如果我们只是一个命令一个命令去执行则会浪费很多网络消耗时间，如果将命令一次性传输到 Redis中去再执行，则会减少很多开销时间。

需要注意的是 pipeline中的命令并不是原子性执行的，也就是说管道中的命令到达 Redis服务器的时候可能会被其他的命令穿插

1.1 为什么会出现Pipeline

Redis本身是基于Request/Response协议的，正常情况下，客户端发送一个命令，等待Redis应答，Redis在接收到命令，处理后应答。在这种情况下，如果同时需要执行大量的命令，那就是等待上一条命令应答后再执行，这中间不仅仅多了RTT（Round Time Trip），而且还频繁的调用系统IO，发送网络请求。如下图。
为了提升效率，这时候Pipeline出现了，它允许客户端可以一次发送多条命令，而不等待上一条命令执行的结果，这和网络的Nagel算法有点像（TCP_NODELAY选项）。不仅减少了RTT，同时也减少了IO调用次数（IO调用涉及到用户态到内核态之间的切换）。
客户端这边首先将执行的命令写入到缓冲中，最后再一次性发送Redis。但是有一种情况就是，缓冲区的大小是有限制的，比如Jedis，限制为8192，超过了，则刷缓存，发送到Redis，但是不去处理Redis的应答

1.2 实现原理

要支持Pipeline，其实既要服务端的支持，也要客户端支持。对于服务端来说，所需要的是能够处理一个客户端通过同一个TCP连接发来的多个命令，可以理解为，这里将多个命令切分，和处理单个命令一样（之前老生常谈的黏包现象），
Redis就是这样处理的。

而客户端，则是要将多个命令缓存起来，缓冲区满了就发送，然后再写缓冲，最后才处理Redis的应答，如Jedis。

1.3 从哪个方面提升性能

正如上面所说的，一个是RTT，节省往返时间，但是另一个原因也很重要，就是IO系统调用。一个read系统调用，需要从用户态，切换到内核态。

1.4 注意点

Redis的Pipeline和Transaction不同，Transaction会存储客户端的命令，最后一次性执行，而Pipeline则是处理一条，响应一条，但是这里却有一点，就是客户端会并不会调用read去读取socket里面的缓冲数据，这也就造就了，
如果Redis应答的数据填满了该接收缓冲（SO_RECVBUF），那么客户端会通过ACK，WIN=0（接收窗口）来控制服务端不能再发送数据，那样子，数据就会缓冲在Redis的客户端应答列表里面。所以需要注意控制Pipeline的大小。

2. Codis Pipeline

在一般情况下，都会在Redis前面使用一个代理，来作负载以及高可用。这里在公司里面使用的是Codis，以Codis 3.2版本为例（3.2版本是支持Pipeline的）。
Codis在接收到客户端请求后，首先根据Key来计算出一个hash，映射到对应slots，然后转发请求到slots对应的Redis。在这过程中，一个客户端的多个请求，有可能会对应多个Redis，这个时候就需要保证请求的有序性（不能乱序），
Codis采用了一个Tasks队列，将请求依次放入队列，然后loopWriter从里面取，如果Task请求没有应答，则等待（这里和Java的Future是类似的）。内部BackenRedis是通过channel来进行通信的，dispatcher将Request通过channel发送到BackenRedis，然后BackenRedis处理完该请求，则将值填充到该Request里面。最后loopWriter等待到了值，则返回给客户端。如下图所示：

3. redis中multi和pipeline区别以及效率(推荐使用pipeline)

pipeline 只是把多个redis指令一起发出去，redis并没有保证这些指定的执行是原子的；multi相当于一个redis的transaction的，保证整个操作的原子性，避免由于中途出错而导致最后产生的数据不一致。通过测试得知，pipeline方式执行效率要比其他方式高10倍左右的速度，启用multi写入要比没有开启慢一点。

multi  watch  exec  discard unwatch  主要针对原子性，性能会有所下降

3.1 redis multi命令

redis multi命令

3.2 流程

标记一个事务块的开始。 事务块内的多条命令会按照先后顺序被放进一个队列当中，最后由 EXEC 命令原子性(atomic)地执行。

而pipeline：客户端将执行的命令写入到缓冲中，最后由exec命令一次性发送给redis执行返回。

1.muti  2.执行命令 3.exec

4. 其他

4.1 RTT是什么？

 RTT(Round-Trip Time)，往返时延。在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。

4.2 黏包现象

沾包现象

只有TCP有粘包现象，UDP永远不会粘包

粘包不一定会发生

客户端服务端都有可能沾包。

应用程序所看到的数据是一个整体，或说是一个流（stream），一条消息有多少字节对应用程序是不可见的，因此TCP协议是面向流的协议

（因为TCP是流式协议，不知道啥时候开始，啥时候结束）

而UDP是面向消息的协议，每个UDP段都是一条消息，应用程序必须以消息为单位提取数据，不能一次提取任意字节的数据，这一点和TCP是很不同的。

可以认为对方一次性write/send的数据为一个消息，需要明白的是当对方send一条信息的时候，无论底层怎样分段分片，TCP协议层会把构成整条消息的数据段排序完成后才呈现在内核缓冲区。

粘包问题主要还是因为接收方不知道消息之间的界限，不知道一次性提取多少字节的数据所造成的。

解决粘包的方法：问题的根源在于，接收端不知道发送端将要传送的字节流的长度，所以解决粘包的方法就是围绕，如何让发送端在发送数据前，把自己将要发送的字节流总大小让接收端知晓，然后接收端来一个死循环接收完所有数据

发生粘包的两种情况：发送端需要等缓冲区满才发送出去，造成粘包（发送数据时间间隔很短，数据很小，会当做一个包发出去，产生粘包）

接收方不及时接收缓冲区的包，造成多个包接收（客户端发送了一段数据，服务端只收了一小部分，服务端下次再收的时候还是从缓冲区拿上次遗留的数据，产生粘包） 

 

 

转自：Redis Pipeline原理分析