说到事务，可能大家首先想到的就是数据库事务。对于数据库事务可能大家都很熟悉，在开发过程中也会经常使用到。众所周知，数据库能实现本地事务，但现在的系统常采用微服务、SOA等架构，因此就出现了跨多个数据库的事务需求，这种事务即为“分布式事务”。
分布式事务一直是企业集成中的一个技术难点，也是每一个分布式系统架构中都会涉及到的一个东西，特别是在微服务架构中，几乎可以说是无法避免，本文就分布式事务来简单聊一下。
事务的具体定义
事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。简单地说，事务提供一种“要么什么都不做，要么做全做（All or Nothing）”机制。
数据库事务
数据库事务（简称：事务，Transaction）是指数据库执行过程中的一个逻辑单位，由一个有限的数据库操作序列构成。
说到数据库事务，就不得不提一下事务著名的四大特性。
- A:原子性(Atomicity) 事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。
- C:一致性(Consistency) 事务在开始前和结束后，数据库的完整性约束没有被破坏。
- I:隔离性(Isolation) 事务的执行是相互独立的，它们不会相互干扰，一个事务不会看到另一个正在运行过程中的事务的数据。
- D:持久性(Durability) 一个事务完成之后，事务的执行结果必须是持久化保存的。即使数据库发生崩溃，在数据库恢复后事务提交的结果仍然不会丢失。
注意：事务只能保证数据库的高可靠性，即数据库本身发生问题后，事务提交后的数据仍然能恢复；而如果不是数据库本身的故障，如硬盘损坏了，那么事务提交的数据可能就丢失了。这属于『高可用性』的范畴。因此，事务只能保证数据库的『高可靠性』，而『高可用性』需要整个系统共同配合实现。
具体关于事务的四种隔离级别之类的这里不再展开，有兴趣可以搜索一下相关资料。不过有一个知识点我们需要了解，就是假如数据库在提交事务的时候突然断电，那么它是怎么样恢复的呢？ 为什么要提到这个知识点呢？ 因为分布式系统的核心就是处理各种异常情况，这也是分布式系统复杂的地方，因为分布式的网络环境很复杂，这种“断电”故障要比单机多很多，所以我们在做分布式系统的时候，最先考虑的就是这种情况。
分布式理论
本地事务主要限制在单个会话内，不涉及多个数据库资源。但是在基于微服务、 SOA（Service-Oriented Architecture，面向服务架构）的分布式应用环境下，越来越多的应用要求对多个数据库资源，多个服务的访问都能纳入到同一个事务当中，再想保证集群的ACID几乎是很难达到，或者即使能达到那么效率和性能会大幅下降，最为关键的是再很难扩展新的分区了，这时我们就需要引入一个新的理论原则来适应这种集群的情况，就是 CAP 原则，那么CAP原则指的是什么呢？
CAP原则
又称CAP定理，是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务无法同时满足以下3个属性：
- 一致性(Consistency) ： 在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）
- 可用性(Availability) ： 在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
- 分区容错性(Partition tolerance) ： 以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。
CAP理论中说三者不可兼得，但实际情况是，在分布式场景中分区一定存在，也就必须要有分区容忍性对应的策略，之后才能在一致性和可用性间二者之间选择。所以对主流架构来说不是三选二，而是二选一。
BASE理论
在分布式系统中，我们往往追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？ 前人已经给我们提出来了另外一个理论，就是BASE理论，它是用来对CAP定理进行进一步扩充的。BASE理论指的是：
- Basically Available（基本可用）
- Soft state（软状态）
- Eventually consistent（最终一致性）
BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：我们无法做到强一致，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
本文参考 -Savorboard