Redis事务
Redis 事务提供了一种将多个命令请求打包的功能。然后，再按顺序执行打包的所有命令，并且不会被中途打断。
但是，事务中的每条命令都会与 Redis 服务器进行网络交互，比较浪费资源
所以，日常开发中不建议使用Redis事务
Redis事务操作
使用redis事务的过程是这样的：
- 开始事务（MULTI）；
- 命令入队(批量操作 Redis 的命令，先进先出的顺序执行)；
- 执行事务（EXEC）。
你也可以通过DISCARD命令取消一个事务
MULTI命令后可以输入多个命令，Redis 不会立即执行这些命令，而是将它们放到队列，当调用了 EXEC 命令后，再执行所有的命令。
举例
1.首先我们在客户端1开启事务，然后设置key1为111
2.然后在客户端2获取key1，是获取不到的
3.这时候执行事务
4.再去客户端2里查询key1，可以查到
watch操作
你可以通过WATCH命令监听指定的 Key，当调用exec命令执行事务时，如果一个被watch命令监视的 Key 被 其他客户端/Session 修改的话，整个事务都不会被执行。
会发生三种情况：
1.同一个session中，watch监视的key在multi之前被修改，那么这个事务不会被执行
2.同一个session中，watch监视的key在事务内部被修改，那么这个事务还是会执行成功
3.同一个session中，watch监视的key在事务内部被修改，但是在事务提交之前被其他 session 修改，那么事务不会被执行
下面是第三种情况举例
举例
1.首先我们在客户端1设置一个key1为111，然后使用watch监听key1，然后开启事务，操作key1
2.这时候，我们去客户端2修改key1
3.客户端1提交事务，发现提交失败。发现key1是客户端2修改的值，也就是客户端1的事务并没有执行成功
Redis事务特性
我们知道事务具有四大特性：
1. （A）原子性，2.（C） 一致性，3.（I） 隔离性，4.（D） 持久性。
但是，在Redis 中不太一样
Redis事务不具备原子性
原子性是指务是最小的执行单位，不允许分割。事务的原子性确保动作要么全部完成，要么完全不起作用。但是，在redis中，并没有约束和回滚机制，如果事务中的命令出现执行失败的情况，也不会回滚，其他命令依然会执行成功
Redis事务不具备一致性
redis没有约束，也没有回滚机制，事务执行过程中如果某个修改操作出现失败，就可能引起不一致的情况
况且，我们通常说AID保证C，连AID都无法保证，那一致性也更不用说了
Redis事务不涉及隔离性
因为redis是一个单线程模型的服务器程序，所有请求和事务都是串行执行的，自然也就不讨论有没有隔离性了
Redis事务不具备持久性
redis本身就是内存数据库，数据存储在内存中，是不具备持久性的
虽然redis也提供了RDB和AOF这样的持久化机制，但和事务没啥关系
redis事务的错误
1.若在事务队列中存在命令性错误，则执行EXEC命令时，所有命令都不会执行
2.若在事务队列中存在语法性错误，则执行EXEC命令时，其他正确命令会被执行，错误命令抛出异常。
总之，在命令入队时，redis会简单检查语法是否出错，如果出错，视为整个事务无效
但是如果逻辑错了，命令入队的时候是不检查的，只有执行的时候才报错，但其他操作也不会回滚
命令性错误
只有出错的命令不会执行，其他命令依然会执行，这违反了事务的原子性
语法（编译）性错误
在事务中，出现语法错误，会直接报错，后面就算再用exec，之前输入的操作也不会提交执行。
也就是整个事务都不会执行
)
