redis 的事务

先来说说什么是事务:

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

• 事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

redis 相关的命令:

• MULTI 开启事务
  • 标记一个事务块的开始。 随后的指令将在执行EXEC时作为一个原子执行。
• EXEC 执行事务
  • 执行事务中所有在排队等待的指令并将链接状态恢复到正常 当使用WATCH 时，只有当被监视的键没有被修改，且允许检查设定机制时，EXEC会被执行
• DISCARD 放弃事务
  • 刷新一个事务中所有在排队等待的指令，并且将连接状态恢复到正常。如果已使用WATCH，DISCARD将释放所有被WATCH的key。
  • 当执行 DISCARD 命令时， 事务会被放弃， 事务队列会被清空， 并且客户端会从事务状态中退出
• WATCH
  • 标记所有指定的key 被监视起来，在事务中有条件的执行（乐观锁）。
  • 被 WATCH 的键会被监视，并会发觉这些键是否被改动过了。 如果有至少一个被监视的键在 EXEC 执行之前被修改了， 那么整个事务都会被取消， EXEC 返回nil-reply来表示事务已经失败。

一图讲解:

• client1 早于 client2 开始事务 (multi开启事务)

• client2 早于 client1 触发执行事务(exec 执行事务)

• 结果: client2 先执行删除k1操作 client1读k1为 null
  

• client1 先执行监视k1操作

• client2 先触发执行事务操作,删除了k1

• 当client1 执行 get k1 操作时,由于client2 修改了k1且开启了watch操作,则不执行get操作
  

为什么 Redis 不支持回滚（roll back）

以下是这种做法的优点：

• Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
• 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。