【较真儿】事务特性及场景演化：

聊聊事务

什么是事务？
答：事务源自于数据库管理系统（DBMS），是执行过程里一个由一系列操作组成的一个不可分割的工作序列。

事务存在的意义是什么？
答：保证数据库的完整性和一致性，即使在错误或系统奔溃的情况下也能保证数据正确。

ACID特性

讲到事务，就跳不开ACID四大特性：

• A（原子性）：在一个事务内，对多个数据的操作的结果只有一种，要么全部成功，要么全部撤销，不存在中间状态。
• C（一致性）：事务保证数据库从一个一致性状态转换到另一个一致性状态。事务的执行结果必须满足所有的完整性约束（包括：数据的实体完整性、参照完整性和用户定义完整性等）。
• I（隔离性）：并发执行的事务之间，各事务内部的读写操作都是独立的，互不干扰。
• D（持久性）：事务被提交之后，就会持久化，即使系统故障也不会丢失。

简要总结，C 是事务存在的意义，是目的；A、I、D是手段。

保证A、I、D就能达到C吗？

答案是：否定的。

上面我们已经了解了一致性的定义：

一致性要求数据库从一个一致性状态转换到另一个一致性状态。

这里的一致性状态要求：数据库中的数据满足所有的完整性约束（如主键约束、外键约束、检查约束等）。

A、I、D确保了事务的完整性，但并未直接定义或验证这些约束。
为了确保一致性，数据库系统还需要实现其他机制，如触发器、约束检查、并发控制算法等。
这些机制与A、I、D特性一起工作，共同维护数据库的一致性。

因此，虽然A、I、D是确保数据库一致性的重要基石，但它们本身并不足以完全保证C的实现。
数据库系统需要综合运用这些特性以及其他机制来确保数据的一致性和完整性。

事务应用场景的演变：

上面是最最开始对事务的定义，而随着数据存储方式的演变，事务的概念已经不在局限于数据库内部。

所有需要保证数据一致性的场景，都会用到事务。这些场景包括但不限于：

• 数据库
• 事务内存
• 缓存
• 消息队列
• 分布式存储

场景的增多也带来了事务和一致性含义上的变化。

一致性的要求也衍生出新的概念：

• 内部一致性：
  • A、I、D 加上其他的一些约束机制就能解决一致性问题
  • 是否满足一致性，只有是或否
  • 主要是在编程层面考虑
• 外部一致性：
  • 很难用A、I、D解决一致性问题
  • 不再只有是和否两种选择，而是多维度的判断是否满足一定程度的一致性
  • 上升到了架构层面考虑

外部一致性，是在分布式环境中必然会遇到且必须解决的问题。通过付出一定的代价，保证系统尽可能高的一致性保证。