dual-stream-architecture

双流架构（Dual-Stream Architecture）是一种针对现代分布式事件驱动系统的设计模式，通过同时利用 Apache Kafka 的持久化能力与 Redis Pub/Sub 的实时推送能力，解决了传统单一流处理方案在可靠性与低延迟之间难以兼顾的矛盾。该模式适用于需要保证消息不丢失且要求毫秒级触达的用户场景，如实时仪表板、WebSocket 推送和在线协作系统。

核心用法遵循"关键路径优先，最佳 effort 补充"的原则。系统将完整事件负载写入 Kafka 作为持久化记录（Critical Path），确保消息可靠存储与后续重放能力；同时通过 Redis Pub/Sub 向订阅者发送轻量级通知（Best-effort），实现亚秒级实时推送。代码示例展示了 DualPublisher 结构体的实现，其中 Kafka 写入失败会中断操作并返回错误，而 Redis 发布失败仅记录日志不阻断主流程。此外还支持批量发布模式，通过 Redis Pipeline 提升吞吐量。

该模式的显著优点在于架构清晰且容错性强。通过明确区分"可靠性层"与"实时层"，开发者可以根据业务需求灵活调整两侧策略，如为 Kafka 配置多副本保证数据安全，为 Redis 设置短超时避免阻塞。文档中详细列出的"NEVER Do"清单（如绝不因 Redis 故障中断主流程、绝不向 Redis 发送完整 Payload）进一步强化了生产环境的鲁棒性。

然而，双流架构也引入了额外的复杂性。维护两套消息中间件增加了基础设施成本与监控难度，Redis Pub/Sub 的"fire-and-forget"特性虽提升了性能，但也意味着实时通道存在消息丢失风险，需要客户端实现补偿机制（如连接后查询 API 获取历史事件）。此外，频道命名管理（events:{source_type}:{source_id}）在高基数场景下可能成为瓶颈。

该技能主要适合后端架构师、分布式系统开发者以及需要构建实时数据管道的工程团队。对于正在设计 WebSocket 网关、实时告警系统或活动流（Activity Feed）的开发者尤为有用。

使用风险主要包括：Redis 单点故障或网络分区可能导致实时通知延迟，虽不影响核心业务流程但会降低用户体验；错误的频道设计（如单事件单频道）会迅速耗尽 Redis 资源；开发者需充分理解最终一致性语义，避免在需要强一致性的金融交易等场景中误用此模式。

核心用法

该技能提出双事件流架构（Dual-Stream Architecture），通过同时向 Kafka（持久化）和 Redis Pub/Sub（实时）发布事件，解决事件驱动系统中"既要保证交付、又要低延迟推送"的核心矛盾。

关键实现：

• Kafka 路径：关键路径，必须成功，确保事件不丢失，支持重放与回溯
• Redis 路径：最佳 effort，失败不阻断主流程，实现亚毫秒级实时推送
• 负载分离：Kafka 承载完整 payload，Redis 仅传轻量通知（ID + 类型），客户端按需回查 API

典型场景：WebSocket/SSE 实时仪表盘、实时通知系统、事件溯源架构。

显著优点

1. 可靠性分层：Kafka 保证 at-least-once 交付，Redis 提供即时性，两者互补而非互斥
2. 故障隔离：Redis 故障不会拖垮主流程，仅降级为 Kafka 延迟消费模式
3. 性能优化：支持 Redis Pipeline 批量发布，Channel 按 events:{type}:{id} 命名，便于精准订阅
4. 生产级细节：提供完整的批量发布、背压处理、客户端断线重连等边缘 case 解决方案

潜在缺点与局限

| 局限 | 说明 |

|------|------|

| 运维复杂度 | 需同时维护 Kafka + Redis 两套基础设施，监控成本翻倍 |

| 数据一致性 | Redis 消息无持久化，崩溃即丢失，需明确语义为"通知"而非"数据" |

| 频道爆炸风险 | 高基数场景下（如每用户一频道），Redis 内存与连接数可能失控 |

| 网络带宽 | 双流同时写入，出口带宽与连接数消耗增加 |

适合人群

• 构建实时仪表盘、IM 系统、交易流水推送的后端架构师
• 需要事件溯源 + CQRS 但又要实时查询的事件驱动系统开发者
• 已使用 Kafka 但受限于消费延迟、需要补充实时通道的存量系统改造团队

常规风险

• Redis 误用为队列：技能明确警示"NEVER use Redis Pub/Sub for persistence"，但开发者仍可能混淆语义
• 敏感数据泄露：若误将完整 payload 推入 Redis，可能绕过 Kafka 的 ACL/审计机制
• 客户端重放风暴：技能建议"客户端先查 API 再订阅"，若实现不当可能引发查询洪峰
• Kafka 背压失控：内存缓冲策略若未设置上限，可能引发 OOM

来源与可信度

维护者为 GitHub 用户 wpank，通过公开仓库分发，安全认证评分 S 级（95分），无可执行代码、无敏感信息泄露、无恶意模式。属于 T2 可信来源的技术文档型技能。