详解事务及事务故障种类以及恢复技术

一、事务的基本概念
1.事务是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。例如，在关系数据库中，一个事务可以是一条sql语句、一组sql语句或者整个程序。（一般一个程序中包含多个事务）
2.事务的开始和结束可以由用户显式控制，如果用户没有显式地定义事务，则由数据库管理系统按默认规定自动划分事务。在SQL中，定义事务的语句一般有三条：

BEGIN TRANSATION;         //开始事务
COMMIT;                   //将事务中所有对数据库的更新写到磁盘上的物理数据库中去，事务正常结束
ROLLBACK;                 //回滚事务，回滚到事务开始时的状态

例如，YII框架中使用：

$transaction = Yii::$app->db->beginTransaction();
try{
     //执行程序，或者脚本中的一些方法，或者一些sql语句
     $this->actionShareAirTransport();
     ......
     //提交事务
     $transsction->commit();
} catch(Exception $e){  //出现异常
     //回滚事务,回滚到事务开始时的状态
     $transaction->rollback();
     //返回错误
     return '数据出现错误，已回滚';
}

redis事务的使用：redis中的事务不能回滚，mysql的事务可以回滚
一般情况下，redis接收到一个客户端连接发来的命令，立刻执行并返回结果。但是当连接发出multi命令时，此链接便进入一个事务上下文，redis把此连接发来的命令存入一个队列中。当此连接发出exec命令，redis便开始按顺序执行队列中的所有命令，事务中任意命令执行失败，前面的命令不会回滚！其余的命令依然被执行！并将所有命令执行的结果打包一起返回给客户端连接，然后此连接便结束事务上下文。
三个阶段：开始事务 命令入队 执行事务

redis事务相关命令：
     multi：标记事务块的开始，redis会将后续的命令逐个放入队列中，然后才能使用exec命令执行这个命令序列。返回字符串OK
     exec：执行从multi开始的中间的命令。当使用watch命令时，只有当受监控的键没有被修改，exec命令才会执行事务中的命令，这种方式利用了检查再设置（CAS）的机制。返回数组，七海总都为每个命令的返回值，当使用watch命令时如果事务执行中止那么exec命令返回Null值。
     discard：取消事务，清除所有闲钱在一个事务中队列的命令，然后回复正常的连接状态，若使用了watch则取消了键监听。返回字符串OK
     watch：监视一个或者多个key，如果在事务执行之前这些key被其他命令所改动，那么事务将会被打断。返回字符串OK，对每个键来说时间复杂度总是O(1)
     unwatch：取消watch命令对所有key的监视。返回字符串OK，对每个键来说时间复杂度总是O(1)
代码：
   $redis->connect('','','');
   $redis->multi();    //标记事务块开始（下面好多条命令可以组成一个事务快）
   $redis->incr('salenum');    //增加销量
   $redis->set('user');      //抢购到的用户
   $redis->watch('salenum','kucun');    //加了watch后，会监听库存和销量
   $redis->exec();    //执行中间的命令，如果监听异常(指当前连接修改当前的值，如果其他连接也修改了就是异常)，不会提交，事务被打断
   

3.事务的ACID特性
(1)原子性Atomicity
事务是数据库的逻辑工作单元，事务中包括的诸操作要么都做，要么都不做
(2)一致性Consistency
事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态
(3)隔离性Isolation
一个事物的执行不能被其他事务干扰
(4)持续性Durability
也就是永久性，一个事务一旦提交，它对数据库中数据的改变就是永久性的
保证事务ACID特性是事务管理的重要任务。事务ACID特性可能中遭到破坏的因素有：
(1)多个事务并行运行时，不同事务的操作交叉运行
(2)事务在运行过程中被强制停止
这些都需要数据库管理系统中恢复机制和并发控制机制的责任
二、事务发生故障的种类
1.事务内部的故障
事务内部更多的故障是非预期的，是不能有应用程序处理的。如运算溢出、并发事务发生死锁而被选中撤销该事务、违反了某些完整性限制而被终止等。
2.系统故障（软故障）
是指造成系统停止运转的任何事件，使得系统要重新启动。如特定类型的硬件错误(cpu故障)、操作系统故障、DBMS代码错误、系统断电等。这类故障影响正在运行的所有事务，但不破坏数据库。此时主存内容，尤其是数据库缓存区(在内存)中的内容都被丢失，所有运行事务都非正常终止。
3.介质故障（硬故障）
是指外存故障。如磁盘损坏、磁头碰撞、瞬间强磁场干扰等。这类故障将破坏数据库或部分数据，并影响正在存取这部分数据的所有事务。
4.计算机病毒
这都会影响数据的一致性。恢复的基本原理就是：冗余。也就是说，数据库中任何一部分被破坏或者不正确的数据可以根据存储在系统别处的冗余数据重建。
三、恢复的实现技术
建立冗余数据最常用的技术是数据转储和登记日志文件
1.数据转储
所谓转储即数据库管理员定期地将整个数据复制到磁带、磁盘或其他存储介质上保存起来的过程。这些备用的数据称为后备副本或后援副本。
2.登记日志文件
日志文件是用来记录事务对数据库的更新操作的文件。不同数据库系统采用的日志文件格式并不完全一样。概括起来日志文件只要有两种格式：以记录为单位的日志文件和以数据块为单位的日志文件。
(1)以记录为单位的日志文件，需要登记的内容包括：
各个事务的开始
各个事务的结束
各个事务的所有更新操作
每个日志记录的内容主要包括：
事务标识（标明是哪个事务）
操作的类型（插入、删除或修改）
操作对象（记录内部标识）
更新前数据的旧值（对插入操作而言，此项为空值）
更新后数据的新值（对删除操作而言，此项为控制）
(2)以数据块为单位的日志文件
日志记录的内容包括事务标识和被更新的数据块。由于将更新前的整个块和更新后的整个块都放入日志文件中，操作类型和操作对象等信息就不必放入日志记录中了。
日志文件的作用：
事务故障恢复和系统故障回复必须使用日志文件
在动态转储方式中必须建立日志文件，后备副本和日志文件结合起来才能有效地恢复数据库
在静态转储方式中也可以建立日志文件，当数据库毁坏后重新装入后援副本把数据库恢复到转储结束时刻的正确状态，然后利用日志文件把已完成的事务进行重做处理，对故障发生时尚未完成的事务进行撤销处理。
登记日志文件的原则：
登记的次序严格按并发事务执行的时间次序
必须先写日志文件，后写数据库(因为如果先写数据库，再写日志文件的过程中发生错误就无法恢复数据库;如果先写日志文件，即使写入库中发生错误那么通过日志文件还是可以恢复。)
3.数据库镜像
指系统将整个数据库或者其中的关键数据复制到冷一个磁盘上，每当主数据库更新的时，数据库管理系统自动把更新后的数据复制过去，有数据库系统自动保证镜像数据与主数据库的一致性。这样一旦介质故障，可由镜像磁盘继续提供使用，同事数据库管理系统自动利用镜像磁盘数据进行数据库的恢复，不需要关闭系统和重装数据库副本。在没有发生故障时，数据库镜像还可以用于并发操作，即当一个用户对数据加排他锁修改数据时，其他用户可以读镜像数据库上的数据，而不必等待该用户释放锁。