场景

转账扣款的场景

分布式事务一致性问题解决方案

  1. 基于base理论，保证最终一致性；

  2. 2pc协议, 存在问题：
    a) 但因为2pc协议调用链比较长，会持续占用资源，所以在高并发场景下存在性能问题的；
    b) 对于互联网公司微服务化架构，整个链路会涉及多个部门的多个服务，如果整个链路8个步骤，7个成功，最后一个失败了，此 时如果回滚前面7个服务，开销是很大的，不现实；

  3. TCC补偿性事务
    Try、Confirm、Cancel可以理解为SQL事务中的Lock、Commit、RollBack阶段TCC必须依赖各阶段（Try/Confirm/Cancel）的本地事务的原子性和一致性来实现全局事务的原子性和一致性。
    Cancel阶段可以是利用数据库的RollBack完成回滚，也可以是提供回滚接口实现。

    缺点：
    耦合性高、非常有局限性，因为有很多的业务是无法很简单的实现回滚的，如果串行的服务很多，回滚的成本实在太高。
    ByteCode: http://www.bytesoft.org/

  4. 业界比较常用的方案是：可靠消息最终一致性，保证最终一致性，需要解决核心问题：

    a) 如何可靠的保存原始消息凭证？ 利用本地事务，依靠业务和消息耦合，在做业务update的时候添加message表记录；

b) 如何保证消息重复投递？ 本地业务添加消息消费状态表；

经典方案：

  1. eBay 模式；

  2. 美团点评订单中心；https://wiki.sankuai.com/pages/viewpage.action?pageId=671371431

  3. 蘑菇街；

  4. 阿里分布式事务服务｜ DRD

    [https://wiki.sankuai.com/pages/viewpage.action?pageId=101702603](https://wiki.sankuai.com/pages/viewpage.action?pageId=101702603)

 [https://wiki.sankuai.com/pages/viewpage.action?pageId=101702603&preview=%2F101702603%2F101618274%2F\[1\]+阿里分布式数据库服务原理与实践.pdf](https://wiki.sankuai.com/pages/viewpage.action?pageId=101702603&preview=%2F101702603%2F101618274%2F[1]+阿里分布式数据库服务原理与实践.pdf)

学习博客：http://www.cnblogs.com/lzyGod/p/5558474.html

results matching ""

    No results matching ""