3.redis事务概念

在 redis 中它的事务与批处理非常相似

Redis中的事务（transaction）是一组命令的集合。事务同命令一样都是Redis的最小执行单位，一个事务中的命令要么都执行，要么都不执行。事务的应用非常普遍，如银行转账过程中A给B汇款，首先系统从A的账户中将钱划走，然后向B的账户增加相应的金额。这两个步骤必须属于同一个事务，要么全执行，要么全不执行。否则只执行第一步，钱就凭空消失了，这显然让人无法接受。

Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证：

1. 事务是一个单独的隔离操作，事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
2. 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行

事务的三个步骤

1. 开启事务：以MULTI开启一个事务。
2. 命令入队：将多个命令添加到命令队列中，接到这些命令不会立即执行，而是放到等待执行的事务队列中。
3. 执行事务：有EXEC执行事务。（或者DISCARD取消执行）

常见案例：

正常执行：指的是队列的中所有操作全部都会执行

全部取消：指的是队列中的所有操作全部都会被取消

执行：DISCARD

全体连坐：如果指令集中有一条在加入队列时报错，则队列中的所有指令全部取消。指的是有语法错误

冤有头债有主：如果指令已经加入到队列中，但执行失败，只有当前指令失败，其它继续执行。指的是已经添加到队列但是执行失败

watch监控

watch监控表示对需要操作的key添加一个乐观锁，防止另一个用户进行修改，导致结果错误。

悲观锁：

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

乐观锁：

顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。提交的版本号必须大于当前版本号才可以提交。

案例：

图一

图二

图解：当图一开启监控key “money”，开启事务的时候加入拿着的是版本1，在事务执行过程中图二第二个客户端修改了版本一的指，现在库中存在的是版本二，而incrby money 200 在执行exec的时候我们的是版本二，乐观锁在这个时候并不允许我们提交，因为当前库中版本是2而我们提交的版本也是2。提交的版本号必须大于当前版本号才可以提交。！！！！！！！！！！

通过watch命令在事务执行之前监控了多个keys，倘若在watch之后有任何的key的值发生了变化，exec命令执行的事务会被取消。

事务的三个特性

单独的隔离性：事务中的所有的命令都会序列化，按顺序执行，事务在执行过程中，不会被其它客户端发送过来的命令请求所打断。

没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新。

不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚