机械行业网站建设制作开发方案,石家庄建设网站,合肥专业手机网站哪家好,做衣服外单网站前言
传统单体架构下#xff0c;所有的功能模块都在一个应用下#xff0c;所有的代码和业务逻辑都在同一个应用下实现#xff0c;所以保证数据的一致性就很简单#xff0c;保证相关操作都在同一个本地事务下就可以了。
但是在微服务架构下#xff0c;将一个应用拆分成了…前言
传统单体架构下所有的功能模块都在一个应用下所有的代码和业务逻辑都在同一个应用下实现所以保证数据的一致性就很简单保证相关操作都在同一个本地事务下就可以了。
但是在微服务架构下将一个应用拆分成了多个独立的服务每个服务都能有自己的数据库服务间通信都是通过远程调用实现实现一个功能可能需要由几个不同的服务来共同实现。这就会带来一个问题不同的服务之间无法做到使用同一个事务这就无法保证数据的一致性了。
解决分布式事务的问题一劳永逸的方式就是直接使用 SeataSeata 是一个开源的分布式事务解决方案用于解决分布式系统中的数据一致性问题。但是引入 Seata 实在是太重了在实际工作中接触过的系统并没有那么多的业务需要使用到分布式事务为了解决那么一两个业务的问题却要为整个系统引入分布式事务服务代价实在是太大了。而且相关的业务实际上只需要保证数据的最终一致性不用保证强一致性所以在实践可以使用本地消息表的方案来解决分布式事务问题。
本地消息表方案
如果系统中只有少数服务需要用到分布式事务那么直接在该服务下创建一张本地消息表结合消息队列就能够实现数据的最终一致性了。
表设计
本地消息表的设计如下
字段类型注释idlongidmsg_typevarchar消息类型biz_idvarchar业务唯一标志contenttext消息体statevarchar状态待发送已消费create_timedatetime创建时间update_timedatetime更新时间
时序图 plantuml startuml
https://plantuml.com/sequence-diagramautonumberparticipant Scheduled_Task
database DB_A
participant Service_A
queue Queue
participant Service_B
database DB_Bgroup Service_A本地事务DB_A - Service_A: 写本地业务数据DB_A - Service_A: 写本地消息数据
endService_A - Queue: 发送消息
note left
发送消息放到事务外
防止由于网络延迟出现
Service_A认为发送失败导致事务回滚
而实际上MQ收到了消息
Service_B也消费了消息
从而出现数据不一致的情况
end noteQueue - Service_B: 消费消息Service_B - Service_B: 幂等判断
note right
防止重复消费消息
end notegroup Service_B本地事务Service_B - DB_B: 写本地业务数据
endgroup 更新本地消息表状态Scheduled_Task - Service_B: 更新本地消息表状态Scheduled_Task - DB_A: 更新本地消息表状态
end
note right
这里即使失败了也无所谓
两个服务的数据已经一致了
没有更新消息状态定时任务会重新投递
Service_B做好幂等处理
等下次消费再去修改消息状态即可
end noteloop 定时任务Scheduled_Task - DB_A: 查询未成功投递的消息Scheduled_Task - Queue: 重新投递
endenduml消息服务方案
本地消息表只只用系统中只有少量业务需要实现分布式事务的情况如果系统中的绝大多数服务都存在分布式事务的业务场景为每个服务都创建一张本地消息表显然很麻烦难以维护。
用到的地方多实际上就可以考虑上 Seata 了专业的事要交给专业的服务来做。不过这里也可以改进一下本地消息表的方案增加一个专门处理分布式事务消息的消息服务和消息库。
表设计
表设计同上面一样消息服务只不过将所有本地消息表合并成一张表了
只不过 state 字段需要多一个状态来区分
在本地消息表方案中由于写Service_A业务和创建消息是在同一个事务中它们要么同时成功要么同时失败所以两个状态待发送已消费就能表示整个消息的生命周期。
待发送状态则表示Service_A业务和消息同时写入库成功等待Service_B消费消息已消费状态则表示Service_B已经成功消费了消息
在消息服务方案中写业务和创建消息不在同一个事务中所以需要再加一个状态发送中
待发送状态则表示刚创建消息此时Service_A还没有写库发送中状态则表示Service_A已经写库成功等待Service_B消费消息已消费状态则表示Service_B已经成功消费了消息
时序图 plantuml startuml
https://plantuml.com/sequence-diagramautonumberdatabase DB_A
participant Service_A
participant Service_Msg
database DB_Msg
queue Queue
participant Service_B
database DB_Bgroup 创建消息Service_A - Service_Msg: 创建消息note left: 生成业务idService_Msg - DB_Msg: 创建消息note left: 消息状态待发送Service_A - Service_Msg: 返回消息ID
endgroup Service_A本地事务DB_A - Service_A: 写本地业务数据
endService_A - Service_Msg: 发送消息
note left: 携带消息ID
Service_Msg - DB_Msg: 更新消息状态
note right: 消息状态发送中
Service_Msg - Queue: 发送消息
Queue - Service_B: 消费消息Service_B - Service_B: 幂等判断group Service_B本地事务Service_B - DB_B: 写本地业务数据
endgroup 更新消息状态Service_Msg - Service_B: 更新消息状态Service_Msg - DB_Msg: 更新消息状态note right: 消息状态已消费
endloop 定时任务Service_Msg - DB_Msg: 查询状态为发送中的消息Service_Msg - Queue: 重新投递
endenduml
