Redis 事务的本质是一组命令的集合。事务支持一次性执行多个命令，一个事务中所有命令都会被序列化。在事务执行过程，会按照顺序串行化执行队列中的命令，其他客户端提交的命令请求不会插入到事务执行命令序列中。Redis支持简单的事务
-------队列 set set set 队列------
总结说：redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
Redis事务没有隔离级别的概念 所有的命令在事务中，并没有直接被执行！只有发起执行命令的时候才会执行 exec
Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。
Redis事务的三个阶段：
- 开始事务(multi)
- 命令入队
- 执行事务(exec)
Redis事务相关命令：
watch key1 key2 ... : 监视一或多个key,如果在事务执行之前，被监视的key被其他命令改动，则事务被打断 （ 类似乐观锁 ）
multi : 标记一个事务块的开始（ queued ）
exec : 执行所有事务块的命令 （ 一旦执行exec后，之前加的监控锁都会被取消掉 ）
discard : 取消事务，放弃事务块中的所有命令
unwatch : 取消watch对所有key的监控
Redis事务使用案例：
（1）正常执行
（2）放弃事务
（3）若在事务队列中存在命令性错误（类似于java编译性错误），则执行EXEC命令时，所有命令都不会执行
（4）若在事务队列中存在语法性错误（类似于java的1/0的运行时异常），则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。
（5）使用watch
案例一：使用watch检测balance，事务期间balance数据未变动，事务执行成功
案例二：使用watch检测balance，在开启事务后（标注1处），在新窗口执行标注2中的操作，更改balance的值，模拟其他客户端在事务执行期间更改watch监控的数据，然后再执行标注1后命令，执行EXEC后，事务未成功执行。
一但执行 EXEC 开启事务的执行后，无论事务使用执行成功， WARCH 对变量的监控都将被取消。
故当事务执行失败后，需重新执行WATCH命令对变量进行监控，并开启新的事务进行操作。
思考: 我正在买票 Ticket -1 , money -100 而票只有1张, 如果在我multi之后,和exec之前, 票被别人买了---即ticket变成0了. 我该如何观察这种情景,并不再提交 悲观的想法: 世界充满危险,肯定有人和我抢, 给 ticket上锁, 只有我能操作. [悲观锁] 乐观的想法: 没有那么多人和我抢,因此,我只需要注意, --有没有人更改ticket的值就可以了 [乐观锁] Redis的事务中,启用的是乐观锁,只负责监测key没有被改动. 具体的命令---- watch命令 例: redis 127.0.0.1:6379> watch ticket OK redis 127.0.0.1:6379> multi OK redis 127.0.0.1:6379> decr ticket QUEUED redis 127.0.0.1:6379> decrby money 100 QUEUED redis 127.0.0.1:6379> exec (nil) // 返回nil,说明监视的ticket已经改变了,事务就取消了. redis 127.0.0.1:6379> get ticket "0" redis 127.0.0.1:6379> get money "200" watch key1 key2 ... keyN 作用:监听key1 key2..keyN有没有变化,如果有变, 则事务取消 unwatch 作用: 取消所有watch监听