Redis Streams XREAD 如何按多个流合并读取消息

需要同时监听订单流和支付流时，不必为每个 Stream 开一条连接。XREAD 可以在一次请求中接收多个 key，但它的“合并”有一个容易忽略的边界：Redis 会分别返回每条流的消息和游标，不会替应用生成一个跨 Stream 的全局时间顺序。

先把两个 Stream 和起始游标对应起来

下面用订单和支付两个流组成一个小型事件读取任务。示例数据只用于说明命令结构，读者可以替换成自己的业务字段。

# 中文注释：创建两个独立 Stream，各自的 ID 由 Redis 生成
redis-cli XADD orders '*' order_id 1001 state created
redis-cli XADD payments '*' order_id 1001 state paid

# 中文注释：0-0 表示从每条流的最早位置开始读取
redis-cli XREAD COUNT 10 STREAMS orders payments 0-0 0-0

STREAMS orders payments 0-0 0-0 不是四个无关参数，而是两组配对关系：orders 对应第一个 0-0，payments 对应第二个 0-0。key 和 ID 的数量不一致时，命令就不能表达清楚每条流的读取位置。

XREAD 的返回结构是按流分组，不是全局排序

一次读取的结果通常先按 Stream 分组，再列出该流中的 entry。即使订单事件和支付事件的 ID 看起来都包含毫秒时间，它们也是各自 Stream 内的 ID，不能直接拿来推断两个流之间的先后。

# 中文注释：下面是响应形状示意，不代表某次本机执行输出
orders
  1710000000000-0  order_id=1001 state=created
payments
  1710000000001-0  order_id=1001 state=paid

如果只想接收调用之后新增的消息，可以把两个起始 ID 都写成 $：

# 中文注释：$ 只关注本次调用之后追加到各流的新 entry
redis-cli XREAD BLOCK 5000 COUNT 10 STREAMS orders payments '$' '$'

但要注意，$ 适合“从现在开始监听”的场景；如果消费者重启后还要续读，不能再次无条件使用 $，而应加载上次保存的两个实际 ID。

每条流都保存自己的最后 ID

读取循环的关键不是记住一个“总游标”，而是维护一个映射。某次响应只包含 orders 时，只推进 orders；payments 没有新消息就保留原值。应用层可以把这个映射持久化到配置存储、数据库或可靠的本地状态中。

# 中文注释：展示游标更新规则；实际项目应把 read_xread 替换为 Redis 客户端调用
cursor = {"orders": "0-0", "payments": "0-0"}

def accept_response(stream_groups):
    # 中文注释：Redis 按流返回结果，不能用一个全局 ID 覆盖所有流
    for stream_name, entries in stream_groups:
        if not entries:
            continue
        last_id, _fields = entries[-1]
        # 中文注释：只更新本次确实返回消息的 Stream
        cursor[stream_name] = last_id

# 中文注释：下一次请求把两个独立游标按 key 顺序传回 XREAD
args = ["STREAMS", "orders", "payments", cursor["orders"], cursor["payments"]]

生产代码还要给游标保存增加原子性约束：先确认消息处理成功，再提交对应 Stream 的新 ID。若业务要求至少一次处理，重启后宁可重复读取少量消息，也不要在消息尚未处理完成时提前推进游标。

COUNT、BLOCK 和应用层合并该怎么选

“合并读取”更准确的理解是“一次请求得到多个流的增量结果”。如果订单和支付必须按同一条业务时间线处理，建议在写入时携带统一的业务序号或事件时间，再由应用层做排序和去重；不要把两个 Stream 的 Redis entry ID 当成共享时钟。

常见问题

多个 Stream 的 ID 可以只写一个吗？

不可以。每个 key 都要有一个对应的 ID，顺序必须与 key 列表一致。

COUNT 10 会不会总共只返回 10 条？

不会。它按每条流限制返回量，两个流都命中时理论上可能返回两份各不超过 10 条的结果。

什么时候应该改用 XREADGROUP？

如果需要消费者组、确认和待处理消息管理，应评估 XREADGROUP；单连接读取多个流且自行维护游标时，XREAD 更直接。