Redis-消息队列的三种方案（List、Streams，安利10个让你爽到爆的IDEA必备插件

我们都知道消息模型有两种

• 点对点：Point-to-Point(P2P)
• 发布订阅：Publish/Subscribe(Pub/Sub)

List 实现方式其实就是点对点的模式，下边我们再看下 Redis 的发布订阅模式（消息多播），这才是“根正苗红”的 Redis MQ

"发布/订阅"模式同样可以实现进程间的消息传递，其原理如下:

"发布/订阅"模式包含两种角色，分别是发布者和订阅者。订阅者可以订阅一个或者多个频道(channel)，而发布者可以向指定的频道(channel)发送消息，所有订阅此频道的订阅者都会收到此消息。

Redis 通过 PUBLISH 、 SUBSCRIBE 等命令实现了订阅与发布模式， 这个功能提供两种信息机制， 分别是订阅/发布到频道和订阅/发布到模式。

这个 频道 和 模式 有什么区别呢？

频道我们可以先理解为是个 Redis 的 key 值，而模式，可以理解为是一个类似正则匹配的 Key，只是个可以匹配给定模式的频道。这样就不需要显式地去订阅多个名称了，可以通过模式订阅这种方式，一次性关注多个频道。

我们启动三个 Redis 客户端看下效果：

先启动两个客户端订阅（subscribe） 名字叫 framework 的频道，然后第三个客户端往 framework 发消息，可以看到前两个客户端都会接收到对应的消息：

我们可以看到订阅的客户端每次可以收到一个 3 个参数的消息，分别为：

• 消息的种类
• 始发频道的名称
• 实际的消息

再来看下订阅符合给定模式的频道，这回订阅的命令是 PSUBSCRIBE

我们往 java.framework 这个频道发送了一条消息，不止订阅了该频道的 Consumer1 和 Consumer2 可以接收到消息，订阅了模式 java.* 的 Consumer3 和 Consumer4 也可以接收到消息。

Pub/Sub 常用命令：

2.3 Streams 实现消息队列

Redis 发布订阅 (pub/sub) 有个缺点就是消息无法持久化，如果出现网络断开、Redis 宕机等，消息就会被丢弃。而且也没有 Ack 机制来保证数据的可靠性，假设一个消费者都没有，那消息就直接被丢弃了。

后来 Redis 的父亲 Antirez，又单独开启了一个叫 Disque 的项目来完善这些问题，但是没有做起来，github 的更新也定格在了 5 年前，所以我们就不讨论了。

Redis 5.0 版本新增了一个更强大的数据结构——Stream。它提供了消息的持久化和主备复制功能，可以让任何客户端访问任何时刻的数据，并且能记住每一个客户端的访问位置，还能保证消息不丢失。

它就像是个仅追加内容的消息链表，把所有加入的消息都串起来，每个消息都有一个唯一的 ID 和对应的内容。而且消息是持久化的。

每个 Stream 都有唯一的名称，它就是 Redis 的 key，在我们首次使用 xadd 指令追加消息时自动创建。

Streams 是 Redis 专门为消息队列设计的数据类型，所