redis的 stream数据类型实现 消息队列？
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结构的键值对。比如：
消费组消费流程
- 消费组的消费者之间竞争去消费消息（一个消息只能被一个消费者使用）；
- 消费者消费完成之后，会给redis服务器发送一个ACK，来让redis知道该条消息消费成功。
redis Stream 实现的消息队列 与 Kafka 的区别
主要是二者的使用场景：
- redis Stream 实现的消息队列：内存型数据库中的数据结构，更适用于相对简单的消息队列场景，性能受内存限制。
- kafka消息队列：专门的分布式消息队列系统，设计用于高吞吐量、大规模数据处理。