数据库事务--开篇介绍(1)
事务的定义
百度百科：
事务（Transaction），一般是指要做的或所做的事情。在计算机术语中是指访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。
百科的描述是很模糊的，不过事务的本身确实仅仅指的一些程序操作，只不过这些操作具备 ACID 特性。于是，我们可以将事务定义为具备 ACID 特性的多个程序执行指令。
我们以小明向小红转账 100 元为例说明这几个特性。对于转账操作，可以拆分为两个步骤：
- 小明账户减去 100 元
- 小红账户加上 100 元
这两个步骤合起来称为一个事务。
A-原子性
事务中的操作要么全部成功，要不全部失败。
对于转账操作，要么成功转账，要么失败。不存在小明账户扣完 100 元，而小红账户没变化。
C-一致性
一致性是指一个业务操作完成，存储系统中的数据符合业务操作的预期结果。不存在中间状态。
对于转账这个业务操作，操作成功就是小红账户和小明账户分别加减 100 元，失败就是账户没有变化。这两种都符合对于业务操作的预期结果，都满足了一致性要求。
I-隔离性
多个事务之间不能互相干扰。
假如小军也给小红转了 100 元，那么这两个转账操作的最终结果就是小红账户多了 200 元，不能因为并行执行而影响最终结果。
隔离性因为涉及到了并发操作，比较复杂，根据不同的隔离级别可以分为串行化，可重复读，读已提交，读未提交。这些隔离级别的实现后续会分析的。
D-持久性
事务提交后，它的改变就是永久性的，后续的操作和故障不会对其造成影响。
简单理解就是数据落盘了，内存会因为机器断电而丢失数据，但磁盘不会。
我的理解
AID 是特性，C 是目的。MySQL 为 AID 特性做了大量的设计工作，而 C 正是这些特性带来的最终效果。
事务的意义
事务对一个健全后端服务非常重要。传统的讲究一个 ACID，不过，事务的本质也就是提供了一个 C。数据一致性很重要，如果资源成本足够低的话，所有的后端服务都能保持一致性是大家都愿意做的事情。
那么一致性面对的问题有什么呢？
- 高并发场景，有可能会丢失变更等一系列不符合原有逻辑的情况
- 机器不可靠，网络不可靠，一切服务的基础组件都不可靠，随时面临崩溃
事务，就是用来解决这两个问题的。隔离性解决了高并发场景问题，原子性和持久性解决基础组件不可靠的问题。
NoSql 无法替代传统关系型数据库的关键原因，也是它无法提供事务特性。像 redis 的事务都是一些不完整的事务，压根保证不了一致性。
总结
事务的本质是保证数据的一致性。
能提供一致性的事务固然强大，但是否要使用还是要根据业务场景的，如果 qps 特别高，是否真的有需求保证数据一致性就真的要好好考虑了，这个成本可不低。
后续的文章会开始介绍 AID 在 MySQL 中是如何实现的。