分布式事务框架
现有分布式处理方案
一致性理论基石： ACID本地事务 XA协议：2PC、3PC CAP理论 BASE理论
数据一致性分为三个种类型：强一致性，弱一致性以及最终一致性
一致性模型，数据的一致性模型可以分成以下3类：
强一致性：数据更新成功后，任意时刻所有副本中的数据都是一致的，一般采用同步的方式实现。
弱一致性：数据更新成功后，系统不承诺立即可以读到最新写入的值，也不承诺具体多久之后可以读到。
最终一致性：弱一致性的一种形式，数据更新成功后，系统不承诺立即可以返回最新写入的值，但是保证最终会返回上一次更新操作的值。
数据库实现的就是强一致性，能够保证在写入一份新的数据库，立即使其可见。
最终一致性是弱一致性的强化版，系统保证在没有后续更新的前提下，系统最终返回上一次更新操作的值。在没有故障发生的前提下，不一致窗口的时间主要受通信延迟，系统负载和复制副本的个数影响。
微服务作为分布式系统，同样受 CAP[1] 原理的制约，在 CAP 理论中， C：Consistency、A：Availability、P：Partition tolerance 三者不可同时满足，而服务化中，更多的是提升 A 以及 P，在这个过程中不可避免的会降低对 C 的要求，因此，BASE 理论随之而来。
BASE[2] 理论来源于 ebay 在 2008 年 ACM 中发表的论文，BASE 理论的基本原则有三个：Basically Available，Soft state，Eventually consistent，主要目的是为了提升分布式系统的可伸缩性，论文同样阐述了如何对业务进行调整以及折中的手段，BASE 理论的提出为分布式事务的发展指出了一个方向。
在最终一致性的实现过程中，最基本的操作就是保证事务参与者的幂等性，所谓的幂等性，就是业务方能够使用相关的手段，保证单个事务多次提交依然能够保证达到同样的目的。
ACID本地事务：强一致性
现有成熟的分布式解决方案包括XA两阶段提交、可靠消息与TCC模式等类型。XA两阶段提交属于强一致事务，可靠消息与TCC模式属于柔性事务。
XA协议：2PC、3PC：XA两阶段提交，2PC两阶段提交（2PC, Two-phase Commit）方案、三阶段提交协议 3PC---强一致性 2PC二阶段提交方案：强一致性 3PC三阶段提交
TCC事务,TCC模式（Try-Confirm-Cancel）补偿模式---最终一致性
可靠本地消息表：最终一致性
MQ事务：最终一致性
Saga事务：最终一致性
saga的具体实现分为两种：Choreography（编排）以及 Orchestration（编配）
参考 关于分布式事务，XA协议的学习笔记 RocketMQ 4.3正式发布，支持分布式事务
编制（orchestration）和编排（choreography）是常用于描述“合成Web服务的两种方式”的术语。
虽然它们有共同之处，但还是有些区别的。
Web服务编制（Web Services Orchestration，WSO）指为业务流程（business processes）而进行Web服务合成，
而Web服务编排（Web Services Choreography，WSC）指为业务协作（business collaborations）而进行Web服务合成。
SOA中的两个概念：编制（orchestration）和编排（choreography） WS中Orchestration和Choreography的含意 Choreography vs Orchestration 编配和编排的定义之争 Web服务聚合中的Orchestration和Choreography Microservices Choreography vs Orchestration: The Benefits of Choreography 微服务协调与编排：协调的好处
事务的隔离级别： 数据库的四种隔离级别：脏读、不可重复读、幻读
Read uncommitted 读未提交 在该级别下，一个事务对一行数据修改的过程中，不允许另一个事务对该行数据进行修改，但允许另一个事务对该行数据读。 因此本级别下，不会出现更新丢失，但会出现脏读、不可重复读。
Read committed 读提交 在该级别下，未提交的写事务不允许其他事务访问该行，因此不会出现脏读；但是读取数据的事务允许其他事务的访问该行数据，因此会出现不可重复读的情况。
Repeatable read 重复读 在该级别下，读事务禁止写事务，但允许读事务，因此不会出现同一事务两次读到不同的数据的情况（不可重复读），且写事务禁止其他一切事务。
Serializable 序列化 该级别要求所有事务都必须串行执行，因此能避免一切因并发引起的问题，但效率很低。
分布式事务中间件Seata的设计原理
https://seata.io/zh-cn/ https://github.com/seata/seata https://github.com/seata/seata-samples
https://seata.io/zh-cn/docs/overview/what-is-seata.html https://github.com/seata/seata/wiki/%E6%A6%82%E8%A7%88
Fescar 的发展历程 阿里是国内最早一批进行应用分布式（微服务化）改造的企业，所以很早就遇到微服务架构下的分布式事务问题。
2014 年，阿里中间件团队发布 TXC（Taobao Transaction Constructor），为集团内应用提供分布式事务服务。
2016 年，TXC 经过产品化改造，以 GTS（Global Transaction Service） 的身份登陆阿里云，成为当时业界唯一一款云上分布式事务产品，在阿云里的公有云、专有云解决方案中，开始服务于众多外部客户。
2019 年起，基于 TXC 和 GTS 的技术积累，阿里中间件团队发起了开源项目 Fescar（Fast & EaSy Commit And Rollback, FESCAR），和社区一起建设这个分布式事务解决方案。
TXC/GTS/Fescar 一脉相承，为解决微服务架构下的分布式事务问题交出了一份与众不同的答卷。
参考 https://www.sofastack.tech/blog/seata-distributed-transaction-deep-dive/ http://jm.taobao.org/2017/04/27/20170427/ https://juejin.im/post/5d2616256fb9a07eef6a3619 https://cloud.tencent.com/developer/article/1463287 https://www.kubernetes.org.cn/5603.html https://yq.aliyun.com/articles/334238
JDTX是由京东数科的数据研发团队倾力打造的分布式事务中间件
参考 http://blog.itpub.net/31556440/viewspace-2662840/
分布式事务：中间件方案
TX-LCN https://www.txlcn.org/zh-cn/
atomikos https://www.atomikos.com/ 开源类事务管理器
GTS https://www.aliyun.com/aliware/txc?spm=5176.8142029.388261.386.a72376f4lqvQxv 全局事务服务（Global Transaction Service ，简称GTS）用于实现分布式环境下高性能事务一致性。
FESCAR （推荐） 现在改名字，是分布式事务中间件Seata
https://github.com/wxbty/meepo
http://www.iocoder.cn/categories/TCC-Transaction/
可靠消息分布式事务中间件 https://gitee.com/silk7/shine-mq
参考 https://blog.csdn.net/fly910905/article/details/87356755 https://www.zhihu.com/question/64921387
Last updated
Was this helpful?