Redis Streams 与消费者组可验证实战：顺序保证、重试与监控

本文围绕 Redis Streams 的核心命令与消费者组机制，提供可复现的命令清单与观察指标，帮助在生产环境实现稳定的消息处理与监控闭环。

## 适用版本与前提

• Redis 6.2+（推荐 7.x，以使用 `XAUTOCLAIM`）。
• 单实例或高可用（Sentinel/Cluster）均可；需保证持久化（AOF/RDB）配置符合业务恢复目标。

## 基本模型与术语

• 流（Stream）：追加写入的有序条目集合，ID 单调递增。
• 消费者组（Consumer Group）：在同一流上形成工作队列，消息被分派给组内消费者，并需 `XACK` 确认。
• PEL（Pending Entries List）：每个组/消费者的未确认消息列表，用于重试与故障转移。

## 创建与写入（可复现）

# 创建流并写入条目（自动分配 ID）
XADD mystream * order_id 1001 amount 29.99
XADD mystream * order_id 1002 amount 49.00

# 创建消费者组（从历史头部读取）
XGROUP CREATE mystream g_orders 0

# 创建消费者并读取（使用组读取）
XREADGROUP GROUP g_orders c_worker1 COUNT 10 STREAMS mystream >

观察要点：

• `XREADGROUP` 使用 `>` 仅读取尚未分派的条目；首次读取会将条目置入该消费者的 PEL。
• 成功处理后执行 `XACK` 确认，消息将从 PEL 移除。

# 处理完成后确认
XACK mystream g_orders 1700000000000-0

# 查看组与消费者信息
XINFO STREAM mystream
XINFO GROUPS mystream
XINFO CONSUMERS mystream g_orders

## 顺序保证与交付语义

• 流内条目是严格有序的，但消费者组的“交付顺序”受并发与重试影响，业务层不可依赖组内严格顺序。
• 交付语义为“至少一次”：如果消费者未 `XACK`，条目会留在 PEL 中以供其他消费者重试领取。
• 业务层建议：使用幂等处理（基于业务唯一键），必要时以“分区键”将相关事件写入同一流或同一消费者，以降低乱序影响。

## 故障与重试（可复现）

# 查看未确认消息（范围与摘要）
XPENDING mystream g_orders

# 传统领取：将超时未确认的消息转移给指定消费者
XCLAIM mystream g_orders c_worker2 60000 1700000000000-0

# 自动领取（Redis 6.2+）：按空闲时长批量领取
XAUTOCLAIM mystream g_orders c_worker2 60000 0 COUNT 100

建议：

• 定义明确的“空闲阈值”（如 60s）用于判定消费者故障或阻塞。
• 重试次数与滞留时间超限时，写入死信流（DLQ）进行人工排查与自动化修复。

# 写入死信流示例
XADD dlq_orders * reason timeout origin_id 1700000000000-0

## 监控与可观测性（可复现）

• 容量与写入：`XINFO STREAM` 观察 `length` 与最近/最早 ID；结合键空间内存占用评估持久化与保留策略。
• 处理健康：`XPENDING` 统计 PEL 尺寸与最老条目空闲时长，阈值告警体现堆积与故障。
• 消费者活跃度：`XINFO CONSUMERS` 查看 `pending` 与 `idle`，闲置过久需回收或重启。

示例采集（每分钟）：

XINFO STREAM mystream
XINFO GROUPS mystream
XPENDING mystream g_orders

## 性能与保留策略

• 自动修剪：
• 精确修剪：`XTRIM mystream MAXLEN = 1000000`（维持精确长度，成本较高）。
• 近似修剪：`XTRIM mystream MAXLEN ~ 1000000`（性能更优，长度近似）。
• 批量读取：设置合理的 `COUNT` 与超时，配合多消费者提升吞吐；避免单消费者成为瓶颈。
• 持久化：AOF 建议开启 `appendfsync everysec` 并监控 AOF 重写时间；Cluster 模式需验证路由与副本延迟对流写入的影响。

## 参考设计（生产落地）

• 幂等键：以 `order_id` 或事件 `event_id` 作为去重基。
• 重试分级：短重试（秒级）自动领取；超限写入 DLQ 并附带上下文。
• 指标与告警：按 PEL 最老条目空闲时长、组 pending 总量、消费者 idle 时长设定阈值。

## 结语

通过可复现的 Streams 与消费者组命令组合，可以在生产环境实现“至少一次”交付的可靠处理、明确的重试与监控指标，从而构建稳健的事件驱动架构。