redis 管道pipeline

为何有这个pipeline？

Redis 的性能高是一大优势，但是在通信层面，由于是 客户端 服务端 通过TCP 通信，肯定是有一定延迟呢。
你会发现 通信 在执行命令的过程 包括四个部分：
发送命令－〉命令排队－〉命令执行－〉返回结果
从第一个到第四个消耗的时间总和称为 Round Trip Time(简称RTT，往返时间)。当客户端与服务器存在网络延迟时，RTT就可能会很大，这样就会导致性能问题。
那有延迟，redis要是不发挥出优势怎么能行？于是开始想。
说到底就是为了能够降低RTT 这个时间，怎么办呢，就想办法
通信次数下手，通信一次 一次时间 通信10次 时间 *10 那不拉跨了，所以呢
把命令 批量式的进行 通信，就是尽可能 一次把 这10命令 打包传输。等一次结果就行.

pipeline通过减少客户端与redis的通信次数来实现降低RTT

原来: 发送A等待A 然后发送B等待B
现在: 发送A/B 然后 等待 结果AB

怎么利用管道？

1.这个技术不是redis技术发明的，已经有这个技术，只是作用在redis上
2.在没有因果关系的命令可以打包一次往返IO，如果有关系就别打包，因为结果只有一次，需要因果关系结果需要事先作用。
3.管道原理式队列 先进先出 所以可以保证顺序性
4.不能无限制打包 打包太多内存也会臃肿
5.Pipeline每次只能作用在一个Redis节点。

适用场景

有些系统可能对可靠性要求很高，每次操作都需要立马知道这次操作是否成功，是否数据已经写进redis了，那这种场景就不适合。
有的系统，可能是批量的将数据写入redis，允许一定比例的写入失败，那么这种场景就可以使用了，比如10000条一下进入redis，可能失败了2条无所谓，后期有补偿机制就行了，比如短信群发这种场景，如果一下群发10000条，按照第一种模式去实现，那这个请求过来，要很久才能给客户端响应，这个延迟就太长了，如果客户端请求设置了超时时间5秒，那肯定就抛出异常了，而且本身群发短信要求实时性也没那么高，这时候用pipeline最好了。

原生批量命令有啥区别

redis 原生有批量命令 mset 不能用吗
1.原生命令 还是一个命令 原子性 只是 内容多了 层面还是命令，管道是多个命令，层面是管道，也就是说 管道里 也能塞你的 mset
2.mset命令只是 服务端处理命令内容 ，不作用客户端。 管道是两头管

原生批量命令是原子性，Pipeline是非原子性的。
原生批量命令是一个命令对应多个key，Pipeline支持多个命令。
原生批量命令是Redis服务端支持实现的，而Pipeline需要服务端与客户端的共同实现。