有些人埋怨，罕用的两阶段提交在性能和可用性方面代价太高。而咱们认为事务滥用和适度应用所引入的性能瓶颈应该次要由应用层来解决，而不是简略的摈弃事务
——————— 来自 google 的寰球分布式数据库
ACID
原子性
在出错时停止事务，并将局部实现的写入全副抛弃。能够让业务层平安的进行重试。
一致性
次要是指对数据有特定的预期状态，任何数据更改必须满足这些状态束缚。这种一致性实质上是要求应用层来保护状态统一，应用程序有责任正确地定义事务来保障一致性。这种一致性能够通过数据库提供的原子性，隔离性，持久性来达到，但它自身并不源于数据库。
隔离性
并发执行的多个事务相互隔离，它们不能相互穿插。
持久性
保障事务一旦提交胜利，即便存在硬件故障或者数据库解体，事务所写入的任何数据也不会隐没。对于单节点数据库，持久性意味着存入了非易失性设施（磁盘或者 ssd 等），在写入的过程中通常还波及了预写日志（比方 mysql redo log)，能够在磁盘损坏时复原数据。对于多节点数据库，持久性意味着多节点的复制，要保障数据库复制到其它节点了才算胜利。
弱隔离级别
避免脏读
实现读 - 提交隔离级别，采纳多版本控制（MVCC)，实现快照隔离，事务每次读取的数据都是已提交事务的最新版本，能够避免脏读。
避免脏写
实现读 - 提交隔离级别，通过加行锁的形式来实现。
避免读歪斜（不可反复读）
实现快照隔离级别，采纳多版本控制技术（MVCC)。相比于读 - 提交，每次查问时独自创立最新的快照，快照隔离级别下采纳一个快照来运行整个事务。
在 innodb 中是如何实现 MVCC 的呢？次要是采纳版本号。每个事务在在开始的时候会生成一个 transaction id, 记为 row trx_id。对于数据库的表新增两个暗藏列，别离是创立列和删除列，记录创立和删除时的版本号，填入的是 row trx_id 值。在快照隔离级别下有两种形式，叫作快照读和以后读。快照读是指事务开始时保留了一个快照，后续读取的数据都是取自这个快照；以后读是指读取数据时须要检查数据以后的最新值，必要时还须要加锁。
对于快照读，innodb 引擎会生成一个版本号数组，将事务生成的 row trx_id 和数组进行比对，确认读到的数据。对于已提交的数据和本事务提交的数据可能读取到，对于未提交的事务的数据则读取不到。
对于以后读，是指的当咱们须要在事务中更新数据时，须要读到以后数据库中的最新数据，而不是快照中的数据，如果有抵触，须要加锁实现。
避免更新失落
更新失落可能产生在这样的一个操作场景中：应用程序从数据库中读取某些值，依据应用逻辑作出批改，而后写回新值。如果两个事务并发做相似的操作，则可能会数据被笼罩，导致更新失落。解决方案有一下几种
- 原子写操作
- 显示加锁
- 自动检测更新失落
- 原子比拟和设置
- 抵触解决与复制
避免写歪斜和幻读
写歪斜不是一种脏写，也不是更新失落，两笔事务更新的是不同的对象。事务首先查问数据，依据返回的后果而作出某些决定，而后批改数据库。当事务提交时反对决定的前提条件已不再成立，最终造成不合乎预期的扭转。只有可串行化的隔离能力避免这种异样。
可串行化
严格串行执行事务
如果每个事务的执行速度十分快，且单个 cpu 核能满足事务的吞吐量需要，严格串行执行是一个非常简单无效的计划。
两阶段加锁
数据库的每个对象都有一个读写锁来隔离读写操作。即锁能够处于共享模式或独占模式。
- 如果事务要读取对象，必须先以共享模式取得锁。
- 如果事务要批改对象，必须已独占模式获取锁。
- 如果事务要先读取后批改对象，要从共享锁降级为独占锁。
- 事务取得锁之后，始终到事务完结才开释锁。
有两个注意事项
①因为锁是在事务完结时才开释，所以抵触更频繁的锁，应该在越凑近事务完结的中央运行，缩小事务等待时间。
②对于死锁能够开启死锁检测机制，产生死锁时能够强行停止一个，并由应用层来重试。然而死锁检测很耗内存的 cpu，如果一个事务更新的太频繁，多个事务同时运行，可能导致大量的死锁检测，从而会升高零碎的并发度。解决办法是在数据库层管制一个数据最多只能由无限的事务同时批改该数据，其它事务排队期待，缩小死锁检测。
可串行的快照隔离
秉持乐观预期的准则，容许多个事务并发执行而不相互阻塞，仅当事务尝试提交时，才检测可能的抵触，如果违反了串行化，则某些事务会被终止。