Redis学习专题（二）事务和锁机制
目录
引言
1、事务三特性
2、事务相关指令 ：Multi、Exec、discard
快速入门
注意：
3、事务冲突
解决办法：
1.悲观锁
2.乐观锁
3.watch & unwatch
引言
Redis 的事务是什么?
1、Redis 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行
2、事务在执行的过程中，不会被其他客户端发送来的命令请求所打断
3、Redis 事务的主要作用就是串联多个命令防止别的命令插队
具有隔离性，但是没有原子性
1、事务三特性
单独的隔离操作
1、事务中的所有命令都会序列化、按顺序地执行
2、事务在执行的过程中，不会被其他客户端发送来的命令请求所打断
没有隔离级别的概念
队列中的命令(指令), 在没有提交前都不会实际被执行
不保证原子性
事务执行过程中, 如果有指令执行失败，其它的指令仍然会被执行, 没有回滚
2、事务相关指令 ：Multi、Exec、discard
1) 从输入Multi命令开始，输入的命令都会依次进入命令队列中，但不会执行(类似Mysql 的 starttransaction 开启事务)
2) 输入Exec后，Redis会将之前的命令队列中的命令依次执行(类似Mysql的commit 提
3) 组队的过程中可以通过discard来放弃组队(类似Mysql的rollback 回顾事务)
4) 老韩说明:Redis事务和Mysql事务本质是完全不同的
快速入门
注意：
1、组队的过程中, 可以通过discard来放弃组队
2、如果在组队阶段报错, 会导致exec失败, 那么事务的所有指令都不会被执行 （原子性）
3、如果组队成功, 但是指令有不能正常执行的, 那么exec提交, 会出现有成功有失败情况, 也就是事务得到部分执行, 这种情况下,Redis事务不具备原子性
而且错误的指令可能在组队的时候会成功 ，举例：incr k1（对键 k1 存储的整数值进行 原子性递增+1）
3、事务冲突
经典的抢票问题
1) 一个请求想购买6
2) 一个请求想购买5
3) 一个请求想购买1
所以一共是需要12张票
如果我们现在只有10张票，但是用户1\2\3同时查询都是10张，最后的剩余票数变成-2，造成超卖
解决办法：
1.悲观锁
工作示意图：
1) 悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁
2) 这样别人/其它请求想拿这个数据就会block（阻塞）直到它拿到锁。
3) 悲观锁是锁设计理念, 传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁.
缺点：性能会比较弱，因为每次上锁和释放锁都有性能的开销
2.乐观锁
工作示意图
1) 乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁
2) 但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制，这个版本修改是需要原子性。
3) 乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的
4) 乐观锁是锁设计理念
用户2第一次查询失败就会把版本变成v1.1然后再次去查询操作票
3.watch & unwatch
1、基本语法:watch key[key ...]
2、在执行multi之前，先执行watch key1[key2],可以监视一个(或多个)key ，如果在事务执行之前这个(或这些)key 被其他命令所改动，那么事务将被打断.
3、这里可以结合乐观锁机制进行理解
理解：
