Zaqar/specs/use-cases/3

Marconi: 用例 3

将事件发布给任意数量的订阅者。

特征信息

目标背景

先决条件

成功结束条件

失败结束条件

主要参与者

触发器

范围

此用例仅涵盖单个应用程序域内的发布-订阅。将事件发布给第三方系统，包括通过 Web 钩子、电子邮件、移动消息服务等，不在此项目的范围内。此类通知桥接最好实现为互补服务。

主要流程

1. 发布者对事件进行签名并将其提交给服务

2. 服务确认事件并保证其持久性

3. 订阅者从服务检索事件

4. 订阅者验证事件的真实性

5. 订阅者处理事件

6. 订阅者循环到 (3)

变体

2a. 服务无法以持久的方式持久化事件：服务返回错误状态和信息给发布者；发布者可以选择重试请求或简单地记录失败并继续，具体取决于收到的错误的性质。

2b. 发布者可以指定持久性容忍度：如果事件是短暂的并且发布者愿意用持久性换取性能，发布者可以在提交过程中向服务提供一个提示。

3a. 已经排队了多个事件：订阅者检索最多 min(50, n) 个事件，其中 n 是订阅者在每次向服务发出请求时指定的。

3b. 没有可用事件：服务返回“无内容”状态码，订阅者必须在一段时间延迟后重试。

3c. 订阅者必须区分特定的事件流：发布者标记事件，订阅者请求服务根据指定的标签过滤事件（在发布者和订阅者之间通过非同步方式协商）。

4a. 事件的签名无效：订阅者忽略该错误事件，跳过下一步 (5)。

6a. 已经排队了超过 min(50, n) 条消息，或者发布者提交事件的速度快于它们被消费的速度：订阅者循环，直到所有事件都被处理。发布者可能需要增加事件的 TTL，以便订阅者能够跟上。

相关信息

• 如果对相同的标签集进行过滤，则多个订阅者可以接收相同的事件。为了便于点对点或 RPC 样式的通信，每个订阅者必须过滤一个唯一的标签集。
• 所有事件提交和检索都会在审计流中记录，并且可以通过轮询来观察。
• 组件和收集器可以通过标记命名事件。
• 发布者、订阅者和审计者可以请求消息总线指标，可以选择性地按一个或多个标签进行过滤。例如，这可用于动态调整事件 TTL。