一、事务的三种基本类型
1.1 基于XA协议的两阶段提交
XA是一个分布式事务协议，由Tuxedo提出。XA中大致分为两部分：事务管理器和本地资源管理器。
其中本地资源管理器往往由数据库实现，比如Oracle、DB2这些商业数据库都实现了XA接口，而事务管理器作为全局的调度者，负责各个本地资源的提交和回滚。XA实现分布式事务的原理如下：
全局事务方式下，全局事务管理器（TM）通过XA接口使用二阶段提交协议（2PC）与资源层（如数据库）进行交互。使用全局事务，数据被Lock的时间跨整个事务，直到全局事务结束。
2PC是反伸缩模式，在事务处理过程中，参与者需要一直持有资源直到整个分布式事务结束。这样，当业务规模越来越大的情况下，2PC的局限性就越来越明显，系统可伸缩性会变得很差。
优点：比较简单，而且一旦商业数据库实现了XA协议，使用分布式事务的成本也比较低。
缺点：
性能不理想，特别是在交易下单链路，往往并发量很高，XA无法满足高并发场景。
mysql数据库中支持的不太理想，mysql的XA实现，没有记录prepare阶段日志，主备切换回导致主库与备库数据不一致。许多nosql也没有支持XA，这让XA的应用场景变得非常狭隘。
2.2 消息事务+最终一致性
基于消息中间件的两阶段提交，本质上是对消息中间件的一种特殊利用，它是将本地事务和发消息放在了一个分布式事务里，保证要么本地操作成功成功并且对外发消息成功，要么两者都失败，开源的RocketMQ就支持这一特性，具体原理如下：
1、A系统向消息中间件发送一条预备消息
2、消息中间件保存预备消息并返回成功
3、A执行本地事务
4、A发送提交消息给消息中间件
通过以上4步完成了一个消息事务。对于以上的4个步骤，每个步骤都可能产生错误，下面一一分析：
步骤一出错，则整个事务失败，不会执行A的本地操作
步骤二出错，则整个事务失败，不会执行A的本地操作
步骤三出错，这时候需要回滚预备消息，怎么回滚？答案是A系统实现一个消息中间件的回调接口，消息中间件会去不断执行回调接口，检查A事务执行是否执行成功，如果失败则回滚预备消息
步骤四出错，这时候A的本地事务是成功的，那么消息中间件要回滚A吗？答案是不需要，其实通过回调接口，消息中间件能够检查到A执行成功了，这时候其实不需要A发提交消息了，消息中间件可以自己对消息进行提交，从而完成整个消息事务
优点：往往用在高并发场景下，将一个分布式事务拆成一个消息事务（A系统的本地操作+发消息）+B系统的本地操作；如果A成功，而B不成功，消息会重投，直到B操作成功，这样就变相地实现了A与B的分布式事务。
缺点：A和B并不是严格一致的，而是最终一致的，我们在这里牺牲了一致性，换来了性能的大幅度提升。如果B一直执行不成功，那么一致性会被破坏。
1.3 TCC编程模式
两阶段提交的一个变种。
TCC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。
以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。
总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。
1.4 总结
分布式事务，本质上是对多个数据库的事务进行统一控制，按照控制力度可以分为：不控制、部分控制和完全控制。不控制就是不引入分布式事务，部分控制就是各种变种的两阶段提交，包括上面提到的消息事务+最终一致性、TCC模式，而完全控制就是完全实现两阶段提交。部分控制的好处是并发量和性能很好，缺点是数据一致性减弱了，完全控制则是牺牲了性能，保障了一致性，具体用哪种方式，最终还是取决于业务场景。
脏读/幻读/不可重复读/更新丢失
针对隔离性，隔离级别从宽松到严格：
未提交读 read uncommitted →提交读 read committed → 可重复读 repeateable reads → 可串行化 serializable
从用词上看， dynamodb的事务应该采取的是 serializable
这种加锁方式，保证了可以并发读取数据，但是不能同时修改表中数据，而且有写操作的时候，读操作只能等待写操作事务结束。以及，有读操作的时候，写操作也只能等待事务结束。也就是说，所有的写操作事务都是线性操作的，相当于单线程操作，同时只会有一个写事务存在，这样就绝对避免了幻读问题，因为事务期间不会有新增操作。
简单形容： 这种隔离级别是锁表的，所以性能相当低下。
三、其他概念
3.1 CAP
3.1.1 一致性（Consistency）
数据操作之后如何保持一致状态。
3.1.2 可用性（Availability）
高可用性意味着，当集群中的节点崩溃或一些硬件或软件部件由于升级而关闭的时候，系统仍然可以以某种方式继续运行（即允许读写操作），不要求全部可用，允许部分可用。
3.1.3 分区容错性（Partition Tolerance）
存在网络分区（网络孤岛，彼此无法连接）的时候，整个系统仍然可以继续运行。也可以理解为节点添加或者删除的时候，系统仍然可用。
3.2 BASE
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的。
BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
接下来看一下BASE中的三要素：
3.2.1 基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性-注意，这绝不等价于系统不可用。
比如：
（1）响应时间上的损失。正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
（2）系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
3.2.2 软状态
软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时
3.2.3 最终一致性
最终一致性强调的是所有的数据副本，在经过一段时间的同步之后，最终都能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
总的来说，BASE理论面向的是大型高可用可扩展的分布式系统，和传统的事物ACID特性是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的分布式系统架构设计过程中，ACID特性和BASE理论往往又会结合在一起。
3.3 如何进行CAP和BASE系统之间的权衡：
如果一个系统要求强一致和分区容错的，ACID特性是必需的；
如果一个系统可用性和分区容错性比一致性更重要，由此产生的系统可以BASE属性来设计特征。
网友评论