1. 事件流平台需求分析
在动手搭建任何事件流平台之前，最容易被跳过、却最决定成败的一步，是需求分析。很多团队一上来就选型 Kafka、Pulsar 或 Redis Streams，结果要么过度设计，要么在关键约束上踩坑。本章的目标不是介绍 Redis Streams 的 API，而是建立一套判断框架：先把业务侧的事件需求翻译成可量化的工程指标，再对照 Redis Streams 的能力边界，得出"适用 / 有条件适用 / 不适用"的结论。
一、事件流平台的六类核心需求维度
无论业务形态如何，事件流平台的需求都可以收敛到六个维度。理解这六个维度，是后续所有选型判断的基础。
- 事件源（Event Source）：谁产生事件、事件类型有多少、单条事件的大小、事件是否有序、是否分区。例如订单系统产生"下单/支付/发货"事件，单条约 1KB，按订单号有序。
- 吞吐量（Throughput）：峰值与均值分别是多少条/秒、多少 MB/s。峰值往往是均值的 5～20 倍，必须按峰值设计。
- 延迟（Latency）：从事件产生到被消费的端到端延迟要求，是毫秒级、秒级还是分钟级可接受。
- 持久化（Durability）：事件需要保留多久、能否丢失、是否需要重放历史、是否要求落盘。
- 消费语义（Delivery Semantics）：至少一次、至多一次还是恰好一次；是否需要多消费组独立消费；是否需要消费确认与重试。
- 运维约束（Operations）：团队是否已有 Redis 运维能力、是否接受内存成本、是否需要跨机房、监控与告警如何接入。
这六个维度不是并列的清单，而是相互制约的。例如"毫秒级延迟 + 恰好一次 + 长期持久化"三者同时要求，往往意味着需要更重的系统；而"秒级延迟 + 至少一次 + 短期保留"则非常适合 Redis Streams。
二、把业务语言翻译成工程参数
需求分析的关键动作是"翻译"。业务方说"订单事件不能丢"，工程上要翻译成：持久化等级 = 至少一次 + AOF everysec 或 always；保留策略 = 至少 7 天；消费确认 = XACK 必须落库后再执行。业务方说"大促期间要扛住"，要翻译成：峰值吞吐 = 均值 × 10，并预留 30% 余量。
下面给出一个可填写的需求采集表，字段直接对应 Redis Streams 的配置决策，而不是泛泛的管理字段。
| 需求项 | 业务描述示例 | 工程参数 | 影响 Redis Streams 的决策 |
|---|---|---|---|
| 事件源 | 订单、支付、物流三类 | 3 个 Stream，按 orderId 分区 | Stream key 命名与分区键 |
| 单条大小 | 约 1KB | 1KB × 峰值 QPS | 内存估算与 maxmemory 策略 |
| 峰值吞吐 | 大促 5 万条/秒 | 50,000 QPS，约 50MB/s | 是否需要集群分片 |
| 端到端延迟 | 秒级可接受 | P99 < 1s | XADD + XREADGROUP 阻塞读 |
| 持久化 | 不可丢失，保留 7 天 | 至少一次 + AOF | appendonly yes，XADD 后 XACK |
| 消费语义 | 多团队独立消费 | 多消费组 | XGROUP CREATE 多组 |
| 运维约束 | 已有 Redis 集群 | 复用现有集群 | 避免引入新中间件 |
三、Redis Streams 的能力边界
Redis Streams 是 Redis 5.0 引入的数据结构，核心命令包括 XADD（追加）、XREAD/XREADGROUP（读取）、XACK（确认）、XDEL/XTRIM（删除与裁剪）、XPENDING/XCLAIM（待处理与认领）。它的优势非常明确：
- 延迟极低，XADD 与 XREADGROUP 都是内存操作，P99 通常在亚毫秒到毫秒级。
- 天然支持多消费组，每个消费组独立维护 last-delivered-id，互不影响。
- 支持消费确认与 Pending Entries List（PEL），可实现至少一次语义与失败重试。
- 与现有 Redis 运维体系复用，部署成本低。
但它的边界同样清晰，必须在需求分析阶段就识别出来：
- 持久化依赖 Redis 本身：RDB 可能丢数据，AOF everysec 最多丢 1 秒，AOF always 性能下降明显。若要求"零丢失"，需评估是否接受 always 或改用其他系统。
- 内存成本高：事件全量驻留内存，长期保留大量历史事件不经济，必须配合 XTRIM 或 MAXLEN 裁剪。
- 分区与扩展有限：单个 Stream 是单 key，无法像 Kafka 那样天然分区并行；高吞吐需靠多 Stream + 客户端分片或 Redis Cluster。
- 无跨机房复制原生支持：跨地域容灾需额外方案。
- 消费语义上限为至少一次：恰好一次需业务侧幂等配合，Redis 本身不提供事务性消费。
四、适用性判断流程
把上述维度组织成一个可执行的判断流程，可以显著降低选型的主观性。下图展示了从业务事件源出发，经过六维需求过滤，最终落到 Redis Streams 适用性结论的判断路径。
图中的判断依据是经验阈值，不是硬性标准。例如"吞吐 ≤ 10 万 QPS"是单集群的保守估计，实际取决于分片数、单条大小和网络带宽。当业务落在"有条件适用"区间时，通常需要三项补偿措施：业务侧幂等（应对至少一次重复）、XTRIM 或 MAXLEN 控制内存、以及多 Stream 分片提升并行度。
五、一个完整的判断示例
假设某电商平台要建设订单事件流，需求如下：订单事件峰值 3 万条/秒，单条 1.2KB，端到端延迟要求 P99 小于 500ms，事件不可丢失且需保留 3 天，风控、履约、数据三个团队需独立消费，平台已有 Redis Cluster 运维能力。
逐项对照：吞吐 3 万 QPS、约 36MB/s，在 Redis Cluster 多分片下可行；延迟 500ms 远高于 Redis 毫秒级能力，满足；持久化要求"不可丢失"，需开启 AOF everysec 并接受极端情况下最多 1 秒数据风险，若业务要求零丢失则需 AOF always 或改用其他系统；保留 3 天，按 3 万 QPS × 1.2KB × 86400 × 3 ≈ 9.3TB 内存，明显过高，必须用 XTRIM 缩短保留期或降低采样；三个团队独立消费，正好对应三个消费组，是 Redis Streams 的强项；已有 Redis Cluster，运维成本低。
结论是"有条件适用"：核心障碍是 3 天全量保留的内存成本。若业务可接受保留 6 小时（约 780GB，仍偏高）或对历史事件改用冷存储，则 Redis Streams 可行。这个示例说明，需求分析的价值不在于给出"是/否"，而在于提前暴露成本与风险点。