通信模式

副标题 / 摘要 请求/响应强调确定性与即时性，发布/订阅强调解耦与扩展。本文给出工程取舍与选型依据。 目标读者 设计系统通信方式的工程师 需要落地消息队列的团队 关注系统扩展性的架构师 背景 / 动机 不同业务对实时性、耦合度与可靠性要求不同。 选错通信模式会导致复杂度或性能问题。 核心概念 请求/响应：点对点、强同步 发布/订阅：多对多、异步解耦 背压与重试：决定系统稳定性 实践指南 / 步骤 确定是否必须实时同步返回结果 评估消费者数量与扩展需求 设计失败重试与死信队列 为消息定义幂等与去重策略 可运行示例 # 极简发布/订阅示例 subscribers = [] def subscribe(fn): subscribers.append(fn) def publish(event): for fn in subscribers: fn(event) if __name__ == "__main__": subscribe(lambda e: print("A got", e)) subscribe(lambda e: print("B got", e)) publish({"type": "order.created", "id": 1}) 解释与原理 请求/响应适合“需要立即结果”的业务流程。 发布/订阅适合“事件驱动、解耦扩展”的场景，但需要处理一致性与幂等。 常见问题与注意事项 发布/订阅会丢消息吗？ 可能，需配置持久化与重试机制。 请求/响应能扩展吗？ 可以，但耦合更高、弹性更差。 混用可以吗？ 可以，常见是“同步写 + 异步通知”。 ...