服务总线订购快速连续消息

Question

假设我有两种类型的消息。 消息A 和消息B。

• MessageA 在 DB 中创建一个条目。
• MessageB 更新 DB 中的条目。

大多数情况下，MessageA 与 MessageB 以长间隔发送。 但是，在某些情况下，两条消息彼此相隔数秒发送。 MessageA 可能仍在创建 DB 条目，但 MessageB 尝试更新不存在的条目。

如何处理这种情况？ 我知道有两种选择：

1. 重试/死信队列 - 消息被发送回队列并再次重试，直到达到最大传递计数并移动到死信队列
2. Defer - 消息被延迟到被明确读取

哪个是最佳实践？

• 1 似乎很好，但仍然可能达到最大重试次数，但尚未创建数据库条目。
• 2 看起来不错，但是需要做额外的编码和基础设施（Redis 和后台任务）来定期检查延迟消息

Answer 1

还有第三种处理这些竞争条件的选项（这并不总是可能的，取决于消息的性质）：

1. 当消息 B 在消息 A 之前到达时，将消息数据以部分形式或特定的保存区域存储在接收服务中。
2. 当Message A 到达时，检查是否有相同key 的Message B 数据，如果有则将两条消息一起处理。

一个实际的例子：假设我们有一个包含 Year Group 和 Student 实体的学校数据库。 要创建新学生，系统会发送一条包含所有学生详细信息的消息。 要创建新的年级组，将发送一条消息，其中包含年级组名称和应属于该年级组的 StudentId 列表。

如果在收到所有学生之前收到年级组消息，您可以创建一个仅包含学生 ID 的占位符学生实体（可能还有一个标志来标识它是占位符）。

收到学生消息后，只需添加或更新现有记录，并填写所有学生详细信息。

如果您必须选择列出的两个选项之一，则取决于：

• Retry/Deadletter 当然要简单得多，但只有在两条消息到达之间的最大延迟相对较短时才会起作用。 它要脆弱得多。
• 消息延迟将更加可靠。 它也不需要那么复杂 - 您不需要Redis 和后台任务，您可以在收到消息 A 时检查延迟消息 B。

Answer 2

对于这种需要消息顺序的场景，Service Bus 提供了一项功能来确保按照它们最初发送的顺序处理消息 - 消息会话。