认识Redis的事务
事务在mysql中非常常见，也是一个非常重点的内容，其具有以下特性
原子性：把多步操作打包成一步，要么全都完成要么全不完成
一致性：操作前后数据保持逻辑一致
持久性：事务中的修改存入硬盘
隔离性：事务的并发进行
而Redis的事务和mysql比算是个半成品
redis是否具有原子性？看怎么对待
redis同样也是把多个操作打包，要么全都执行要么不执行，但其不保证执行的正确性，也不支持回滚操作，而mysql的原子性是执行正确，若出错可以回滚，因此是否有原子性存在争议。
因此，一致性也不保证：因为其不保证操作的正确性，也不可以回滚
持久性：虽然redis有持久化机制，但和事务的持久性没啥关系，其本身就是一个内存数据库
隔离性：不涉及（单线程模型服务器，串行执行任务）
Redis中的事务
在redis中实现事务，每个客户端引入了一个队列
并不是连上服务器就有队列，当我们开启事务的时候才有，此时我们在客户端输入命令，其不会立即执行，而是放入队列中，当遇到执行事务时，会把队列的任务按顺序全部执行（主线程执行，执行后处理别的客户端）
为什么不用mysql？mysql强大的功能后背负着时间和空间的代价，所以redis的快就脱颖而出了。
Redis事务的相关命令
开启事务：multi
执行事务：exec
放弃当前事务：discard
这个返回值告诉我们操作并未执行，而是放入已队列中，此时服务器中是没有这两个key的
只有我们输入exec才能完成设置
如果任务入队列了但服务器突然重启，等同于discard
监控某个key：watch（事务外的命令，先监控再开启事务）（必须搭配事务使用）
监控key在事务执行前（从开始事务到事务执行）是否发生改变
如果监控到确实改变了，那么事务的执行结果返回nil（不执行任务）
watch的实现原理：类似于乐观锁
乐观锁：加锁前认为锁竞争冲突概率低 低成本（只是象征性加个锁，被抢了也不会大惊失色）
悲观锁：。。。概率高 高成本（全力避免锁被抢）
c++/linux中的锁都是悲观锁
两种锁要做的工作是不同的。
watch相当于基于版本号的机制实现了乐观锁
当执行watch key时，给key一个版本号（数字），每次修改时，版本号会变大
如果另一个客户端，对key进行任何的修改版本号就会改变
原来的客户端执行事务时会判定key的版本号和watch的key版本号是否一致
一旦发现不一致，就会认为被其他客户端修改过了，就会直接丢弃返回nil