CAP理论

说到分布式事务,必须提到的就是CAP理论,即同时满足“CAP定律”中的“一致性”、“可用性”和“分区容错性”三者是不可能的;大多数的场景,都需要牺牲强一致性来换取系统的高可用性,系统往往只需要保证“最终一致性”,只要这个最终时间是在用户可以接受的范围内即可;阿里云好像有一个GTS分布式事务框架,是做强一致性的,目前行业还未看到有做强一致性方案。

两阶段提交

提到分布式系统,必然要提到分布式事务。要想理解分布式事务,不得不先介绍一下两阶段提交协议。拿网上的一个例子来说明:
第一阶段,张老师作为“协调者”,给小强和小明(参与者、节点)发微信,组织他们俩明天8点在学校门口集合,一起去爬山,然后开始等待小强和小明答复。
第二阶段,如果小强和小明都回答没问题,那么大家如约而至。如果小强或者小明其中一人回答说“明天没空,不行”,那么张老师会立即通知小强和小明“爬山活动取消”。
这时候会发现,这个过程中可能有很多问题的。如果小强没看手机,那么张老师会一直等着答复,小明可能在家里把爬山装备都准备好了却一直等着张老师确认信息。更严重的是,如果到明天8点小强还没有答复,那么就算“超时”了,那小明到底去还是不去集合爬山呢?这就是两阶段提交协议的弊病,所以后来业界又引入了三阶段提交协议来解决该类问题,当然这不是两阶段提价的最重要问题,最重要的两阶段有个预提交的阶段,非常影响性能,这在讲究用户体验至上的情况下,基本不能容忍的。

最终一致性解决方案

既然不能容忍强一致性带来的性能问题,那肯定是要最终一致性来保证事务和数据的一致性了,而且这也是目前行业内比较流行的解决方案,但由于各行各业业务千差万别,所以目前仍然没有一个万能方案来适应各个公司各个业务场景,我看过支付宝、蘑菇街、乃至其他同行分享的方案,都有公司很深的烙印。最终一致性的原理,即是规避开分布式事务的强一致性,在可能出现不一致场景的情况下,允许出现一段时间的数据不一致,但经过处理,最终系统整体的数据是准确的是符合一致性的。实现这种最终一致性方案,有基于补偿、基于消息的、基于tcc的,但万变不离其宗,基本都是对rpc调用过程进行结果确认,再通过反向处理服务保证最后数据的准确性。

亚信落地方案

作为服务运营商的解决方案(运营商解决方案一般以省为单位,该方案为浙江移动),就以手机运营商这边很重要的一个场景为例,用户有1000积分,可以兑换100M流量,而扣减用户1000积分和给用户送100M流量分属2个系统(和实际情况不完全一致,仅举例说明),需要调用2次rpc服务,一旦扣减积分成功,但兑换流量因为业务或者超时等业务或系统异常,流量这一步的调用失败,而这时候1000积分已经扣减掉了,系统发现这个问题,则需要将1000积分重新给用户加上,这部分功能由拦截器发现集成到客户端的jar里面,然后对调用情况进行落表,记录下调用2次rpc过程的成功和失败,出现不一致的时候,发送消息给积分系统,由积分系统来将扣减的1000积分重新加上,流程见下图(小陶提供):

总结

分布式事务的解决方案必须根据业务的实际情况来考虑,同时衍生出一系列问题,比如消息的丢失、重复,反撤的性能如何等等,都是需要考虑的问题,里面的内容仍需要不断完善。