duplicates - 发件箱模式 - 对于任何 SQL 和 NoSQL DB 没有重复和无序的消息中继

Question

当我们需要在 2 个系统中更改数据时，双写入是一个问题:数据库(SQL 或 NoSQL)和 Apache Kafka(例如)。 必须更新数据库并可靠地/原子地发布消息。 最终一致性是可以接受的，但不一致是 Not Acceptable 。

如果没有 2 阶段提交 (2PC)，双重写入会导致不一致。

但在大多数情况下，2PC 不是一种选择。

Transactional Outbox是一种微服务架构模式，其中单独的消息中继进程将插入数据库的事件发布到消息代理。

并行运行的多个消息中继进程会导致发布重复(2 个进程读取 OUTBOX 表中的相同记录)或无序(如果每个进程只读取 OUTBOX 表的一部分)。

单个消息中继进程也可能多次发布消息。消息中继可能会在处理 OUTBOX 记录之后但在记录它已经这样做的事实之前崩溃。当 Message Relay 重新启动时，它会再次发布相同的消息。

如何在事务性发件箱模式中实现消息中继，以便将重复消息或未排序的风险降到最低，并且该概念适用于所有 SQL 和 NoSQL 数据库？

Answer 1

Exactly-once delivery guarantee 而不是使用 Transactional Outbox 模式的 at-least-once 很难实现。

消息中继发布的消息的消费者必须是幂等的，并过滤重复和无序的消息。

消息必须包含

• 实体的当前状态(而不是仅更改的字段，也称为更改事件，“delta”)，
• ID header 或字段，
• 版本标题或字段。

ID header /字段可用于检测重复项(确定消息已被处理)。

版本 header /字段可用于确定消息的更新版本已被处理(如果消费者收到 msg_a: v1, v2, v4 则它必须在消息到达时丢弃 v3 的 msg_a 因为更新已处理 msg_a 的 v4 版本)。

Message Relay 被提取到一个单独的微服务中并在单个副本(Kubernetes 中的 .spec.replicas=1)中运行，并在所有现有 Pod 被终止时使用 Recreate Deployment 策略(Kubernetes 中的 .spec.strategy.type=Recreate)进行更新在创建新的之前(而不是 RollingUpdate 部署策略)无助于解决重复问题。消息中继可能会在处理 OUTBOX 记录之后但在记录它已经这样做的事实之前崩溃。当 Message Relay 重新启动时，它会再次发布相同的消息。

拥有多个主动-主动消息中继实例可以实现更高的可用性，但会增加发布重复和无序的可能性。

对于快速故障转移的Message Relays主备集群可以基于

• 使用 sidecar 进行 Kubernetes 领导人选举 k8s.io/client-go/tools/leaderelection
• Redis 分布式锁(Redlock)
• SQL 锁使用 SELECT ... FOR UPDATE NOWAIT
• 等等

作为explained by Martin Klappmann没有 fencing 的分布式锁会被破坏，并且只能最大限度地减少领导者选举中出现多个领导者(短时间内)的机会。