Redis 事务

先放一个大佬的文章：聊一聊Redis事务

一、什么是Redis 事务

可以一次执行多个命令，本质是一组命令的集合。一个事务中的所有命令都会序列化，按顺序串行化执行，而不会被其他命令插入。

二、事务可以用来做什么

一个队列中，可以一次性、顺序性、排他性的执行一系列命令。

三、如何使用

可以通过 MULTI 命令来开启一个 Redis 事务，该命令在执行后总会返回 OK。在执行该命令之后，用户便可以发布多条 Redis 命令。Redis 并不会立即执行这些命令，而是将它们放入到一个队列中。所有的命令将会在调用 EXEC 命令后被执行。调用 DISCARD 命令将会清空事务队列中的所有命令，并且退出事务。

3.1 Redis 事务命令

• DISCARD：取消事务，放弃执行事务块内的所有命令。
• EXEC：执行所有事务块内的命令。
• MULTI：标记一个事务块的开始。
• UNWATCH：取消 WATCH 命令对所有 key 的监视。
• WATCH key [key …]：监视一个(或多个) key ，如果在事务执行之前这个(或这些) key 被其他命令所改动，那么事务将被打断。

3.2 命令演示

3.2.1 正常执行

3.2.2 放弃事务

3.2.3 全体连坐

队列中只要其中任意一条命令的语法有问题都会导致整个事务的执行失败。

3.2.4 冤有头债有主

先将 k1 设置成 aa

再执行事务：

k1 的值为 aa，非数字值，而 INCR 命令只适用于数字值。这种错误属于运行时错误。当事务中有运行时错误时，也只有出现运行时错误的命令会执行失败，对于事务中的其他命令的执行并没有影响。从这也可以看出，Redis 事务本身并不支持原子性，无法做到像 MySQL或者 Oracle 那样，一旦事务中出现错误，立即回滚。

3.2.5 watch 命令

3.2.5.1 悲观锁

悲观锁（Pessimistic Lock），顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人向拿这个数据就会阻塞（block）直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作前先上锁。

3.2.5.2 乐观锁

认为线程安全不一定会发生，因此不加锁，只是在更新数据时去判断有没有其他线程对数据做了修改。如果没有修改则认为是安全的，自己才更新数据；如果已经被其他线程修改说明发生了线程安全问题，此时可以重试或者抛出异常。

3.2.5.3 watch 命令

以转账为例，先来看下转账成功：

执行失败的情况：

watch 指令，类似于乐观锁，事务提交时，如果 key 的值已被别的客户端改变，比如某个 list 已被别的客户端 push/pop 过了，整个队列都不会别执行。
通过 watch 命令在事务执行前监控了多个 key，倘若在 watch 之后有任何 key 的值发生了变化，EXEC 命令执行的事务都将被放弃，同时返回 Nullmulti-bulk 应答以通知调用者事务执行失败。

四、总结

1、Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证：

• 批量操作在发送 EXEC 命令前被放入队列缓存。
• 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。
• 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。

2、一个事务从开始到执行会经历以下三个阶段：

• 开始事务：以 MULTI 开始一个事务
• 命令入队：将多个命令入队到事务中，街道这些命令并不会立即执行，而是放到等待执行的事务队列里面。
• 执行事务：由 EXEC 命令触发事务

3、Redis 的事务特性：

• 单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
• 没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在“事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
• 不保证原子性：Redis 同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。