事务

指对系统进行的一组操作，为了保证系统的完整性，事务需要具有ACID特性。

原子性（Atomic）

• 一个事务包含多个操作，这些操作要么全都执行，要么全都不执行。
• 实现事务的原子性，要支持回滚操作，在某个操作失败后，回滚到事务执行前的状态。

回滚：实际上是一个比较高层抽象的概念。

• 大多数DB在实现事务时，是在事务操作的数据快照上进行的（如：MVCC），并不修改实际的数据，如果有错并不会提交，所以很自然的支持回滚。
• 而在一些支持简单事务的系统中，直接操作实际数据，可以先预演一遍要执行的操作，如果失败则这些操作不会被执行，通过这种方式很简单的实现了原子性。

一致性（Consistency）

• 指事务使得系统从一个一致的状态转换到另一个一致的状态。
• 事务的一致性决定了一个系统设计和实现的复杂度，事务可以不同程度的一致性：

强一致性

读操作可以立即读到提交的更新操作。

弱一致性

提交的更新操作，不一定立即会被读操作读到，这种情况会存在一个不一致窗口，指读操作可以读到最新值的一段时间。

最终一致性

是弱一致性的特例。事务更新一份数据，最终一致性保证在没有其他事务更新同样的值的话，最终所有的事务都会读到之前事务跟新的最新值。如果没有错误发生，不一致窗口的大小依赖于：通信延迟，系统负载等。

其他一致性变体还有：

单调一致性

如果一个进程已经读到一个值，那么后续不会读到更早的值。

会话一致性

保证客户端和服务器交互的会话过程中，读操作可以读到更新操作后的最新值。

隔离性（Isolation）

指并发事务间互相影响的程度，比如一个事务会不会读取到另一个未提交的事务修改的数据。在事务并发操作时，可能出现的问题有：
脏读

事务A修改了一个数据，但未提交，事务B读到了事务A未提交的更新结果，如果事务A提交失败，事务B读到的就是脏数据。

不可重复读

同一事务中，对于同一份数据读取到的结果不一致。如事务B在事务A提交前后读取的数据不一致。
原因：事务并发修改记录。
解决：加锁。但这会导致锁竞争加剧，影响性能。另一种方法是通过MVCC可以在无锁的情况下，避免不可重复读。

幻读

同一事务中，同一个查询多次返回的结果不一致。如事务B在事务A提交前后查询到的数据记录变多了。
原因：并发事务增加记录。
解决：串行。

事务的隔离级别从低到高有：

Read Uncommitted

最低的隔离级别，什么都不需要做，一个事务可以读到另一个事务未提交的结果。所有的并发事务问题都会发生。

Read Committed

只有在事务提交后，其更新结果才会被其他事务看见。可以解决脏读问题。

Repeated Read

在一个事务中，对于同一份数据的读取结果总是相同的，无论是否有其他事务对这份数据进行操作，以及这个事务是否提交。可以解决脏读、不可重复读。

Serialization

事务串行化执行，隔离级别最高，牺牲了系统的并发性。可以解决并发事务的所有问题。

持久性（Durability）

事务提交后，对系统的影响是永久的。

总结

• 原子性：事务操作失败时，回滚。
• 一致性：弱一致性时，A改了一个数，B不能立即读取到，这时B也修改了这个数，会导致A改的数被覆盖。多个原子性事务并不能保证一致性。
• 隔离性：提交前可读、提交后可读、可重复读、串行化。
• 持久性：事务提交后影响是永久的。

补充

MVCC-多版本并发控制(Multi-Version Concurrency Control)

• 是一种用来解决读-写冲突的无锁并发控制，也就是为事务分配单向增长的时间戳，为每个修改保存一个版本，版本与事务时间戳关联，读操作只读该事务开始前的数据库的快照。 这样在读操作不用阻塞写操作，写操作不用阻塞读操作的同时，避免了脏读和不可重复读
• 乐观并发控制（OCC）是一种用来解决写-写冲突的无锁并发控制，认为事务间争用没有那么多，所以先进行修改，在提交事务前，检查一下事务开始后，有没有新提交改变，如果没有就提交，如果有就放弃并重试。乐观并发控制类似自选锁。乐观并发控制适用于低数据争用，写冲突比较少的环境。
• 多版本并发控制可以结合基于锁的并发控制来解决写-写冲突，即MVCC+2PL，也可以结合乐观并发控制来解决写-写冲突。

关系型数据库和非关系型数据库的区别