事务想必大家并不陌生,比如经常被人提起的
ACID
,但是为了后续的分布式事务
的内容,我们先来聊聊ACID
,然后再介绍下什么是分布式事务
,最后着重讲下基于可靠消息
的分布式事务解决方案。ACID
,但是为了后续的分布式事务
的内容,我们先来聊聊ACID
,然后再介绍下什么是分布式事务
,最后着重讲下基于可靠消息
的分布式事务解决方案。
严格意义上的事务应该是具备原子性、一致性、隔离性和持久性,简称 ACID
ACID
。🎜原子性(Atomicity)
,可以理解为一个事务内的所有操作要么都执行,要么都不执行。原子性(Atomicity)
,可以理解为一个事务内的所有操作要么都执行,要么都不执行。一致性(Consistency)
,可以理解为数据是满足完整性约束的,也就是不会存在中间状态的数据,比如你钱包有100,我钱包有100,你给我打50块,此时你钱包的钱应该是50,我钱包的钱应该是150,不会存在我钱加了,你钱没扣的中间状态。隔离性(Isolation)
,指的是多个事务并发执行的时候不会互相干扰,即一个事务内部的数据对于其他事务来说是隔离的。持久性(Durability)
,指的是一个事务完成了之后数据就被永远保存下来,之后的其他操作或故障都不会对事务的结果产生影响。而通俗意义上事务就是为了使得一些更新操作要么都成功,要么都失败
。
分布式事务
顾名思义就是要在分布式系统中实现事务,它其实是由多个本地事务
一致性(Consistency)
,可以理解为数据是满足完整性约束的,也就是不会存在中间状态的数据,比如你钱包有100,我钱包有100,你给我打50块,此时你钱包的钱应该是50,我钱包的钱应该是150,不会存在我钱加了,你钱没扣的中间状态。🎜🎜隔离性(Isolation)
,指的是多个事务并发执行的时候不会互相干扰,即一个事务内部的数据对于其他事务来说是隔离的。🎜🎜持久性(Durability)
,指的是一个事务完成了之后数据就被永远保存下来,之后的其他操作或故障都不会对事务的结果产生影响。而通俗意义上事务就是为了使得一些更新操作要么都成功,要么都失败
。🎜
分布式事务
顾名思义就是要在分布式系统中实现事务,它其实是由多个本地事务
组合而成。🎜
一次大的操作由不同的小操作组成的,这些小的操作分布在不同的服务器上,分布式事务
需要保证这些小操作要么全部成功,要么全部失败。从本质上来说,分布式事务
就是为了保证不同数据库
的数据一致性
。分布式事务
需要保证这些小操作要么全部成功,要么全部失败。从本质上来说,分布式事务
就是为了保证不同数据库
的数据一致性
。
常见的分布式事务的解决方案有以下几种:2PC,3PC,TCC,本地消息表、可靠消息最终一致性、尽最大努力通知
等
今天我们就着重讲讲可靠消息最终一致性的解决方案
可靠消息最终一致性方案
是指当事务发起方执行完成本地事务后发出消息到消息中间件
,事务参与方(消息消费者)
一定能够接收到消息并处理事务成功,此方案强调的是只要消息发给事务参与方,则最终事务要达到一致
2PC,3PC,TCC,本地消息表、可靠消息最终一致性、尽最大努力通知
等🎜🎜今天我们就着重讲讲可靠消息最终一致性的解决方案
🎜可靠消息最终一致性方案
是指当事务发起方执行完成本地事务后发出消息到消息中间件
,事务参与方(消息消费者)
一定能够接收到消息并处理事务成功,此方案强调的是只要消息发给事务参与方,则最终事务要达到一致
。🎜此方案是通过消息中间件实现的,事务发起方(消息生产方)将消息发给消息中间件,事务参与方从消息中间件接收消息,由于网络通信的不确定性会导致分布式事务问题,如下图:
如上图在虚线框内,存在以下几种情况:
1)本地事务提交失败,则消息不发送。
2)本地事务成功,消息发送失败,本地事务回滚。
3)本地消息成功,消息超时,本地事务回滚,消息最终失败。
4)本地消息成功,消息超时,本地事务回滚,消息最终成功。
综上所述,存在第四种情况
,造成本地事务,与消息参与方的事务不一致。第四种情况
,造成本地事务,与消息参与方的事务不一致。
消息中间件与事务参与方
要确保能够成功消费
到消息。
注意事务参与方的接口幂等性
事务参与方
要确保能够成功消费
到消息。🎜接口幂等性
问题,消息参与方可能已经成功消费,由于网络问题导致消息中间件认为消息未消费,发起重试之后产生的问题。🎜本地消息表的关键在于本地有一张存储消息日志的记录表,需要启动一个定时任务去不停地扫描消息日志记录,确保消息能够被发送。具体流程如下图:
上图流程:
1)事务发起方本地事务执行成功,在本地消息表中记录消息日志。
2)启动定时任务,循环扫描本地消息表。
3)定时任务扫描到消息则发送消息到消息中间件。
4)消息中间件收到消息,成功返回消息发送成功通知给事务发起方。
5)事务发起方收到消息发送成功则删除日志消息。
6)事务参与方订阅消息,消费消息。
7)事务参与方处理本地事务。
8)本地事务处理成功,发送成功ack给消息中间件。
需要注意的点:事务参与方保证接口幂等性
。事务参与方保证接口幂等性
。
Apache RocketMQ
4.3之后的版本正式支持事务消息
,为分布式事务实现提供了便利性支持。在RocketMQ 4.3后实现了完整的事务消息,实际上其实是对本地消息表的一个封装
,将本地消息表移动到了MQ内部
,解决 Producer 端的消息发送与本地事务执行的原子性
RocketMq事务消息方案
🎜🎜🎜ApacheRocketMQ
4.3之后的版本正式支持事务消息
,为分布式事务实现提供了便利性支持。在RocketMQ 4.3后实现了完整的事务消息,实际上其实是对本地消息表的一个封装
,将本地消息表移动到了MQ内部
,解决 Producer 端的消息发送与本地事务执行的原子性
问题。🎜🎜🎜🎜实现流程:
1)事务发起方发送
Half
事务消息Half
事务消息
2)RocketMq回复Half
发送成功
3)事务发起方执行本地事务
4)事务发起方执行本地事务成功,发送commit到RocketMq,mq投递消息到事务参与方;事务发起方执行本地事务失败,发送rollback
到RocketMq,mq删除消息。
5)当RocketMq一定时间内未收到来自事务发起方的确认信息,会对事务发起方进行事务回查
。
6)事务发起方查询本地事务状态。
7)事务发起方根据查询到的事务状态发送commint/rollback
到RocketMq。
8)当RocketMq发起commit
后,收到失败或一定时间未收到成功ack,则会发起重试。
优点
:
消息数据独立存储,降低业务系统与消息系统之间的耦合。
吞吐量优于本地消息表方案。
缺点
2)RocketMq回复Half
发送成功
4)事务发起方执行本地事务成功,发送commit到RocketMq,mq投递消息到事务参与方;事务发起方执行本地事务失败,发送rollback
到RocketMq,mq删除消息。
5)当RocketMq一定时间内未收到来自事务发起方的确认信息,会对事务发起方进行事务回查
。
7)事务发起方根据查询到的事务状态发送commint/rollback
到RocketMq。
commit
后,收到失败或一定时间未收到成功ack,则会发起重试。优点
:🎜🎜消息数据独立存储,降低业务系统与消息系统之间的耦合。🎜吞吐量优于本地消息表方案。🎜🎜缺点
:🎜🎜一次消息发送需要两次网络请求(half消息 + commit/rollback)。🎜需要实现消息回查接口。🎜🎜其实每种分布式事务的解决方案都有优劣,我们需要权衡利弊,选择最合适业务场景的一种才是王道!🎜🎜🎜以上是分布式事务 :可靠消息最终一致性方案的详细内容。更多信息请关注PHP中文网其他相关文章!