Redis事务的概念：
Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。
总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
Redis事务没有隔离级别的概念：
批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。
Redis不保证原子性：
Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。
Redis事务的三个阶段：
- 开始事务
- 命令入队
- 执行事务
Redis事务相关命令：
watch key1 key2 … : 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 （ 类似乐观锁 ）
multi : 标记一个事务块的开始（ queued ）
exec : 执行所有事务块的命令 （ 一旦执行exec后，之前加的监控锁都会被取消掉 ）
discard : 取消事务，放弃事务块中的所有命令
unwatch : 取消watch对所有key的监控
Redis事务使用案例：
- 正常使用
- 放弃事务
- 定义事务的过程中，命令格式输入错误，整体事务中的所有命令均不会执行，包括正确的命令
- 定义事务的过程中，命令执行错误，例如给list进行incr操作，能够运行正确的命令，运行错误的命令不会被执行并且会抛出异常。
- 使用watch （开启事务之前）
（1）监控name，age在事务中更改没有问题
（2）再开一个服务端，在事务开启时对name进行更改，事务执行失败
分布式锁
基于特定条件的事务执行
业务场景
天猫双11热卖过程中，对已经售完的货物追加补货，且补货完成。客户购买热情高涨，3秒内将所有商品购买完毕。本次补货已经将库存全部清空,如何避免最后一件商品不被多人同时购买? [超卖问题]
业务分析
●使用watch监控一个key有没有改变已经不能解决问题，此处要监控的是具体数据
●虽然redis是 单线程的，但是多个客户端对同一数据同时进行操作时，如何避免不被同时修改?
解决方案
●使用setnx设置一个公共锁
1 | setnx lock-key value |
利用setnx命令的返回值特征，有值则返回设置失败，无值则返回设置成功
●对于返回设置成功的，拥有控制权，进行下一 步的具体业务操作，对于返回设置失败的，不具有控制权，排队或等待
操作完毕通过del操作释放锁
死锁
由于锁操作由用户控制加锁解锁，那么必然会出现未解锁的风险
需要解锁不能只由用户来控制，系统级别要给出对应的解锁方案。
1 | expire lock—key value |
