基础概念 - 分布式事务面试题
事务大家应该都知道，事务将一组操作纳入到一个不可分割的执行单元，这个执行单元里的操作都成功时才能提交成功。
简单地说，事务提供一种要么不做，要么全做机制。
ACID
我们先简单了解一下事务的四大特性：
- A 原子性(Atomicity)
一个事务(transaction)中的所有操作，要么全部完成，要么全部不完成，不会出现部分成功部分失败的情况。。
- C 一致性(Consistency)
事务的一致性指的是在一个事务执行之前和执行之后数据库都必须处于一致性状态。如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。如果在事务中出现错误，那么系统中的所有变化将自动地回滚，系统返回到原始状态。
- I 隔离性(Isolation)
指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。由并发事务所做的修改必须与任何其他并发事务所做的修改隔离。事务查看数据更新时，数据所处的状态要么是另一事务修改它之前的状态，要么是另一事务修改它之后的状态，事务不会查看到中间状态的数据。
- D 持久性(Durability)
指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。
单体事务
在单体架构时代，所有的业务只用一个数据库。
单体架构时代事务的是实现很简单，我们操作的是同一个数据库，利用数据库本身提供的事务机制支持就可以了。
例如我们比较熟悉的MySQL数据库：
- 事务的隔离性是通过数据库锁的机制实现的。
- 事务的一致性由undo log来保证：undo log是逻辑日志，记录了事务的
insert、update、deltete操作，回滚的时候做相反的delete、update、insert操作来恢复数据。 - 事务的原子性和一持久性由redo log来保证：
redolog被称作重做日志，是物理日志，事务提交的时候，必须先将事务的所有日志写入redo log持久化，到事务的提交操作才算完成。
详细了解建议阅读《MySQL技术内幕 InnoDB存储引擎》7.2节。
分布式事务
随着业务发展，单体架构顶不住了，慢慢进入分布式时代——SOA或者粒度更细的微服务。
当然伴随而来的就是分库分表。
- 我们可能会根据业务服务拆分的方式，对应地
垂直拆分大库，例如原始大库拆分成订单库、商品库、支付库。 - 同时由于业务数据可能会高速增加，很快就成了亿级，我们不得不又
水平分库，来减轻单个数据库的压力。
不管是怎么分库的，最后的结果就是我们一个操作可能要横跨多个数据库。
数据库本身的事务机制只能保证它自己这个库的事务，但是没法保证到其它的库。我们要保证跨多个库的操作还具备事务的特性，就不得不上分布式事务了。
在前面 分布式必备理论基础：CAP和BASE 里，讲了分布式的理论基础——CAP和BASE，这里就不再多讲。
我们只需要知道，BASE理论是对CAP中AP的一个延申，在没法保证强一致性的前提下，尽可能达到最终的一致性。
我们的分布式事务通常也做不到本地事务那么强的一致性，一般都是对一致性(Consistency)适当做了一些放宽，只需要达到最终的一致性。
最近建一些几十个工作内推群，各大城市都有，群里目前已经收集了很多内推岗位，大厂、中厂、小厂、外包都有。 欢迎HR、开发、测试、运维和产品加入。
扫描下方微信，备注：网站+所在城市，即可拉你进工作内推群。
