持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第26天，点击查看活动详情

管道

通常执行一条指令需要以下三个步骤：

1、客户端向Redis发送请求，阻塞等待Redis应答

2、Redis收到请求，执行命令

3、客户端收到响应信息

其中1、3成为一次RTT。

没有管道时如果同时执行大量命令，那么当前命令需要等待上一条命令应答完成后才会执行，这个过程不仅需要多次RTT，而且频繁调用系统IO，发送网络请求。

管道的诞生允许一次性发送多条指令，极大地减少了RTT和IO的调用次数（IO调用涉及到用户态到内核态的切换）

原理

要支持 pipeline，除了需要 Redis 服务端支持，也需要各个客户端的支持，例如 jedis 就对 pipeline 提供了很好的支持。对于服务端来说，所需要的就是能够处理客户端通过一个 TCP 连接发送的多个命令，对多个命令进行排队，执行。而客户端，则需要将多个命令缓存起来，待缓冲区满了就发送，同时还需要处理 Redis 的应答。

pipeline 不是什么新鲜技术，很多技术都使用过，它能提供性能的核心就在于：它能将一组 Redis 命令进行组装，通过一次 RTT 传输给 Redis，同时再将这组命令的执行结果按照顺序返回给客户端。将原来一组命令多次 RTT 以及 IO 交互变成了一组 RTT 和 IO 交互，大大减少了网络传输时间和 IO 调用的时间。

在使用 pipeline 的过程中需要控制其中命令的大小，如果一次组装的命令过多，则会增加造成一定的网络阻塞，也会增加客户端的等待时间。

发布订阅

Redis 提供了基于“发布/订阅”模式的消息机制，发送者（publish）发布消息，订阅者（subscribe）接收消息，两者之间不需要进行直接通信，他们之间通过频道进行消息传递。发布者向指定的频道（channel）发布消息，订阅了该频道的订阅者都可以接收到该消息。

例子

订阅者

127.0.0.1:6379> subscribe channel1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel1"
3) (integer) 1

发布者

127.0.0.1:6379> publish channel1 "hello redis"
(integer) 1
127.0.0.1:6379> 
​

发布者发布信息以后订阅者接收信息

127.0.0.1:6379> subscribe channel1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel1"
3) (integer) 1
1) "message"
2) "channel1"
3) "hello redis"

应用场景：QQ 消息，别人发消息需要实时查看，也可查看历史数据。