分布式事务的基本知识

分布式事务的基础知识
1.产生背景
分布式事务的产生其实是相对本地事务而言的，在之前的章节关于事务的ACID特性以及事务隔离级别做了详细的解说，再加上数据库的redo和undo特性使得本地事务的处理变得简单。然而随着分布式应用的不断增加，本地事务的那一套理论已经不能适应分布式事务的应用场景，最本质的原因就是因为本地事务是在同一个进程、同一个数据库种进行，而对于分布式应用来说一个事务的产生涉及到了多个数据库和多个进程，使得分布式事务难以控制。分布式事务的最主要的问题就是数据的不一致性，所以目前大家讨论的关于分布式事务的问题其本质也是为了保证数据的一致性。
2.常用的理论
2.1 CAP理论
CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足一下3个属性：
一致性(Consistency) ： 客户端知道一系列的操作都会同时发生(生效)
可用性(Availability) ： 每个操作都必须以可预期的响应结束
分区容错性(Partition tolerance) ： 即使出现单个组件无法可用,操作依然可以完成
具体地讲在分布式系统中，在任何数据库设计中，一个Web应用至多只能同时支持上面的两个属性。显然，任何横向扩展策略都要依赖于数据分区。因此，设计人员必须在一致性与可用性之间做出选择。关于这个理论的证明可以自行百度，网上有许多相关资料。
2.2 BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结， 是基于CAP定理逐步演化而来的。BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。接下来看一下BASE中的三要素：
1、基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性----注意，这绝不等价于系统不可用。比如：
（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
2、软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
3、最终一致性
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起
3总结
总的来说分布式事务是由于分布式架构导致的，在进行单体项目的开发时我们根据事务的ACID特性可保证数据的强一致性，当采用分布式架构时可能导致分布式事务问题，目前解决分布式事务问题大致有4种常用方案，两阶段提交、TCC补偿、可靠消息异步确保、最大努力通知，在后面的章节将详细介绍。
参考链接：
https://www.cnblogs.com/aigongsi/archive/2012/10/11/2718313.html
https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
https://www.cnblogs.com/monkeyblog/p/10449363.html
https://www.cnblogs.com/szlbm/p/5588543.html