通常我们用redis做接口缓存后，查询接口的性能就能提升到ms级别；
但是redis是纯内存操作啊，总不至于要到ms吧，根据官方的 benchmark 单实例也是能抗 7w+ qps 也就是说单个redis 操作在redis-server上耗时大概是 0.014ms，那时间是消耗到哪里去了？
redis是 client-server 模型，client客户端将 command 通过tcp网络连接发送到 server服务端，服务端执行完 command 后将响应再通过 tcp 连接发送给client；
对于应用服务来说，我们所关注的性能其实是客户端时间，即前面的整个执行过程，虽然 redis-server 命令执行的非常快，但每次命令执行都需要在网络上走一遭，按照我们公司redis客户端中间件统计的rt，一次命令的执行平均是1ms 左右，那么网络耗时占比： 1-0.014 / 1 = 0.98(98%!!! ) 可见，大部分时间都耗在网络io上
所以，减少网络io次数就能大大提供 redis-client 感知的耗时，redis提供的 pipeline 功能，让我们可以提交一个命令后，不用等这个返回结果就可以继续执行下一个命令，也就是说，可以执行多个命令后，一次性获取所有结果； 这样就大大减少了在网络上的消耗
比如
Client: INCR X
Client: INCR X
Client: INCR X
Client: INCR X
Server: 1
Server: 2
Server: 3
Server: 4
除此之外，减少了网络读写次数的同时，也减少了 redis-server 内核态和用户态的上下文切换，进一步提高了性能
性能提升了多少？
redis官方声称pipeline可带来10倍的性能提升
官方图片
测试机Intel(R) Xeon(R) CPU E5520 @ 2.27GHz， 用pipeline比没用pipeline性能提升了将近7倍
// 用pipeline
$ ./redis-benchmark -r 1000000 -n 2000000 -t get,set,lpush,lpop -P 16 -q
SET: 552028.75 requests per second
GET: 707463.75 requests per second
LPUSH: 767459.75 requests per second
LPOP: 770119.38 requests per second
// 没用pipeline
SET: 122556.53 requests per second
GET: 123601.76 requests per second
LPUSH: 136752.14 requests per second
LPOP: 132424.03 requests per second
注意，使用pipeline的时候，多个命令的响应是缓存在server端的，所以在 pipeline 里一批命令的数量不要过多，以免服务端内存压力过大
类似的技术还有
- CSS Sprites，将很多小图标合并成一张图片
- jdbc batch api批量提交sql
参考：
