Redis中的事务

一、什么是Redis的事务

Redis官网对其事务是这样描述的：

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

二、事务相关命令

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

使用MULTI+EXEC模拟用户1给用户2转账

127.0.0.1:6379> MULTI # 开启事务
OK # 总是返回OK
127.0.0.1:6379> set user1:money 100 # 用户1余额100
QUEUED # 命令入队
127.0.0.1:6379> INCRBY user2:money 100 # 用户1给用户2转账100
QUEUED
127.0.0.1:6379> DECRBY user1:money 100 # 扣除用户1余额
QUEUED
127.0.0.1:6379> EXEC # 执行事务，返回事务队列中所有命令的执行结果
1) OK
2) (integer) 100
3) (integer) 0
127.0.0.1:6379> get user1:money # 查看用户1余额
"0"
127.0.0.1:6379> get user2:money # 查看用户2余额
"100"

使用DISCARD取消事务

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set name Tom 
QUEUED
127.0.0.1:6379> lpush list a b c
QUEUED
127.0.0.1:6379> DISCARD # 取消事务
OK
127.0.0.1:6379> get name # 事务取消，事务队列中的命令没有执行，所以返回nil
(nil)
127.0.0.1:6379> LRANGE list 0 -1
(empty array)

使用WATCH监视key，使用UNWATCH取消监视

session1在EXEC执行事务之前，session2对已经被监视的user1:money 作了修改，所以EXEC不会执行事务队列中的命令；

三、事务概念再理解

• 关于一组操作：
  • 关系型数据库中的事务是一组sql，或者一组业务；
  • redis中的事务是一组命令;
  • 其实在这一点上，两者是没有区别的。
• 关于隔离性：
  • 关系型数据库中的事务之间是有隔离级别的，级别不同，事务之间的可见度也就不同；
  • redis中的事务没有隔离级别的概念，事务跟事务之间是完全隔离，或者说就是按顺序执行的。
• 关于原子性：
  • 关系型数据库中的原子性是一组操作要么全部成功，要么全部失败，这意味着，如果其中有一条sql执行失败，就必须要回滚所有执行过的sql；
  • redis中的事务原子性是一组操作要么全部执行，要么全部不执行，即使有一条命令执行失败，也不影响其他命令的执行；
  • 这区别就大了，所以说redis中的事务是相对弱化的

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

这里直接引用官方描述

如果你有使用关系式数据库的经验， 那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。

以下是这种做法的优点：

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

有种观点认为 Redis 处理事务的做法会产生 bug ， 然而需要注意的是， 在通常情况下， 回滚并不能解决编程错误带来的问题。 举个例子， 如果你本来想通过 INCR命令将键的值加上 1 ， 却不小心加上了 2 ， 又或者对错误类型的键执行了 INCR， 回滚是没有办法处理这些情况的。