事务和事务的隔离

ACID，指数据库事务正确执行的四个基本要素的缩写。包含：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。一个支持事务（Transaction）的，必需要具有这四种特性，否则在事务过程（Transaction processing）当中无法保证数据的正确性，交易过程极可能达不到交易方的要求。

原子性: 整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。例如：Bob给Jim100钱   

ver1，Bob有100块钱，Jim有0块钱

ver2，Bob有0块钱，Jim有0块钱（回滚段undo：Bob有100块钱，Jim有0块钱）

ver3，Bob有0块钱，Jim有100块钱（回滚段undo：Bob有0块钱，Jim有0块钱）

这三个步骤要么一起成功，要么一起回滚到最初状态。

一致性: 在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。（能保证看到系统内的所有更改）

Can（before happend）

    （Lock Bob and Jim）防止新的事务单元进来修改bob和Jim信息

ver1，Bob有100块钱，Jim有0块钱

ver2，Bob有0块钱，Jim有0块钱（回滚段undo：Bob有100块钱，Jim有0块钱）

ver3，Bob有0块钱，Jim有100块钱（回滚段undo：Bob有0块钱，Jim有0块钱）

    （unLock Bob and Jim）

隔离性:提高系统并发，实质是破环一致性，SQL92标准隔离级别定义标准，另外新加MVCC/snapshop快照隔离级别。

SERIALIZABLE（序列化）：添加范围排它锁（比如表锁，页锁等），直到transaction A结束。以此阻止其它transaction B对此范围内的insert，update等操作，单位时间类只有一个事务进来，性能差。

 

REPEATABLE READ（可重复读）：对于读出的记录，添加共享锁直到transaction A结束。其它transaction B对这个记录的试图修改会一直等待直到transaction A结束。读锁不可升级为写锁（读读并行）。可能发生的问题：当执行一个范围查询时，可能会发生幻读。

 

READ COMMITTED（提交读）：在transaction A中读取数据时对记录添加共享锁，但读取结束立即释放。其它transaction B对这个记录的试图修改会一直等待直到A中的读取过程结束，而不需要整个transaction A的结束。所以，在transaction A的不同阶段对同一记录的读取结果可能是不同的。（读读并行，读写并行）可能发生的问题：不可重复读（读写并行：第一次读和第二次读的可能不一样）。

 

READ UNCOMMITTED(未提交读)：读不加锁，只加写锁。所以其它transaction B可以在transaction A对记录的读取过程中修改同一记录，可能会导致A读取的数据是一个被破坏的或者说不完整不正确的数据，另外，在transaction A中可以读取到transaction B（未提交）中修改的数据。比如transaction B对R记录修改了，但未提交。此时，在transaction A中读取R记录，读出的是被B修改过的数据。

(读读并行，读写并行,写读并行）可能发生的问题：脏读（读到写过程中的数据）

Multi-Version Concurrency Control 多版本并发控制：Copy on Write和无锁编程（标准不等于对）

快照（Snapshot）隔离级别：在写的时候生成一个快照回滚段，提供给读使用。保证读写并行，写读并行。主要用于读多写少的场景，并行度能超过读未提交，隔离级别较高不会出现脏读。

持久性（Durability）：在事务完成以后，该事务所对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。

RAID持久性：一个数据写到多个磁盘上去，并保证同时成功或者同时失败，多个磁盘可以让数据更加不宜丢失！

数据写内存：速度快，易丢失，数据写磁盘：效率低。但是保证持久性必须落磁盘上。

1，commit提交到内存中返回成功，攒一包数据后批量一起存储到磁盘块。优点：iops高，缺点：容易丢失包。

2，组提交：一个commit不让返回，等待一批提交之后在打包存储到磁盘上去，返回成功。优点：保证系统的持久性和吞吐量  缺点：可能延迟性高

具体做法必须通过实际业务来选定。

如果系统down机，如何保证数据ACID:事务的原子性操作只有一个commit，重启后进去recovery状态，commit完成之后之后的请求必须全部完成，否则回滚。recovery之后才提供对外访问，并记录日志防止这一次recovery失败重启。

事务调优原则，尽可能在不影响业务的情况下 

1，减少锁的范围，myisam表锁 -> innodb行锁, 原位锁 -> mvcc多版本锁(将一个大锁变成只锁一个的小锁)

2，增加锁上可以并行的线程数。读锁写锁分离，可以并行读取数据，多线程读取。

3，选择正确的锁类型：悲观锁，乐观锁

悲观锁： 具有强烈的独占和排他特性。它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。如果其他的线程做事就会把这个线程换出来，把cpu，缓存清空，重新执行新的线程业务

乐观锁：每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量，像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁。

如果你认为数据争抢不严重，使用乐观锁，如果数据争抢严重使用悲观锁。