七、Redis消息发布与管道

Redis的订阅

消息多播

​ 消息多播允许生产者只产生一次消息，由中间件负责将消息复制到多个消息队列，每个消息队列由相应的消费组进行消费，他是分布式系统常用的一种解耦方式

基本指令

subscribe  channel[主题名] ....
publish channel[主题名] messgae【消息
12

使用场景：
1、实时消息系统！
2、事实聊天！（频道当做聊天室，将信息回显给所有人即可！）
3、订阅，关注系统都是可以的！
稍微复杂的场景我们就会使用 消息中间件 MQ （）

※：redis5.0中新增了stream数据结构，支持消息队列的持久化

Redis管道

当我们使用客户端对redis进行一次操作的时候，中间的过程是什么样的？

当我们使用客户端对redis进行多次操作的时候，中间的过程是什么样的？

​ 进行一次操作，消耗一个网络来回，多个操作消耗多个网络来回，是不是有点耗费时间？

我们可以将过程转换成下图

过程优化之后如下图

​ 两个连续的写操作和两个连续的读操作，只需要花费一次网络来回，这就是管道的本质，客户端通过改变指令的顺序就可以大幅节省IO时间

管道压力测试指令 -P 表示管道内并行的请求数量

redis-benchmark -t set -P 200 -q

管道的本质

1. 客户端调用write将消息写到操作系统内核为套接字分配的发送缓冲中sendbuffer
2. 系统内核将缓冲区的内容发送到网卡，网卡硬件将数据通过路由送到服务器的网卡
3. 服务器网卡将数据放到内核为套接字分配的接收缓冲中recivebuffer
4. 服务器调用read从接收缓冲中取出消息进行处理
5. 服务器调用write将响应内容发送到sendbffer中
6. 服务器内核将缓冲区的内容通过路由发送到客户端的网卡中
7. 客户端内核将网卡中的数据放到接收缓冲中recivebuffer
8. 客户端调用read从缓冲中读取数据

​ 我们开始以为write方法必须到数据发送给对方后才能返回，其实只要将数据放到缓冲区中就可以返回，如果缓冲区满了，则需要等待缓冲区空闲，read方法只有检测不到缓存中有数据才会一直在那等待