读数据密集型应用系统设计有感而发（四）（数据库事务）数据库mysql

有些人抱怨，常用的两阶段提交在性能和可用性方面代价太高。而我们认为事务滥用和过度使用所引入的性能瓶颈应该主要由应用层来解决，而不是简单的抛弃事务
? --------------------- 来自google的全球分布式数据库
ACID 原子性
在出错时中止事务，并将部分完成的写入全部丢弃。可以让业务层安全的进行重试。
一致性
主要是指对数据有特定的预期状态，任何数据更改必须满足这些状态约束。这种一致性本质上是要求应用层来维护状态一致，应用程序有责任正确地定义事务来保证一致性。这种一致性可以通过数据库提供的原子性，隔离性，持久性来达到，但它本身并不源于数据库。
隔离性
并发执行的多个事务互相隔离，它们不能互相交叉。
持久性
保证事务一旦提交成功，即使存在硬件故障或者数据库崩溃，事务所写入的任何数据也不会消失。对于单节点数据库，持久性意味着存入了非易失性设备（磁盘或者ssd等），在写入的过程中通常还涉及了预写日志（比如mysql redo log)，可以在磁盘损坏时恢复数据。对于多节点数据库，持久性意味着多节点的复制，要保证数据库复制到其它节点了才算成功。
弱隔离级别防止脏读
实现读-提交隔离级别，采用多版本控制（MVCC)，实现快照隔离，事务每次读取的数据都是已提交事务的最新版本，可以防止脏读。
防止脏写
实现读-提交隔离级别，通过加行锁的方式来实现。
防止读倾斜（不可重复读）
实现快照隔离级别，采用多版本控制技术（MVCC)。相比于读-提交，每次查询时单独创建最新的快照，快照隔离级别下采用一个快照来运行整个事务。
【读数据密集型应用系统设计有感而发（四）（数据库事务）】在innodb中是如何实现MVCC的呢？主要是采用版本号。每个事务在在开始的时候会生成一个transaction id,记为row trx_id。对于数据库的表新增两个隐藏列，分别是创建列和删除列，记录创建和删除时的版本号，填入的是row trx_id值。在快照隔离级别下有两种方式，叫作快照读和当前读。快照读是指事务开始时保存了一个快照，后续读取的数据都是取自这个快照；当前读是指读取数据时需要检查数据当前的最新值，必要时还需要加锁。
对于快照读，innodb引擎会生成一个版本号数组，将事务生成的row trx_id和数组进行比对，确认读到的数据。对于已提交的数据和本事务提交的数据能够读取到，对于未提交的事务的数据则读取不到。
对于当前读，是指的当我们需要在事务中更新数据时，需要读到当前数据库中的最新数据，而不是快照中的数据，如果有冲突，需要加锁实现。
防止更新丢失
更新丢失可能发生在这样的一个操作场景中：应用程序从数据库中读取某些值，根据应用逻辑作出修改，然后写回新值。如果两个事务并发做类似的操作，则可能会数据被覆盖，导致更新丢失。解决方案有一下几种

原子写操作
显示加锁
自动检测更新丢失
原子比较和设置
冲突解决与复制

防止写倾斜和幻读
写倾斜不是一种脏写，也不是更新丢失，两笔事务更新的是不同的对象。事务首先查询数据，根据返回的结果而作出某些决定，然后修改数据库。当事务提交时支持决定的前提条件已不再成立，最终造成不符合预期的改变。只有可串行化的隔离才能防止这种异常。
可串行化严格串行执行事务
如果每个事务的执行速度非常快，且单个cpu核能满足事务的吞吐量需求，严格串行执行是一个非常简单有效的方案。
两阶段加锁
数据库的每个对象都有一个读写锁来隔离读写操作。即锁可以处于共享模式或独占模式。

如果事务要读取对象，必须先以共享模式获得锁。
如果事务要修改对象，必须已独占模式获取锁。
如果事务要先读取后修改对象，要从共享锁升级为独占锁。
事务获得锁之后，一直到事务结束才释放锁。

有两个注意事项
①因为锁是在事务结束时才释放，所以冲突更频繁的锁，应该在越靠近事务结束的地方运行，减少事务等待时间。
②对于死锁可以开启死锁检测机制，产生死锁时可以强行中止一个，并由应用层来重试。但是死锁检测很耗内存的cpu，如果一个事务更新的太频繁，多个事务同时运行，可能导致大量的死锁检测，从而会降低系统的并发度。解决办法是在数据库层控制一个数据最多只能由有限的事务同时修改该数据，其它事务排队等待，减少死锁检测。
可串行的快照隔离
秉持乐观预期的原则，允许多个事务并发执行而不互相阻塞，仅当事务尝试提交时，才检测可能的冲突，如果违背了串行化，则某些事务会被终止。