redis pipeline和mget、mset
为什么需要pipeline？
因为redis本身是基于request/response模式，每一个命令都需要等待上一个命令响应后进行处理，中间需要经过RTT（Round Time Trip，往返延时，表示发送端从发送数据开始，到发送端收到来自接收端的确认，所需要的时间。），并且需要频繁调用系统IO。
pipeline应用场景
多个命令需要被及时提交，且这些命令的响应结果没有相互依赖。
好处
可较大提升性能
需要注意
- 不要和常规命令client共用一个链接，因为pipeline是独占连接的，如果管道内命令太多，可能会造成请求超时
- 可发送命令数量受到客户端缓冲区大小限制，如超过限制，则flush到redis
- redis server存在query buffer限制，默认是1GB，如果超过这个值，客户端会被强制断掉
- redis server存在output buffer限制，受到maxmemory配置限制
- 要实现pipeline，同时需要服务器端和客户端的支持
- redis cluster不建议使用pipeline，容易产生max redirect错误
- twem proxy可以支持pipeline
局限性
当某个命令的执行需要依赖前一个命令的返回结果时，无法使用pipeline。
mget和mset
mset a “a1” b “b” c “c1” mget a b c
mget和mset命令也是为了减少网络连接和传输时间所设置的，其本质和pipeline的应用区别不大，但是在特定场景下只能用pipeline实现，例如：
get a
set b ‘1’
incr b
pipeline适合执行这种连续，且无相关性的命令。
根据大家的测试反馈，在key数量非常多的时候，mget命令性能可能优于pipeline。（未做实测考证）