1.redis的事务是基于队列实现的
mysql的事务是基于事务日志和锁机制实现的
redis是乐观锁机制
redis与mysql事务的区别：
mysql事务是一开始就在内存里面执行了，只是还没有提交。
而redis是把任务放在队列里，还没有执行。只有exec的时候，才是真正的执行了。
开启事务
multi #进入事务
command1 #要执行的命令
command2 #要执行的命令
command3 #要执行的命令
command4 #要执行的命令
exec #执行
discard #取消执行
4条语句作为一个组，并没有真正执行，而是被放入同一队列中。
如果，这时执行discard，会直接丢弃队列中所有的命令，而不是做回滚。
当执行exec时，队列中所有操作，要么全成功要么全失败
redis事务还有监听命令
watch key
乐观锁悲观锁
乐观锁：顾名思义很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量
悲观锁：顾名思义很悲观，每次去拿数据的时候都认为别人修改，所以每次在拿数据的时候都会上锁，这样如果中间有人想拿数据就会一直阻塞除非锁被释放获取到锁。传统的关系型数据库里，用到了很多种这种锁机制，比如行锁，表锁，写锁等
2.在mutil后面的语句，语句出错可能有两种情况
2.1 语法就有问题，此时exec报错，所有语句得不到执行
2.2 语法本身没错，但适用对象有问题，exec之后会执行正确的语句，并跳过有问题的语句
3.redis事务3特性
3.1 单独的隔离操作：事务中所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
3.2 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被执行，
也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
3.3 不保证原子性:redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚