分布式事务梳理
分布式事务目前流行的方案也有很多种,网上能找到大把的技术文章,但看人家的文章总是有各种问题,要么某些地方不好理解,要么某些地方认为不正确,还是按自己的视角来梳理一下。
目前看到的方案,2PC,3PC,TCC,事务消息,本地消息表,等等。
一,2PC
多个数据库在同一个公司,同一个网段可访问到,以及数据库支持2PC,先对多个要提交的事务先发起预提交,多个库确认可以commit了之后,再发起确认commit,当然这个方案存在一些问题,前面说的前提是一些场景上的限制,场景适用后,在发起commit阶段仍然会有可能有不一致的可能性存在,后面会有3PC,同样也是解决了部分问题,无法最终解决一致性问题。
二,3PC
3PC是在2PC的基础之上,在commit又分成了2步,进一步减少数据不一致的可能性。
三,TCC
其实TCC和2PC原理基本一样,只是TCC是不同的资源可能在不同公司,采用不同的服务的方式,多个服务需要支持一个完整的事务,这时候2PC就不适用了,TCC相当于把每个需要事务控制的服务提供确认和取消的操作,这样,在发起事务前先预先锁住资源,待所有资源都确认可以获得,再发起确认操作,中间如有某一个资源预先获取失败,则会取消其它的资源的持有。
在一篇文章又看到解释TCC又分几种类型,通用型,补偿型,异步确保型。通用型也就是刚刚说到的这种,补偿型稍微有点不一样,只提供提交和撤回操作,异步确保型则引入MQ。
对于TCC方案,后面的确认环节同样存在一定的问题,会有不一致的可能性存在,这时候就需要一些超时机制,check机制来尽可能的自动确保事务的一致性,这些机制几乎能解决因网络抖动,服务暂时不可用或者down机后快速恢复等情况引发的问题,对于一些更严重的故障,甚至比如程序出了bug,无法恢复的情况,最终也只能引入人工来修复。
四,事务消息
刚才有提到引入MQ,对于发MQ和本地的操作如何能够保证一致性呢,这个就引出了事务消息的概念,普通的MQ无法保证消息发成功和本地的业务的完全一致性,为了这个目标,在MQ系统中引用2PC的方案,先提交一次消息,然后执行业务,完成之后再次提交一次确认消息,对于没有收到确认的消息,定时轮询回查业务方,或者定期删除。
五,事务消息-本地消息表
有文章提到ebay的一个实现方案,本地消息表来保证本地事务,然后再需要一个timer来轮询本地消息表,检查没有投递成功的消息重复调用发送。如果没有RocketMQ这种支持事务的MQ,可以选用此方案,对业务的入侵较大,不易复用。
基于消息的最终一致方案,目的是保证本地操作和消息发送成功作为一个事务保证一致性。如果消费者端的业务执行成功与否会影响到消息生产者端,则还需要一个回调来报告消费端的成功与失败。
六,Paxos
Zookeeper使用的一致性算法,据说真正的解决了一致性问题,稍后再看。
七,
没有名字,但各大厂都提供的支付接口,与调用方本地的事务需要保证的一致性,我认为这也是解决分布式事务的一个很好的方案。
调用方先创建本地订单,然后调用支付接口,拿到结果后更新本地订单。
针对本地订单已经创建,但是没有拿到支付结果的订单,重复调用支付,支付接口根据调用方的orderid唯一来做幂等。
支付服务方还会定时调用回调接口报告支付成功与失败,来保证事务的一致性和完整性,定时调用本地接口。
如果本地重试和支付宝重试均失败,那就需要人工介入。
对于遇到的一些场景进行分类的话,可以有几个维度的划分
需要回滚,比如订中转的机票,适合用TCC的方案
不需要回滚,比如单纯的支付场景,比如随主业务一起发通知的场景,只需要保证最终能够成功或者到达即可,更适合采用事务消息的方案
这里认为退票和退款这两种情况不属于回滚,属于另起的一个单独的事务
实时一致性,必须强一致,实时看到效果,在线等的场景
最终一致性,允许延迟,只要求最终一致即可,上面的方案七
允许少量不一致的业务,偶尔也会来凑热闹,这个就不属于分布式事务了
基于跨数据库的分布式事务,同一服务内的跨库场景,适用2PC或者3PC
基于跨服务的分布式事务,上面说的场景大多数属于这一类,仍需具体看场景来使用TCC或者事务消息等
分布式消息,本地事务与消息的一致,通常针对不需要回滚的,允许非实时一致的,可选用此方案
再回顾一下对这几个方案的理解,本质的原理几乎是一样的,都需要双方确认,以及提供do和undo操作,以及最终的人工处理。
每次我在遇到不好理解,或者不好解决的问题的时候,都会把这个场景拿到现实生活中找类似的场景,打个比方说吧,就说刚才的订中转机票的场景,现在放到现实中找例子,比如有一个客户需要从订票代理A手里购买航空公司B和航空公司C的票,代理A打电话给B,问票还有么,有的话给自己留一会,如果没有,此次订票失败,代理A再打电话给C问票还有么,有的话给自己留一会,没有的话再回过来告诉A刚才那个票不要了,如果两方都有,就打电话告诉B,票我确定要了,然后再打电话告诉C,票我要了,正常事务就完事了,可是A再最后给C打电话的时候,电话打不通了,联系不上C,那会怎么办,A会一直重试再打几次电话,直到打通为止,正常情况下,不会一直打不通,真遇到了极端情况,C公司系统坏了,票买不了了,航班取消了等等,那也只能有一方赔付事务中断导致的损失,这些永远也无法用一个事务完成的了的,对于前面的正常情况,都是可以用事务来处理。
相关概念
事务,分布式事务
评论
发表评论