Redis的pipeline管道

使用场景

当有多个操作命令需要被迅速提交至服务器端，但用户并不依赖每个操作返回的响应结果，对结果响应也无需立即获得，那么管道就可以用来作为优化性能的批处理工具。性能提升的原因主要是减少了 TCP 连接中交互往返的开销。 由于Redis一般处理毫秒级请求，所以视pipeline内容数量可以减少tcp建立次数可以提升3~5倍性能但是在原生情况下无法支持redis-cluster
pipeline不是一个事务，不能保证里面的一组命令一起成功或者失败。

1.背景：

没有pipeline之前，一般的redis命令的执行过程都是：发送命令－〉命令排队－〉命令执行－〉返回结果。
多条命令的时候就会产生更多的网络开销

这个时候需要pipeline来解决这个问题：使用pipeline来打包执行N条命令，这样的话就只需简历一次网络连接，网络开销就少了

2. 使用pipeline和未使用pipeline的性能对比：

使用Pipeline执行速度与逐条执行要快，特别是客户端与服务端的网络延迟越大，性能体能越明显

3.原生批命令(mset, mget)与Pipeline对比

1) 原生批命令是原子性，pipeline是非原子性， (原子性概念:一个事务是一个不可分割的最小工作单位,要么都成功要么都失败。原子操作是指你的一个业务逻辑必须是不可拆分的. 处理一件事情要么都成功要么都失败，其实也引用了生物里概念，分子－〉原子，原子不可拆分) 2) 原生批命令一命令多个key, 但pipeline支持多命令（存在事务），非原子性 3) 原生批命令是服务端实现，而pipeline需要服务端与客户端共同完成

4. pipeline正确使用方式：

使用pipeline组装的命令个数不能太多，不然数据量过大，增加客户端的等待时间，还可能造成网络阻塞，可以将大量命令的拆分多个小的pipeline命令完成
如：有300个命令需要执行，可以拆分成每30个一个pipeline执行