可靠性是衡量数据库好坏的重要指标，它要求数据库始终保证数据的一致性，当故障发生时已经提交的数据不会丢失，并在系统重启之后数据能够快速恢复。
数据在写入时往往先被写到内存缓冲区，之后在某一时间才会真正持久化到磁盘中。对于一个简单的增、删、改、查操作，可以等待数据写到磁盘后再返回操作成功，这样就不会出现一致性问题。
而实际应用中经常出现一组操作需要作为整体执行的情况，比如两个账户之间进行转账，一个账户的资金转出和另一个账户的资金转入要作为一个完整的操作，要么都成功要么都失败，不允许出现数据不一致的情况。基于这样的需求，数据库提供了事务机制，用于将一系列数据库操作组合成一个完整的逻辑过程。
事务就是数据库中一系列数据操作的集合，集合可能有大有小，但无论集合中有多少操作，要么一起操作成功，要么失败一起回滚。无论集合中有多少操作，对于用户来说，就是一个操作，相当于一个原子操作。
事务的 ACID 属性：
-
原子性（Atomicity）：事务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用，比如上文转账的示例。
-
一致性（Consistency）：确保从一个正确的状态转换到另外一个正确的状态，这就是一致性。要么事务成功，进入一个新的状态，要么事务回滚，回到过去稳定的状态。
-
隔离性（Isolation）：并发访问数据库时，一个用户的事务不被其他事务所干扰，各并发事务之间是独立的。
-
持久性（Durability）：一个事务被提交之后，对数据库中数据的改变是持久的，即使数据库发生故障，比如断电宕机，也不应该对其有任何影响。
由于一个事务包含多个操作，可能出现事务进行到一半发生故障的情况，此时数据库会处于不一致的状态。数据库要恢复到一致性状态，要么撤销已经执行的操作，恢复到事务执行前的状态，要么重做未完成的操作，恢复到事务执行后的状态。要知道哪些操作需要撤销、哪些操作需要重做，一般会用到一种技术：日志。
在数据库设计中，将记录撤销操作的日志称为 “undo log”，将记录重做操作的日志称为 “redo log”，接下来的介绍中会讨论它们如何处理数据不一致的问题。