Stream 数据类型

简介

尽管 Redis 的 PubSub 发布订阅（publish/subscribe ）模式实现了消息的广播，但却很难找到特别适合的应用场景，因为它的缺点十分明显：

• 没有（ack）确认机制，也不保证消息消费的连续性。
• 不支持持久化消息，如果 Redis 宕机，所有的消息都会丢失。

Redis 5.0 版本新增了 Stream 数据类型（数据结构），它给 Redis 带来了支持持久化、消费者 ack 、断点消费、多消费者组的消息队列。

Stream 从概念上来说就像是一个消息链表，把所有发布的消息都一个个串起来，每个消息都有一个唯一的 ID。

可以把 Stream 看作是轻量级的内存版 kafka。

每个 Stream 可以有多个 consumer_group，每个 consumer_group 可以有多个 consumer。同一个组内的消费者共享一个 last_delivered_id，每个消费者有自己独立的 pending_ids。

同一个组内的消费者属于竞争关系，任何一个消费者读取了消息都会使组内的游标 last_delivered_id 往前移动。同组内的多个消费者会轮询获得同一个队列中的消息。如果同一个组内有多个消费者，就会加快该组消费的速度。

多个消费者组之间是彼此独立的，互不影响，也就是说，同一条消息可以被多个 consumer_group 消费到。

Stream 中的术语

• consumer_group：消费者组。消费者既可以选择单独消费，也可以加入一个消费者组实现组内消费。同一个组内的多个消费者共享所有的消息，同一条消息只会被组内的一个消费者消费到，可以应用在分布式的场景中来保证消息的唯一性。
• last_delivered_id：用来记录 consumer_group 最近一次读取到的消息 id，它是存在于消费者组的标识。消费者组不会自动创建，需要使用 xgroup create 命令来显式创建，并且要指定 last_delivered_id 标识（游标）。组内的消费者一旦读取到消息， last_delivered_id 就会更新，不管消息是否被消费者正确处理完。
• pending_ids：也被称为 PEL（Pending Entries List，待处理消息列表）。每一个消费者各自维护一套，用来表示已经被消费者获取，但还没有进行 ack 确认（acknowledge）的消息。记录的目的是为了保证至少消费了一次消息。当某个消息被 ack，才会从 pending_ids 中移除。
• 单独消费 xread：也称独立消费，指的是消费者不加入任何一个组，单独消费消息。这样，就无法维护 last_delivered_id，不能支持断点消费。它可能导致漏掉消息的问题。
• 组内消费 xreadgroup：指的是以消费者组的形式消费消息。由于组内维护了一个 last_delivered_id 标识，因此组内消费模式支持断点消费。推荐使用 xreadgroup 命令。
• ack：它是 acknowledge 的简写。组内消费者一旦读取到消息，就会将其标记会 pending（待处理状态），记录到当前消费者自身的 pending_ids 列表，当消费者正确处理完消息，必须手动发送 ack 指令，告知服务器自己处理好了。该消息的 pending 标识才会移除，也就是从消费者的 pending_ids 列表中移除。ack 指令并不会导致消息从 Stream 队列中移除，因为一个队列是可以绑定多个消费者组的，可能其他的消费者组还没消费。这里说的 ack 确认机制，仅仅是消费者侧的 ack。

组内消费的优点

• 消息分流：队列中的消息会分流（平均分配）给同一个组内的多个消费者，从而加快了消费的速度。
• 消息标识：消费者组会维护一个标识（游标），用于记录最近一次消费的消息 id，即 last_delivered_id。这样，就算有消费者宕机重启，也可以根据组内维护的 last_delivered_id 标识，接着消费消息。它可以支持断点消费，保证了消费消息的连续性，确保组内的每一条消息都可以被消费到。
• ack 确认机制：组内的消费者获取消息后，消息会处于 pending 状态，并记录到消费者的 pending_ids 列表。当消费者成功处理完该消息，需要通过 xack 命令进行确认（告知服务器，我已经处理好了该消息），从而解除消息的 pending 状态，将其从 pending_ids 中移除。ack 确认机制可有效避免消费者拿到了消息，但在处理过程中发生故障（比如宕机）&#