发布订阅

一次发布怎样交给多个独立订阅者？

• 发布订阅: 生产者向主题发布消息，订阅者根据订阅关系接收所需消息，生产者不必逐一知道接收者;
• 主题: 对消息进行逻辑分类的通道，例如“订单已创建”，不同服务可独立订阅;
• 扇出: 为多个订阅目标提供同一事件，使通知、分析等处理可以并行;
• 动态目标: 新订阅者加入时不必修改发布方的接收者名单，有利于独立演进;

订单服务 → 订单主题 → 库存订阅
                   → 通知订阅
                   → 分析订阅

订阅如何决定接收哪些消息？

• 过滤: 按事件属性设置订阅规则，只接收与自身工作相关的消息;
• 协议端点: 订阅目标可为 HTTP 服务、队列或函数，实际支持范围取决于实现;
• 订阅稳定性: 消费者暂时离线后能否补收，取决于是否保留消息和订阅状态;
• 持久性: 某些服务保存多副本并提供至少一次投递，某些内存广播只面向在线订阅者;
• 原文修正: Pub/Sub 不必然即时推送且无积压，推拉方式和保留策略是产品层面的选择;

发布订阅与竞争消费如何区分？

模式	消息业务归属	例子
竞争消费	一项工作由某个消费者执行	多个 worker 处理图片转换
发布订阅	多个订阅分别处理同一事实	库存、通知、分析各自处理订单事件

• 组合: 每个订阅下面可以再连接一个队列，由该服务的多个实例竞争处理，兼顾扇出与水平扩容;
• 解耦范围: 发布方无需知道订阅实现，但双方仍依赖事件模式与业务语义;

发布订阅怎样保护消息边界？

• 访问控制: 发布者和订阅者分别授权，避免任意生产者伪造业务事实或任意订阅者读取敏感信息;
• 加密: 使用受保护的端点与传输通道，持久保存时也应考虑存储保护;
• 故障管理: 对每个订阅独立设置重试、死信和监控，避免一个慢消费者阻塞其他订阅;
• 原文示例: Amazon SNS、Google Pub/Sub，具体投递行为需查对应配置;