事务实现机制

事务的实现相对比较复杂，它是基于多种机制和方案共同保障而做到了。
比如，通过回滚机制实现事务的原子性；借助锁机制和MVCC(多版本并发控制)保证事务的隔离性和并发性；基于WAL、Checkpoint、Crash Recovery、重做或回滚等机制实现事务的持久性；通过约束一致性(唯一索引、外键、check、NOT NULL等完整性约束)和数据一致性(由原子性、隔离性、持久性等机制保证，尤其是持久性保证数据的一致不丢失)，实现数据库系统的稳定状态。

回滚机制
回滚机制，就是在事务发生错误的情况下，数据库可以恢复到事务开始时的状态的能力。它是保证原子性的核心，也是事务并发调度的重要属性。

锁Locking
锁（加锁或封锁）机制，是实现事务的并发控制与隔离性的最常用的方案。

锁机制就是事务在对某个数据对象(如表、记录等)操作之前，先向系统发出请求，对其加锁；加锁后事务就对该数据对象有了一定的控制，在释放它的锁之前，其它的事务不能更新此数据对象。

加锁后具有什么样的控制由锁的类型决定，不同类型的锁综合作用，保证多个事务并发操作数据时，事物间各自的隔离和互不干扰。

MVCC
多版本并发控制（Multi-Version Concurrency Control，简称“MVCC”）是一种并发控制的方法，用于实现数据库的并发访问。与封锁机制的目标类似，但是比加锁有着更高的并发度、可以减少事务阻塞等。任何情况下MVCC都不会阻塞读操作，只有在多个写操作更新相同行记录时，才会有阻塞事务的冲突。

MVCC协议确保每个事务都只看到与该事务启动时的快照视图相一致的版本数据；每个事务只看到数据的一个快照，该快照只包含那些在事务启动时已经提交的数据。这个快照并不等于数据的当前状态。

MVCC的关键是要高效地维护每一行记录的不同版本，每个版本表示事务开始时，所有已经提交的数据的最新结果。

MVCC实现的也是事务的隔离和并发控制。它的目的是，让读操作不阻塞写操作，写操作不阻塞读操作，提高数据库访问的并发度。数据读取的是行记录的最新版本。写操作会创建独有的隔离的行记录副本，用以更新。

WAL
WAL（Write-Ahead Logging）是一种实现事务日志的标准方法。WAL的核心机制是，在对数据进行任何变更之前，先确保对数据库的所有修改操作都已经记录到事务日志中，从而保证事务的更新操作不会丢失。即先写日志到磁盘的机制，数据可以后续再刷新到磁盘。

WAL的目的在于保证日志的完整和正确，从而完成事务的持久性，支持数据库的灾难恢复(Crash Recovery)，防止数据丢失，而且先写日志将数据的随机写改为日志的顺序写，这样也提高了数据库的处理性能

Checkpoint
Checkpoint是事务日志中的检查点。

Checkpoint机制的基本过程是这样的。当产生检查点时，到该检查点为止的所有的内存数据页都会被刷新写入到硬盘中，并在WAL事务日志中写入该检查点记录。也就是，检查点机制保证检查点之前的所有数据都已经写入到了数据库文件中。

数据库如果发生故障，恢复过程中会从最后的检查点开始，重做这个检查点之后的事务日志，即重做日志，使数据库恢复到一致性状态。

从异常恢复的角度来说，检查点之前的WAL日志是不需要的，这样就可以循环使用日志文件；不同的数据库有不同的处理机制，比如MySQL的binlog则不会循环覆盖，而是归档便于数据库的同步或重现恢复(当然binlog中没有检查点的概念，而是redolog中使用checkpoint)。

Checkpoint机制的作用在于：保证数据库的一致性，将缓冲区的脏数据写入硬盘，使内存和硬盘中的数据一致；使WAL日志尽快失效，便于重用和节省占用的硬盘空间；缩短数据库崩溃的恢复时间，如果不进行Checkpoint，WAL日志就一直不会失效，数据库系统在重启过程中需要重做的WAL事务日志就会非常庞大，导致恢复时间过长

Crash Recovery
Crash Recovery也叫crash-safe。crash-safe的能力就是做到，即使数据库异常重启，已经提交的记录都不会丢失。

数据库系统发生异常终止的原因有很多，通常都是由于数据库服务进程被强行终止。可能的情况有：内存不足时被OOM Killer终止（Out Of Memory Killer）、操作系统崩溃、服务器停机、服务器重启、服务器发生硬件故障等。

Crash Recovery机制保证当发生数据库系统(服务进行)异常终止时，数据库能够从灾难中恢复到某个一致性状态。故障恢复/灾难恢复/异常恢复，就是要做到，只要硬盘上的数据和日志没有丢失，数据库就不会丢失数据，这是数据库系统的设计目标。