5.1 从一致性开始

事务存在的意义就是保证系统中不同数据间不会产生矛盾，数据修改后的结果是我们期望的，也就是保证数据状态的一致性（Consistency）。

想要达成数据状态的一致性，需要三个方面的努力：

• 原子性（Atomic）：原子化更新。业务操作要么全部完成, 要么全都不做，不容忍中间状态。
• 隔离性（Isolation）：在不同的业务处理过程中，事务保证了各自业务正在读、写的数据互相独立，不会彼此影响。
• 持久性（Durability）：业务数据不会丢失。事务结束后，除非数据被其他业务更新，否则不应该有变化。

这也就是常说的事务的 ACID 特性，不过笔者这里额外提一点，事实上 ACID 这四种特性并不正交，A、I、D 是手段，C（Consistency）是三者协作的目标，弄到一块完全是为了读起来顺口。

当事务的影响范围局限在单机本地内的系统时，一致性通过编码实现起来水到渠成，但倘若事务修改的对象影响涉及外部，例如跨节点、跨越网络影响时，一致性问题通常很难再使用 A、I、D 来解决，但是外部一致性又是分布式系统中必然会遇到且必须要解决的问题，此时我们就要转变观念，将一致性从“是或否”的二元问题转变为可以按不同强度分开讨论的多元问题，在确保代价可承受的前提下获得强度尽可能高的一致性保障。

一致性强弱的程度关乎系统设计权衡，由此事务处理从一个具体操作上的“编程问题”而转变成一个需要全局权衡的“架构问题”。人们在探索这些架构的设计时产生了诸多思路和理论，下一篇我们就来看看分布式系统中最为出名的权衡理论 -- CAP 定理。