分布式事务—两阶段提交协议

分布式事务—两阶段提交协议

两阶段提交协议(Two-phase Commit,2PC)经常被用来实现分布式事务。一般分为协调器C和若干事务执行者Si两种角色,这里的事务执行者就是具体的数据库,协调器可以和事务执行器在一台机器上。

  1) 我们的应用程序(client)发起一个开始请求到TC;

  2) TC先将<prepare>消息写到本地日志,之后向所有的Si发起<prepare>消息。以支付宝转账到余额宝为例,TC给A的prepare消息是通知支付宝数据库相应账目扣款1万,TC给B的prepare消息是通知余额宝数据库相应账目增加1w。为什么在执行任务前需要先写本地日志,主要是为了故障后恢复用,本地日志起到现实生活中凭证 的效果,如果没有本地日志(凭证),出问题容易死无对证;

  3) Si收到<prepare>消息后,执行具体本机事务,但不会进行commit,如果成功返回<yes>,不成功返回<no>。同理,返回前都应把要返回的消息写到日志里,当作凭证。

  4) TC收集所有执行器返回的消息,如果所有执行器都返回yes,那么给所有执行器发生送commit消息,执行器收到commit后执行本地事务的commit操作;如果有任一个执行器返回no,那么给所有执行器发送abort消息,执行器收到abort消息后执行事务abort操作。

  注:TC或Si把发送或接收到的消息先写到日志里,主要是为了故障后恢复用。如某一Si从故障中恢复后,先检查本机的日志,如果已收到<commit >,则提交,如果<abort >则回滚。如果是<yes>,则再向TC询问一下,确定下一步。如果什么都没有,则很可能在<prepare>阶段Si就崩溃了,因此需要回滚。

  现如今实现基于两阶段提交的分布式事务也没那么困难了,如果使用Java,那么可以使用开源软件atomikos(http://www.atomikos.com/)来快速实现。

  不过但凡使用过的上述两阶段提交的同学都可以发现性能实在是太差,根本不适合高并发的系统。为什么?

  • 1)两阶段提交涉及多次节点间的网络通信,通信时间太长!
  • 2)事务时间相对于变长了,锁定的资源的时间也变长了,造成资源等待时间也增加好多!

  正是由于分布式事务存在很严重的性能问题,大部分高并发服务都在避免使用,往往通过其他途径来解决数据一致性问题。

3.1 如何可靠保存凭证(消息)

有两种方法:

3.1.1 业务与消息耦合的方式

  支付宝在完成扣款的同时,同时记录消息数据,这个消息数据与业务数据保存在同一数据库实例里。

Begin
 transaction

         update
 A set

amount=amount-10000

where userId=1;

         insert
 into message(userId, amount,status) values(1,
10000,
1);

End
 transaction

commit;

  上述事务能保证只要支付宝账户里被扣了钱,消息一定能保存下来。

  当上述事务提交成功后,我们通过实时消息服务将此消息通知余额宝,余额宝处理成功后发送回复成功消息,支付宝收到回复后删除该条消息数据。

3.1.2 业务与消息解耦方式

  上述保存消息的方式使得消息数据和业务数据紧耦合在一起,从架构上看不够优雅,而且容易诱发其他问题。为了解耦,可以采用以下方式。

    1)支付宝在扣款事务提交之前,向实时消息服务请求发送消息,实时消息服务只记录消息数据,而不真正发送,只有消息发送成功后才会提交事务;

    2)当支付宝扣款事务被提交成功后,向实时消息服务确认发送。只有在得到确认发送指令后,实时消息服务才真正发送该消息;

    3)当支付宝扣款事务提交失败回滚后,向实时消息服务取消发送。在得到取消发送指令后,该消息将不会被发送;

    4)对于那些未确认的消息或者取消的消息,需要有一个消息状态确认系统定时去支付宝系统查询这个消息的状态并进行更新。为什么需要这一步骤,举个例子:假设在第2步支付宝扣款事务被成功提交后,系统挂了,此时消息状态并未被更新为“确认发送”,从而导致消息不能被发送。

  优点:消息数据独立存储,降低业务系统与消息系统间的耦合;

  缺点:一次消息发送需要两次请求;业务处理服务需要实现消息状态回查接口。

3.2 如何解决消息重复投递的问题

  还有一个很严重的问题就是消息重复投递,以我们支付宝转账到余额宝为例,如果相同的消息被重复投递两次,那么我们余额宝账户将会增加2万而不是1万了。

  为什么相同的消息会被重复投递?比如余额宝处理完消息msg后,发送了处理成功的消息给支付宝,正常情况下支付宝应该要删除消息msg,但如果支付宝这时候悲剧的挂了,重启后一看消息msg还在,就会继续发送消息msg。

  解决方法很简单,在余额宝这边增加消息应用状态表,通俗来说就是个账本,用于记录消息的消费情况,每次来一个消息,在真正执行之前,先去消息应用状态表中查询一遍,如果找到说明是重复消息,丢弃即可,如果没找到才执行,同时插入到消息应用状态表(同一事务)。

for

each 
msg in

queue

  Begin
 transaction

    select
 count(*) as

cnt from message_apply where msg_id=msg.msg_id;

    if

cnt==0

then

      update
 B set

amount=amount+10000

where userId=1;

      insert
 into message_apply(msg_id) values(msg.msg_id);

  End
 transaction

  commit;

ebay的研发人员其实在2008年就提出了应用消息状态确认表来解决消息重复投递的问题:http://queue.acm.org/detail.cfm?id=1394128

补充:

  之前看多阿里大神程立的一个关于分布式事务的文档,目前使用较多的分布式事务解决方案有几种:   一、结合MQ消息中间件实现的可靠消息最终一致性   二、TCC补偿性事务解决方案   三、最大努力通知型方案   第一种方案:可靠消息最终一致性,需要业务系统结合MQ消息中间件实现,在实现过程中需要保证消息的成功发送及成功消费。即需要通过业务系统控制MQ的消息状态   第二种方案:TCC补偿性,分为三个阶段TRYING-CONFIRMING-CANCELING。每个阶段做不同的处理。         TRYING阶段主要是对业务系统进行检测及资源预留         CONFIRMING阶段是做业务提交,通过TRYING阶段执行成功后,再执行该阶段。默认如果TRYING阶段执行成功,CONFIRMING就一定能成功。         CANCELING阶段是回对业务做回滚,在TRYING阶段中,如果存在分支事务TRYING失败,则需要调用CANCELING将已预留的资源进行释放。   第三种方案:最大努力通知xing型,这种方案主要用在与第三方系统通讯时,比如:调用微信或支付宝支付后的支付结果通知。这种方案也是结合MQ进行实现,例如:通过MQ发送http请求,设置最大通知次数。达到通知次数后即不再通知。         具体的案例你也可以参考下这篇博客,它上面的这个案例就是结合电商支付做的系统分布式事务实现案例:http://www.roncoo.com/article/detail/124243

  基于事务消息的MQ方案是目前公认的较为理想的分布式事务解决方案,各大电商都在应用这一方案。种方式适合的业务场景广泛,而且比较可靠。不过这种方式技术实现的难度比较大。目前主流的开源MQ(ActiveMQ、RabbitMQ、Kafka)均未实现对事务消息的支持,所以需二次开发或者新造轮子。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏北京马哥教育

原创头条 | 如何让主机合规分析报告评分达到90分?

“胖猴,某大型企业高级运维,马哥教育原创作者联盟成员,热爱分享Linux应用技术和原创知识,有30万字以上的原创内容。” 说明:本次文档是根据某厂的主机合规分...

2975
来自专栏Flutter入门到实战

Flutter填坑全面总结

Flutter是一个新的跨平台开发的工具,博主也玩了一段时间,一步步的踩着坑摸石头过河,这其中受尽了各种各样的坑,各种谷歌,stackoverflow,Flut...

3902
来自专栏网站漏洞修补

解决网站漏洞防止网站被黑

网站被黑,打开网站竟然跳转到博cai网站上去了,一开始以为自己看错了,多次从百度点击自己网站进去,还是会跳转到彩piao网站上,第一反应是自己的网站被黑了,经营...

3383
来自专栏hadoop学习笔记

hadoop基础入门教程--DKHadoop配置安装教程

使用hadoop版本是DKH标准三节点发行版,DKHadoop版本的易用性比较好,环境部署要简单的多,参考此篇安装前请先下载DKHadoop版本,网盘链接:ht...

993
来自专栏简单聊聊Spark

搭建CM(ClouderaManager)

首先,为什么要搭建本地yum源呢?大部分公司里面,由于内网机不允许连接外网,所有导致不能通过网络的方式安装软件,而本地yarn源就是为了解决这个问题而诞生的一种...

1141
来自专栏Python爬虫与算法进阶

学习Git(二)基本操作

Git 基础操作 1. 创建版本库 什么是版本库呢?版本库又名仓库,英文名 repository,你可以简单理解成一个目录,这个目录里面的所有文件都可以被 G...

35912
来自专栏偏前端工程师的驿站

Java魔法堂:以Windows服务的形式运行Java程序

一、前言                               由于防止维护人员误操作关闭Java控制台程序,因此决定将其改造为以Windows服务的形式...

2596
来自专栏菩提树下的杨过

process information unavailable 的解决办法

有时候在centos上查看java进程时,会遇到process information unavailable 的情况,如下图: ? 不同账号之间kill进程时...

2259
来自专栏Web项目聚集地

PL/SQL Developer连接虚拟机数据库(图文详解)

Web项目聚集地的朋友求助关于PL/SQL Developer连接虚拟机Oracle数据库的教程,他说自己操作过程遇到很多错误,可以说操作中有很多注意的地方...

1502
来自专栏IMWeb前端团队

From svn to git 你要知道的东西

最近团队项目准备从svn往git迁,于是做了一些相关的了解,发现svn跟git还是有很多不一样的,下面写了一些个人理解。 核心区别 分布式 vs 集中式 git...

1955

扫码关注云+社区

领取腾讯云代金券