如何解决发件箱模式 - 对于任何 SQL 和 NoSQL DB 没有重复和无序的消息中继
当我们需要更改 2 个系统中的数据时,双重写入是一个问题:数据库(SQL 或 NoSQL)和 Apache Kafka(例如)。 必须更新数据库并可靠地/原子地发布消息。 最终的一致性是可以接受的,但不一致则不是。
如果没有 2 阶段提交 (2PC),双重写入会导致不一致。
但在大多数情况下,2PC 不是一种选择。
Transactional Outbox 是一种微服务架构模式,其中单独的 Message Relay 进程将插入数据库的事件发布到消息代理。
多个 Message Relay 进程并行运行会导致发布重复项(2 个进程读取 OUTBOX 表中的相同记录)或无序(如果每个进程只读取 OUTBOX 表的一部分)。
单个消息中继进程也可能多次发布消息。消息中继可能会在处理 OUTBOX 记录之后但在记录它已经这样做的事实之前崩溃。当 Message Relay 重新启动时,它将再次发布相同的消息。
如何在事务发件箱模式中实现消息中继,从而将重复消息或无序的风险降至最低,并且该概念适用于所有 SQL 和 NoSQL 数据库?
解决方法
使用事务发件箱模式很难实现恰好一次的交付保证,而不是至少一次。
消息中继发布的消息的消费者必须是幂等的,并过滤重复和无序的消息。
消息必须包括
- 实体的当前状态(而不是仅更改字段,即更改事件,“delta”),
- ID 标头或字段,
- 版本标题或字段。
ID 标头/字段可用于检测重复项(确定消息已被处理)。
版本头/字段可用于确定消息的更新版本已被处理(如果消费者收到 msg_a: v1,v2,v4 那么它必须在它到达时丢弃 msg_a 的 v3,因为更新msg_a 的 v4 版本已经处理完毕。
Message Relay 提取到一个单独的微服务中并在单个副本中运行(Kubernetes 中的 .spec.replicas=1)并在所有现有 Pod 被终止时使用重新创建部署策略(.spec.strategy.type=Recreate 在 Kubernetes 中)进行更新在创建新的之前(而不是 RollingUpdate 部署策略)无助于解决重复问题。消息中继可能会在处理 OUTBOX 记录之后但在记录它已经这样做的事实之前崩溃。当 Message Relay 重新启动时,它将再次发布相同的消息。
拥有多个主动-主动消息中继实例可以实现更高的可用性,但会增加发布重复和无序的可能性。
对于消息中继的快速故障转移主备集群可以基于
- Kubernetes Leader 选举使用 sidecar k8s.io/client-go/tools/leaderelection
- Redis 分布式锁(Redlock)
- 使用
SELECT ... FOR UPDATE NOWAIT
的 SQL 锁 - 等
由于 explained by Martin Klappmann 没有围栏的分布式锁被破坏,并且只会最大限度地减少领导者选举中多个领导者(短时间内)的机会。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。