原文链接:http://www.jianshu.com/p/716d3ec567c0 问题的起源分布式系统的特性对分布式系统有过研究的读者,可能听说过“CAP定律”、“Base理论”等,非常巧的是,化学理论中ACID是酸、Base恰好是碱。这里我们不对这些概念做过多的解释,有兴趣的读者可以查看相关参考资料。 这里针对一致性我们做个简单的科普: 分布式事务有强一致,弱一致,和最终一致性这三种: 强一致
弱一致
最终一致
实例描述 比如有订单,库存两个数据,一个下单过程简化为,加一个订单,减一个库存。 而订单和库存是独立的服务,那怎么保证数据一致性。 这时候我们需要思考一下,怎么保证两个远程调用“同时成功”,数据一致? 请大家先注意一点远程调用最郁闷的地方就是,结果有3种,成功、失败和超时。 超时的话,成功失败都有可能。 一般的解决方案,大多数的做法是借助mq来做最终一致。 如何实现最终一致实例分析 我们是怎么利用Mq来达到最终一致的呢?下面让我们来一起进行详细的分析: 订单业务分析 首先,拿我们上面提到的订单业务举例: 在我们进行加订单的过程中同时插入logA(这个过程是可以做本地事务的) 复杂的混合异步业务调用那么我们通过上面的分析可能联想到这样的问题?
第一种情况:假设a,b,c三者都正常执行,那整个业务正常结束 第二种情况:假设b超时,那么需要a给b重发消息(记得b服务要做幂等),如果出现重发失败的话,需要看情况,是终端服务,还是继续重发,甚至人为干预(所有的规则制定都需要根据业务规则来定) 第三种情况:假设a,b,c三者之中的一个失败了,失败的服务利用MQ给其他的服务发送消息,其他的服务接收消息,查询本地事务记录日志,如果本地也失败,删除收到的消息(表示消息消费成功),如果本地成功的话,则需要调用补偿接口进行补偿(需要每个服务都提供业务补偿接口)。 注意事项
上面的话我们该怎么理解呢,举个例子吧: 比如A给B转账,A先自己扣钱,然后发了个消息,B这边如果在这之前销户了,那重试多少次也没用,只能人工干预。 阿里在分布式事务采用的解决方式阿里部分业务是用Mq实现了最终一致性,也有一部分业务用了tcc事务,但是tcc事务用的比较少,因为会侵染业务,开发成本比较高,如果体量不大的话直接用jta或mq支持事务就好,其实在分布式事务这一块还有一种最大努力型,也比较无脑的一种方式。 文/jsondream(简书作者) |
|