Redis Stream 适合日均消息量百万级以下、已有 Redis 基础设施且对延迟敏感的中小型项目。Kafka 适合吞吐超过 10 万/秒、需要长期存储或严格可靠性保障的大规模分布式场景。

快速处理思路

选型过程不需要复杂测试，先通过三个核心指标快速过滤。

1. 评估消息量：统计当前日均消息总量，若低于百万级且峰值不超过 10 万/秒，Redis Stream 可行。
2. 检查基础设施：确认项目中是否已部署 Redis，若已有 Redis 且无 Kafka 运维团队，优先选 Redis Stream 降低复杂度。
3. 确认可靠性等级：若业务涉及金融交易或严格顺序消费，需评估 Redis 持久化配置（AOF/RDB）是否满足要求，否则选 Kafka。

为什么会这样

架构设计差异决定性能边界。Redis Stream 基于内存操作，延迟低但受内存容量限制；Kafka 基于磁盘顺序写入，吞吐高但延迟相对较高。

Redis Stream 在 Redis 5.0 引入，设计哲学是轻量级，单实例即可运行，无需 ZooKeeper 配合，内存操作带来微秒级延迟。Kafka 是分布式日志系统，需要分区机制和集群协调，适合海量数据流处理。部分基准测试数据显示，在特定配置下 Redis Stream 单条生产耗时可能低于 Kafka，但消费者吞吐量 Kafka 通常更高。

分步处理

按步骤执行选型评估，确保决策可落地。

1. 吞吐量压力测试

使用基准测试工具验证当前环境性能。

redis-benchmark -t xadd -n 1000000 -r 1000000 mystream * field1 value1

观察 QPS 表现，若单节点无法满足峰值流量，需考虑 Kafka 的分区扩展能力。

2. 持久化配置检查

Redis 需开启持久化防止消息丢失。

config set appendonly yes

确认 AOF 策略为 everysec 或 always，权衡性能与安全性。Kafka 默认基于磁盘存储，持久性更强。

3. 消费组模型验证

验证多消费者并行处理能力。

XGROUP CREATE mystream mygroup $ MKSTREAM

确保支持 ACK 机制，避免消息消费失败后丢失。Redis Stream 支持消费组和待处理列表（PEL），实现至少一次交付语义。

怎么验证是否生效

通过监控指标确认消息队列运行状态。

• 延迟监控：检查消息生产到消费的时间差，Redis Stream 应控制在毫秒级以内。
• 堆积检查：使用XINFO STREAM查看消息堆积数量，若持续增长说明消费能力不足。
• 内存使用：监控 Redis 内存占用，防止因消息堆积导致内存溢出触发淘汰策略。

常见坑

• 内存爆炸：Redis 基于内存存储，若消费者处理慢于生产者，消息堆积会耗尽内存。需设置最大内存限制和淘汰策略。
• ACK 遗漏：消费者处理成功后必须发送 ACK，否则消息会留在待处理列表（PEL）中，导致重复消费或内存泄漏。
• 顺序性误区：Redis Stream 保证流内顺序，但多消费者组并行处理时需注意业务逻辑的顺序依赖。
• 可靠性不足：相比 Kafka，Redis Stream 在极端故障下的数据恢复能力较弱，不适合核心金融交易场景。

常见问题

Redis Stream 能完全替代 Kafka 吗？

不能，高吞吐场景仍建议 Kafka。当消息吞吐超过 10 万/秒或需要长期存储时，Kafka 的分区机制和磁盘持久化更具优势。

Redis Stream 消息会丢失吗？

配置持久化可降低风险。开启 AOF 持久化并正确使用 ACK 机制，可保证至少一次交付，但极端故障下可靠性低于 Kafka。

已有 Redis 项目迁移成本高吗？

较低，复用现有实例。Redis Stream 无需部署额外服务，适合快速实现原型验证或已有 Redis 基础设施的项目。

参考来源

• Spring Boot 项目里用 Redis Stream 替代 Kafka:一个轻量级消息队列的完整落地实践
• Redis100 篇 - Redis vs Kafka 消息队列场景怎么选
• Redis5.0 Stream 深度测评：比 Kafka 轻量 100 倍的消息队列方案？
• 选 Redis Stream 还是传统 MQ?——技术选型与场景适配指南
• Redis Streams vs Kafka:轻量级消息队列选型指南
• 【消息队列】几个 mq 组件的对比：redis stream/rabbitmq/rocketmq/kafka