事务的ACID
在关系数据库中，一个事务通常由多个 sql 语句组成。
原子性（A）保证每个事务都被视为一个完整的单元，要么全成功，要么全失败。如果构成事务的某个 sql 未能完成，则整个事务失败，数据库保持事务开始之前的状态，通常通过 undo log 实现。
一致性（C）确保事务只能将数据库从一种有效状态带到另一种有效状态，维护数据库不变性，例如有在有外键约束的情况下，无法从数据库中删除一条被另外一个表引用的记录。
隔离性（I）是指在并发执行事务的情况下能获得和顺序执行事务相同的状态，根据具体的实现细节可以分为不同的隔离级别。
持久性（D）保证一旦事务被提交，即使在系统故障的情况下它也将保持提交后的状态，通常通过 redo log 实现。
全局事务
随着互联网的发展，系统架构从早期单体架构慢慢演化到了分布式架构。之前关系数据库事务包含的多个 sql 语句，随着分布式系统的出现，会在多个物理节点上执行。此时便出现了全局事务。全局事务的定义是一种适用于单个服务使用多个数据源场景的事务解决方案，本质上是在分布式系统中追求一致性的处理方案
一种解决分布式环境下一致性的方法是两阶段提交。
分布式事务
分布式也从单服务访问多数据源变成了多服务访问多数据源。
Consistency 一致性代表数据在任何时刻、任何分布式节点中所看到的都是符合预期的。
Availability 可用性代表系统不间断地提供服务的能力。
Partition tolerance 分区容错性代表分布式环境中部分节点因网络原因而彼此失联后，系统仍能正确地提供服务的能力。
三者只能满足其二
区别
在分布式环境中达成一致性需要通过共识算法，分布式共识算法的基本思路就是少数服从多数。
如果说ACID的C是节点服务器的数据完整性，而CAP的一致性是分布式多服务器之间复制数据以取得这些服务器拥有同样的数据，这是一种分布式领域的一致性概念。因此两者是完全不同的概念。
分布式一致性是作为分布式系统整体对外表现为一个一致性的系统，而其内部节点之间可能存在差异
此时，分布式系统的一致性和之前的一致性在概念上有较大的差别，因此大家对一致性重新做了定义，将之前的一致性叫做强一致性，此时的一致性叫做最终一致性，同时也将之前的事务叫做刚性事务，此时的事务叫做柔性事务。
还有一种形象的比喻就是，ACID的C与CAP的C的关系类似精确与一致性的关系：
