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 资源；开发者需充分理解最终一致性语义，避免在需要强一致性的金融交易等场景中误用此模式。