网站如何定位,莱芜雪野湖好玩吗,衡阳网站优化公司,企业备案增加网站本文参考#xff1a; 数据库事务系列04-本地消息表实现分布式事务 基础概念
本地消息表实现分布式事务最终一致性的核心#xff1a;是通过上游本地事务的原子性持久性#xff0c;配合中间件的重试机制#xff0c;从而实现调用下游的最终一致性。
这里有几个要点可以解析一… 本文参考 数据库事务系列04-本地消息表实现分布式事务 基础概念
本地消息表实现分布式事务最终一致性的核心是通过上游本地事务的原子性持久性配合中间件的重试机制从而实现调用下游的最终一致性。
这里有几个要点可以解析一下 上游本地事务的原子性 通常上游会专门维护一张本地消息表存放调用下游的消息作为调用下游的依据。并且写消息表的动作和上游的业务逻辑都放在同一个本地事务中位于同一个数据库中借助本地事务的 ACID 特性实现写业务逻辑 写下游消息的一致。 中间件的重试机制 会有中间件异步地去读取上面写的消息表通常是定时任务去异步地扫表读取出其中没有被确认调用过下游的消息再次对下游发起调用。这里对下游发起调用也有多种方式 在定时任务中按照消息表中记录的结构体直接调用下游 RPC当有多个下游要接入的时候上游需要配合改代码代码耦合度较高但是逻辑简单不需要接入其他中间件时效性最快。定时任务将消息投递至消息中间件 MQ由下游消费 MQ当有多个下游要接入的时候上游不需要感知实现了逻辑解耦但是架构较复杂需要上下游同时接入中间件 MQ并且时效性也没有很快因为定时任务 - MQ - 调用下游 会有额外的网络开销。 调用下游的一致性 由于可能存在中间件的重试调用所以下游需要自己保证调用接口的幂等性否则会存在重复脏数据。
具体实现
来看看网上常见的两种本地消息表实现方案之前我对这些方案也容易产生混淆想着这种常见的分布式事务一致性手段为什么连方案都不能实现统一但是后来发现各种方案都是基于特定的场景衍生出来的都有其应用场景需要具体情况具体分析。先提前总结下核心区别在于修改消息表消息状态是由上游控制还是由下游控制的
本地消息表结构
NameTypeCommentIdLong唯一 idContentText消息表内容JSONBiz_TypeInteger消息类型StatusInteger消息状态0未确认1已确认Create_timeDatetime创建时间Modify_timeDatetime修改时间Ext_fieldText拓展字段
方案 1
核心流程如下所示
上游 Service 执行业务逻辑写入业务数据表上游 Service 插入本地消息表status 0 未确认定时任务扫描消息表中 status 0 的记录定时任务投递 status 0 的记录至 MQ下游 Service 接入并读取 MQ 消息下游 Service 幂等消费并执行自己的业务逻辑下游 Service 业务逻辑执行成功回调 上游 Service 的接口通知成功上游 Service 被回调以后更新本地消息表状态为 status 1 确认 其中 7, 8 需要上游业务提供回调接口由下游调用告知上游消息已经被正确地调用了通过这一次 RPC 调用保证了上下游服务的最终一致性
方案 2
整体业务架构和上面的方案一致但流程上有些不一样
上游 Service 执行业务逻辑写入业务数据表上游 Service 插入本地消息表status 0 未确认定时任务扫描消息表中 status 0 的记录定时任务投递 status 0 的记录至 MQ定时任务直接将 status 改为 1 已发送下游 Service 接入并读取 MQ 消息下游 Service 幂等消费并执行自己的业务逻辑 其中 45 是定时任务投递了 MQ 消息过后就直接将消息表中的状态 status 1上游的职责就是最大努力通知上游将 status 0 努力通知到下游通知到下游就与它无关了。后续依赖 MQ 的持久化机制并且完全信赖下游读取 MQ 消息并且能够成功消费的。
方案 1-2
这算是方案1在架构上的一种变式吧就是不依赖 MQ直接 RPC 调用下游实现起来相对简单耦合度会比较高业务上下游针对不同的业务逻辑都需要单独开发一次
