事务的基本概念

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

Redis事务相关的几个命令

• multi：MULTI 命令用于开启一个事务，它总是返回 OK 。 MULTI 执行之后， 客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 当 EXEC命令被调用时， 所有队列中的命令才会被执行。

• exec ：执行所有的事物命令，EXEC 命令的回复是一个数组， 数组中的每个元素都是执行事务中的命令所产生的回复。 其中， 回复元素的先后顺序和命令发送的先后顺序一致。 当客户端处于事务状态时， 所有传入的命令都会返回一个内容为 QUEUED 的状态回复（status reply）， 这些被入队的命令将在 EXEC 命令被调用时执行。

• discard： 通过调用 DISCARD ， 客户端可以清空事务队列， 并放弃执行事务。

• watch key [key ...]：监视一个或多个key(类似于乐观锁)
• unwatch：取消watch对所有key的监视

Redis事务的三个阶段

• 开始事务：使用multi命令开启一个事务，当一个事务被exec或discard后，改事务就宣告结束（无论有没有成功执行），下次在向开启事务就必须在使用这个命令开启事务。
• 命令入队：简单点说就是，开启事务后输入的命令不会立即执行，而是先入队，执行当exec后在一次性执行。
• 执行事务：使用exec命令执行事务

Redis事务使用示例： 1、正常执行

3、事务在执行 EXEC 之前，入队的命令可能会出错(语法上就是错误的)，执行exec时，整个事务都会失败。

4、事命令可能在 EXEC 调用之后失败（语法上没有错误，但是调用执行的时候出错了），在执行exec命令时，其他正确的命令可以正确执行，错误命令抛出错误

为什么Redis不支持事务回滚？

通过上面的案例我们可以看到redis在事务中发生错误后是没有回滚的，而是继续执行余下的命令，那么redis为什么不支持事务回滚呢？从各方面考虑有以下两点原因：

• Redis命令只会因为错误的语法而失败，或是命令用在了错误类型的键上面，也就是说，从实用的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发过程中别发现，而不应出现在生产环境中。而且需要注意的是在通常情况下， 回滚并不能解决编程错误带来的问题。
• 因为redis不需要支持事务回滚，所以他可以在内部保持简单和快捷。

5、使用watch监控 WATCH 命令可以为 Redis 事务提供 check-and-set （CAS）行为。被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回nil-reply来表示事务已经失败。下面使用很典型的账户和消费问题来展示一下watch的作用。 案例一：使用watch检测balance，事务期间balance数据未变动，事务执行成功

案例二：使用watch检测balance，在开启事务后（标注1处），在新窗口执行标注2中的操作，更改balance的值，模拟其他客户端在事务执行期间更改watch监控的数据，然后再执行标注1后命令，执行EXEC后，事务未成功执行。