Redis事务

今天有空了再来了解一下Redis的事务吧，毕竟听说Redis的事务和关系型数据库还是不太一样的！

定义

Redis 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。

Redis 事务的主要作用就是串联多个命令防止别的命令插队。

语法

Multi、Exec、discard
从输入 Multi 命令开始，输入的命令偶会依次进入 命令队列 中，但不会执行，直到输入Exec后,Redis会将之前的命令队列中的命令依次执行。

组队的过程中可以通过 discard 来放弃组队

案例

1.组队阶段成功，提交阶段也成功

2.组队阶段失败（语法错误），导致提交阶段全部失败

3.组队阶段成功（语法正确），但是执行阶段有成功也有失败（非数字 value 不支持 incr）

总结：
1.组队阶段某个命令出现错误，执行阶段整个队列都会被取消。
2.组队阶段正常，执行阶段某个命令出现错误，则只有报错的命令不被执行，而其他命令都会执行，不会回滚。

事务冲突问题

咱都了解过事务冲突的问题，简单来说就是同一条数据，线程A在修改的时候，如果线程B也在在修改就产生了冲突问题。
解决事务冲突问题通常有悲观锁和乐观锁两种方式。

大白话絮叨两句：悲观锁就是线程（事务）A在修改的时候上锁，不允许别的线程（事务）去修改；乐观锁就是每个线程（事务）都可以直接去修改同一条数据，只是修改前瞅一眼数据，修改的时候只要这个数据没变化就修改，有变化（被别的线程/事务修改了）就修改失败。

不明白悲观锁、乐观锁的话得先去了解一下。

解决方案

WATCH key [key …]

Redis就是以乐观锁的方式在处理事务冲突问题。

在执行 Multi 之前，先执行 watch key1 [key2]，可以监视一个（或者多个）key，如果在事务执行之前这个（或这些）key 被其他命令所改动，那么事务将被打断。

UNWATCH

取消 WATCH 命令对所有 key 的监视。

如果在执行 WATCH 命令之后，EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行 UNWATCH 了。

Redis 事务三大特性

1. 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令打断。
2. 没有隔离级别的概念：队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行
3. 不保证原子性：事务中如果有一条命令执行失败，其后的命令仍然会被执行

这就是和关系型数据库事务的区别喽！