pipeline 管道
一般情况下，Redis Client端发出一个请求后，通常会阻塞并等待Redis服务端处理，Redis服务端处理完后请求命令后会将结果通过响应报文返回给Client。
通过pipeline方式当有大批量的操作时候，我们可以节省很多原来浪费在网络延迟的时间，需要注意到是用pipeline方式打包命令发送，
redis必须在处理完所有命令前先缓存起所有命令的处理结果。打包的命令越多，缓存消耗内存也越多。所以并不是打包的命令越多越好。
Redis Pipelining可以一次发送多个命令，并按顺序执行、返回结果，节省RTT(Round Trip Time)。
pipeline使用建议
Pipeline虽然好用，但是每次Pipeline组装的命令个数不能没有节制，否则一次组装Pipeline数据量过大，一方面会增加客户端的等待时间，另一方面会造成一定的网络阻塞，可以将一次包含大量命令的Pipeline拆分成多次较小的Pipeline来完成
原生批量命令与Pipeline对比
可以使用Pipeline模拟出批量操作的效果，但是在使用时要注意它与原生批量命令的区别，具体包含以下几点：
-- 原生批量命令是原子的，Pipeline是非原子的。
-- 原生批量命令是一个命令对应多个key，Pipeline支持多个命令。
-- 原生批量命令是Redis服务端支持实现的，而Pipeline需要服务端和客户端的共同实现。
Transaction
同一个redis client发送命令MULTI表示准备执行事务，同时发送的命令会在server端排队，期间不影响其他客户端发送命令，服务器不会阻塞，该客户端发送EXEC，服务器端把执行完的结果一起发送给客户端。如果同一个Transaction中的命令太多，服务器会阻塞。（也就是在事务执行期间，服务器不会执行其他命令）
pipeline、Transaction对比
pipeline关注的是RTT时间，而transaction关注的是一致性
-- pipeline: 一次请求，服务端顺序执行，一次返回。
-- transaction: 多次请求（MULTI命令＋其他n个命令＋EXEC命令，所以至少是2次请求），服务端顺序执行，一次返回。
-- 集群模式下，使用pipeline时，slot必须是对的，不然服务端会返回redirecred to slot xxx的错误；不建议使用Transaction，因为假设一个Transaction中的命令即在Master A上执行，也在Master B执行，A成功了，B因为某种原因失败了，这样数据就不一致了，这个有点类似于分布式事务，无法保证绝对一致性。
