redis 事务
事务
可一次执行多个命令，本质上上一组命令的集合。一个事务的所有命令都会被序列化，按照顺序串行化执行，在执行期间不允许其他命令加塞进来 ；
常用命令
Discard取消事务，放弃执行事务块内的所有命令Exec执行所有事务块内的命令Multi标记一个事务块的开始Unwatch取消watch命令对所有key的监视watch key [key2 key3 ... keyN]监视一个或多个key，如果在事务执行之前，被监视的key被其他命令所改动，则事务将会被打断 ；
正常执行
使用 multi 命令开启事务，然后所有的操作，都会被放到一个 queen 里面，待收到 EXEC 命令，就会将 queen 里面的命令按顺序执行；
开启事务，可以一次执行一堆命令 ；
放弃事务
在往事务块里面添加命令的时候 ，使用 discard 可以清空事务块的所有命令，也就是放弃本次事务 ；
全体连做
在往事务添加命令的时候，如果有一个 错误的命令 ，添加到了事务块里面，Redis 会立马抛出一个错误，在执行 exec 命令的时候，会失败，事务不会得到执行 ；
冤有头债有主
如果在往事务里面添加命令的时候，虽然你的操作可能会报错，但是你的命令是正确的，redis 是不会知道你执行以后到底错误与否的，所有不会报错；
在执行 exec 的时候，其他命令会得到执行，但是执行出错的命令，会抛出一个错误 ；
redis 到底支不支持事务
支持是肯定支持的，但是不是向 mysql 的事务那样强烈，有一条命令操作引起异常，则全部回滚掉 ；
redis 是部分支持，如果你给我一个错误的命令，那么我全部不执行，如果你给我一个正确的命令，我就执行，但是命令执行以后的错误，不关我事了 ；
所以， redis 是不支持原子性的，也就是不会进行回滚 ；
Watch 监控
-
悲观锁
顾名思义，就是很悲观，每次取拿数据的时候，都认为别人会改动数据，所以每次在拿数据的时候，都会上锁，这样其他线程想要拿数据，就只能等；
传统的关系型数据库里面的行锁、表锁、读锁、写锁，都是这种锁机制 ，在操作之前先上锁；
影响高并发 ；
-
乐观锁
顾名思义，就是很乐观，每次去拿数据的时候，都认为别人不会修改，所以不会上锁，但是在更新的时候，会判断一下再此期间别人有没有更新该条记录，可以使用版本号机制进行判断。
乐观锁适用于多读的应用类型 ，提高吞吐量；
-
CAS（check and set）
watch 类似于 乐观锁 的存在，对 Key 进行 Watch 以后，再开启事务 multi ，在执行 exec 之，在事务期间之外，如果发现监视的 key被修改过，不论是谁改动，事务都将执行失败 ；
一旦执行 exec ，无论事务成功执行与否，对 key 的监视，都将被取消掉 ；
