redis事务

redis事务此篇博客是根据看《redis设计与实现》19章写的

redis通过MULTI、EXEC、WATCH等命令来实现事务功能.

redis事务特性：
1.事务一次性、按顺序的执行多个命令在事务执行期间
2.服务器不会中断事务去执行其他客户端的请求，会将事务中的所有命令都执行完毕，再去处理其他客户端的命令请求。

redis事务执行过程：
1.客户端以MULTI命令开始，从非事务状态切换至事务状态

2.接着将多个命令放入事务队列当中
第一点客户端已经将非事务状态切换到事务状态，服务器会根据客户端发的不同命令执行不同的操作：
1）客户端发送是事务相关的命令，服务器会立即执行事务相关命令（EXEC、DISCARD、WATCH、MULTI）
2）客户端发送是非事务相关的命令，服务器不会立即执行命令，而是将命令放入事务队列里，然后向客户端返回QUEUED回复。
命令执行流程–判断是否处于事务状态:
a.否,执行命令，返回结果
b.是,非事务相关命令，放入队列;事务相关命令，执行相应的命令，比如discard
事务队列：每个Redis客户端都有自己的事务状态，事务状态里又包含一个事务队列、已入队命令计数器（事务队列的长度），事务队列是一个multiCmd类型的数组。最先入队命令放在事务队列的索引0位置上，第二入队的命令放在事务队列的索引1位置。

3.最后由EXEC命令将事务提交
当一个处于事务状态的客户端向服务器发送EXEC命令时，这个EXEC命令将立即被服务器执行。服务器会遍历这个客户端的事务队列，执行队列中保存的所有命令，最后将执行命令所得的结果全部返回给客户端。

常用的事务命令：MULTI、EXEC、DISCARD、WATCH、UNWATCH
WATCH:watch是用于在事务之前，监视某个key或多个key,当执行exec,如果任意一个key已经被其他客户端修改就不再执行，执行就失败并向客户端返回代表事务执行失败空的回复。
客户端1

客户端2修改
客户端1执行失败

Redis通过谨慎的错误检测和简单的设计来保证事务的一致性：
1.入队错误
首先开启事务,向客户端输入非事务命令，每执行一条命令，都放入队列中。说明在事务提交之前，其内部都不会被执行。如果一个事务在入队命令的过程中，出现了命令不存在，或者命令的格式不正确等情况，那么Redis将拒绝执行这个事务。
客户端在输入命令uuuu时redis已经知道这是错误命令，所以再去执行exec的话整个事务的命令就会全部失败。

2.执行失败
客户端在输入某个错误命令没有发现错误，incr job我们知道执行这个命令是会报错，但是在开启事务后在未执行exec前都放入队列中，执行exec后报错，发现其他正确命令都执行，错误命令没有执行。若在在入队时有报错，整个事务内的命令都会失败，入队时没有报错，在执行时报错，redis默认会跳过这个错误命令继续执行。Redis的事务和传统的关系型数据库事务的最大区别在于，Redis不支持事务回滚机制。

3.服务器停机
如果Redis服务器在执行事务的过程中停机，那么根据服务器所使用的持久化模式，可能有以下情况出现：
1）如果服务器运行在无持久化的内存模式下，那么重启之后的数据库将是空白的，因此数据总是一致的。
2）如果服务器运行在RDB模式下，那么在事务中途停机不会导致不一致性，因为服务器可以根据现有的RDB文件来恢复数据，从而将数据库还原到一个一致的状态。如果找不到可供使用的RDB文件，那么重启之后的数据库将是空白的，而空白数据库总是一致的。
3）如果服务器运行在AOF模式下，那么在事务中途停机不会导致不一致性，因为服务器可以根据现有的AOF文件来恢复数据，从而将数据库还原到一个一致的状态。如果找不到可供使用的AOF文件，那么重启之后的数据库将是空白的，而空白数据库总是一致的。
综上所述，无论Redis服务器运行在哪种持久化模式下，事务执行中途发生的停机都不会影响数据库的一致性。

隔离性：Redis使用单线程的方式来执行事务（以及事务队列中的命令），并且服务器保证，在执行事务期间不会对事务进行中断。数据库有多个事务并发执行，各事务之间不会互相影响，在并发状态下执行的事务和串行执行的事务产生的结果完全相同。

持久性：Redis事务是简单用队列包含了Redis命令，并没有为事务提供任何持久化功能。