redis的 stream数据类型实现 消息队列？

redis的消息队列可以通过：

• PUB/SUB，订阅/发布模式：缺点是发布订阅模式是无法持久化的，如果出现网络断开、Redis 宕机等，消息就会被丢弃；

• 使用列表 List 实现：支持了持久化，但是不支持多播，分组消费等。

redis 5.0 之后，新增的 Stream数据类型实现的 消息队列可以 持久化，支持多播、分组消费。

Stream 数据类型的结构

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

• Consumer Group ：消费组，使用 XGROUP CREATE 命令创建，一个消费组有多个消费者(Consumer), 这些消费者之间是竞争关系（即一个消息，只能被这个消息组中的一个消费者使用）。
• last_delivered_id ：游标，每个消费组会有个游标 last_delivered_id。它表示该消费组中当前已经处理完成的消息ID。用于记录消费者的处理进度，当消费者重新启动或恢复时，可以从这个位置继续处理未处理的消息。
• pending_ids：消费者(Consumer)的状态变量，作用是维护消费者的未确认的 id。 pending_ids 记录了当前已经被客户端读取的消息，但是还没有 ack 。它用来确保客户端至少消费了消息一次，而不会在网络传输的中途丢失了没处理。

此外，补充两点：

• 消息ID：默认形式是timestampInMillis-sequence（时间戳-序号），用户也可以自定义，但必须是整数-整数形式。

• 消息内容：消息内容就是键值对，形如hash结构的键值对。比如：

  

消费组消费流程

1. 消费组的消费者之间竞争去消费消息（一个消息只能被一个消费者使用）；
2. 消费者消费完成之后，会给redis服务器发送一个ACK，来让redis知道该条消息消费成功。

redis_Stream___Kafka__37">redis Stream 实现的消息队列 与 Kafka 的区别

主要是二者的使用场景：

1. redis Stream 实现的消息队列：内存型数据库中的数据结构，更适用于相对简单的消息队列场景，性能受内存限制。
2. kafka消息队列：专门的分布式消息队列系统，设计用于高吞吐量、大规模数据处理。