Redis事务

1、事务概要

Redis事务是一个单独的隔离操作：

• 事务中的所有命令都会序列化、按顺序地执行。
• 事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis事务的主要作用

        串联多个命令，防止别的命令插队。

事务的3个命令

1. Multi
2. Exec
3. discard

从输入Multi命令开始，输入的命令都会一次进入命令队列中，但不会执行，直到输入Exec后，Redis会将之前的命令队列中的命令依次执行（组队过程）。

组队的过程中，可以通过discard命令来放弃组队。

其实，这里类似于"二阶事务（2PC）"，但是本质是不同的！：

• 输入Multi命令进入队列排队 类似于2PC中的事务准备阶段
• 输入Exec命令 类似于2PC中的事务提交阶段
• discard命令类似于事务的回滚阶段

如图：

 案例1

        开启事务到执行队列：

案例2

        开启事务到放弃组队 

以上是事务正常执行的案例，下面演示出问题的案例：

1>当在组队过程中的命令出现错误，直接执行队列，那么执行阶段会提示"transaction discard" 

理解为：“队伍中，一人坑，全队输”

如下：

 2>当组队过程中的命令正常，执行队列时，其中的命令存在异常。

结果：哪个命令存在错误，哪个命令就不会执行，并提示错误信息

 

总结

        Redis事务其实就是把一个客户端的多个命令串联起来，防止其他客户端插队。并分为命令排队阶段和执行队列阶段，提供队列中的回滚操作（discard），当排队过程中，出现错误，那么队列不会执行；当组队成功后，执行队列时，某个命令出现错误，那么该命令会执行失败，并提示错误信息，其他正常的命令正常执行。 

2、事务冲突

这里用下面案例来描述：

一个淘宝账号被3个人同时登录，且同一时间购买不同的商品，账号只有1w的余额：

甲：购买8000元的商品

乙：购买5000元的商品

丙：购买1000元的商品

假设购买时，redis是按甲、乙、丙的顺序依次执行"减少余额"的命令，最终，余额出现负数

解决方案有2种：

悲观锁

        悲观锁（Pessimistic Lock）：顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所有每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block，直到它拿到锁。

        传统的关系型数据库里边就会用到很多这种锁机制，比如行锁、表锁等，读锁、写锁等，都是在做操作之前先上锁。

 如下：

步骤详解：

1. 甲获取到锁，在甲没有释放锁之前，别人没办法去操作余额
2. 当甲购买完释放锁（余额-8000=2000）
3. 锁被释放后，乙才能获取锁
4. 这时乙去购买商品，判断此时"2000-5000"为负数，固不执行购买操作，余额不变
5. 乙释放锁。

乐观锁

        乐观锁（Optimistic Lock）顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下再此期间别人有没有去更新这个数据，可以使用版本号等机制实现。

        乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。 

​​​​​​​

步骤详解：

1. 甲乙丙在购买商品时，给数据（余额）添加一个版本号v1.0
2. 甲乙先进行购买，都获取到了余额（1w）及版本号
3. 对数据进行更新前，会判断当前版本号是否与拿到的版本号相同，相同则对数据进行操作，不同则终止命令。会更新这个版本号
4. 假设此时甲获取到余额版本为v1.0，与数据的版本号相同，则购买商品，余额减去8000，并把余额版本号更新为v1.1
5. 乙比甲稍微慢点，拿到的版本号也是v1.0，但是在处理数据时，发现当前的版本号为v1.1，与拿到的版本不一致，固终止命令
6. 丙后面获取到余额版本号为v1.1，处理数据时，与当前版本号v1.1一致，再余额-1000，更新版本号为v1.2

3、watch命令

语法：

        watch  key1  key2  key3 ...

在执行multi之前，先执行watch  key1  ...，可以监视一个（或多个）key，如果在事务执行之前，这个（或这些）key被其他命令所改动，那么事务将被打断，返回nil（空）

案例：