【简述】

事务是指一系列的操作步骤，着一些列的操作步骤，要么完全地执行，要不完全地不执行。

比如微博中：

A用户关注了B用户，那么A的关注列表里就会有B用户，B用户的粉丝列表里就会有A用户。

这个关注的步骤就是由一些列的操作步骤构成：

(1).A用户添加到B的粉丝列表

(2).B用户添加到A的关注列表

这两个步骤必须全部执行成功，整个逻辑才是正确的，否则就会产生数据的错误，比如A用户的关注列表有B用户，但B的粉丝列表里没有A用户，所以要保证一系列的操作都完全成功，提出了事务控制的概念。

【Redis事务】

Redis中的事务（transaction）是一组命令的集合，至少是两个或两个以上的命令。

事务同命令一样都是Redis的最小执行单位，一个事务中的命令要么都执行，要么都不执行。

【事务简单例子】

先以 MULTI 开启一个事务，然后将多个命令入队到事务中，最后由 EXEC 命令触发事务，一并执行事务队列中的所有命令。

【注意——版本差异】

2.6.5版本之前：

单个Redis命令的执行原子性的，但Redis没有在事务上增加任何维持原子性的机制，所以Redis事务的执行并不是原子性的。

事务可以理解为一个打包的批量执行脚本，但批量指令并非原子化的操作，中间某条指令的失败不会导致前面已做指令的的回滚，也不会造成后续指令不做。

2.6.5之后的版本：

能保证一个事务中的所有命令要么都执行，要么都不执行。

如果在发送EXEC命令前客户端断线了，则Redis会清空事务队列，事务中的所有命令都不执行。

而一旦客户端发送了EXEC命令，所有的命令都会被执行，即使伺候客户端断线也没关系，因为Redis中已经记录了所有要执行的命令。

【异常情况1——语法错误（3.0版本，事务不执行例子）】

上面例子中，第一个指令 set name "zhangsan" 成功加入了事务队列，但是接下来的命令有语法错误，而2.6.5之后的版本只要有一个命令有语法错误，执行EXEC命令后Redis会直接返回错误，连语法正确的命令也不会执行。

【异常情况2——运行时错误（语法正确，运行错误）】

运行时错误是指在命令执行时出现的错误。比如下例中的键值不同类型操作，这种操作实际上是在执行之前Redis无法发现的，所以事务里这样的命令会被Redis接收并执行的，如果事务里的一条命令出现了运行时错误，事务里的其他命令依旧会继续执行。

【复杂情况——利用Watch实现乐观锁】

[悲观锁]

悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据时会认为被人会修改该数据，所以每次拿数据的时候都会先上锁 ，这样每次别人想拿这个数据就会block阻塞直到别人拿到锁，传统的关系型数据库里面就用到了很多这样的锁机制，比如运行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁，让别人无法操作数据。

[乐观锁]

乐观锁（Optimistic Lock），顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改该数据，所以不会上锁，但是再更新的时候会判断一下在此期间别人有没有去更新这条数据，一般使用版本号机制进行判断，乐观锁适用于多读的应用类型，这样可以提高吞吐量。

乐观锁大多数情况是基于数据版本号（version）的机制实现的，何谓数据版本呢，即为数据添加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表添加一个“version”字段。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加1，此时将提交的数据version与数据库表对应的version进行对比，如果提交的version大于数据库当前的version，则予以更新，否则认为是过期数据，不予以更新。

[Redis实现的乐观锁]

【注意】

Redis的事务没有关系型数据事务提供的回滚（rollback）功能，为此开发者必须在事务执行出错后自己收拾烂摊子，将数据库复原回事务执行前的状态。

不过由于Redis不支持回滚功能，使得Redis在事务上可以保持简洁和快速。