Redis事务的理解与使用

Redis 事务

官方文档，永远是你学习的第一手资料：Redis 事务

1)基本认识

 谈到事务，大家首先都会联想到 mysql 中复杂但又功能强大的“事务”，和 mysql 相比，redis 所提供的事务简直就是个“弟弟”。我们从 mysql 事务的四大基本特点进行比较：

原子性：

 原子性最初的含义就是把多个操作打包到一起，要么全部执行，要么全部不执行。但是mysql 在原子性这条道路上走的更远，它要求多个操作要么全部执行成功，要么全部不执行，如果其中任一操作执行失败，都会 rollback 确保数据的一致性。

 Redis 事务可以说具有原子性，也可以说没有，这是一个理解角度的问题。Redis 事务确实可以将多个操作打包一起执行，从这方面谈，Redis 是具有原子性的；但是和 mysql 不同，Redis 事务并不保证所有命令执行成功，由于 mysql 的标杆作用“拉高”了原子性的标准，从这一方面说，Redis 并不具有原子性。

 早些版本的 Redis 官网中明确提出了， Redis 事务具有原子性，但现在去看，官网已经把第一句删掉了。看连 Redis 官方都 “怂了”，所以我们还是倾向于认为 Redis 不具有原子性

 那为什么 Redis 不提供和 mysql 一样强大的事务机制呢？首先 mysql 为了实现事务机制付出了巨大的代价，而 Redis 则是主打一个轻量简单，如果和 mysql 一样就丢了自己的特色，那又怎么从这么多数据库中冲杀出来呢？

一致性：

 由于 Redis 并不提供事务回滚机制，当其中某些操作失败时就会造成数据不一致的问题。例如以下这个场景：张三给李四转账 1000 元。张三余额 -1000 的操作成功，但是李四余额 + 1000 的操作失败，而 redis 并不会因为操作执行失败而回滚数据，从而导致数据不一致的问题发生

持久性：

 mysql 中又 redo log 保证事务的持久性，但是 redis 事务本身并不具有持久性，持久化还得依赖redis的 rdb 或者 aof 机制。但是否开启持久化，是redis-server自己的决定，和事务本身无关

隔离性：

 Redis 没有也不需要隔离性。隔离性是针对并发读写的问题而引入了，而 Redis 是一个单进程的数据库，不存在这方面的烦恼。

2)事务操作

1.MULTI

• multi 指令用于开启一个事务

  127.0.0.1:6379> multi
  OK
  1
  2

• Redis 服务端为每一个客户端维护一个事务命令队列，multi 后所有命令(除了 exec)都会被添加到队列中而不是立即执行（queued 状态）

  127.0.0.1:6379> set key1 1
  QUEUED
  127.0.0.1:6379> set key1 2
  QUEUED
  1
  2
  3
  4

2.EXEC

• exec 指令用于按次序一次性执行事务队列中命令

  127.0.0.1:6379> exec
  1) OK
  2) OK
  127.0.0.1:6379> get key1
  "1"
  1
  2
  3
  4
  5

3.错误处理

在 Redis 事务中存在两种类型的错误：

• 在调用 exec 前发生错误，例如某个指令中存在语法错误。当这种错误发生时，整个事务都会被直接丢弃

  127.0.0.1:6379> multi
  OK
  127.0.0.1:6379> get key1
  QUEUED
  127.0.0.1:6379> abc
  (error) ERR unknown command `abc`, with args beginning with: 
  127.0.0.1:6379> exec
  (error) EXECABORT Transaction discarded because of previous errors.
  1
  2
  3
  4
  5
  6
  7
  8

• 在调用 exec 期间发生的错误。在这种情况下，Redis 会继续执行剩余的命令，不管某些命令是否失败。

  127.0.0.1:6379> FLUSHALL
  OK
  127.0.0.1:6379> multi
  OK
  127.0.0.1:6379> set key1 1
  QUEUED
  127.0.0.1:6379> LPOP key1
  QUEUED
  127.0.0.1:6379> set key2 2
  QUEUED
  127.0.0.1:6379> get key2
  QUEUED
  127.0.0.1:6379> EXEC
  1) OK
  2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
  3) OK
  4) "2"
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17

  上面的案例也验证了 Redis 事务只能保证多条一起执行，但并不保证所有的命令都会执行成功。失败了也不会数据回滚，因而存在一致性的问题

4.DISCARD

• discard 指令用于终止取消当前正在执行的事务，队列中的所有指令都会被直接丢弃

  127.0.0.1:6379> multi
  OK
  127.0.0.1:6379> get key1
  QUEUED
  127.0.0.1:6379> get key2
  QUEUED
  127.0.0.1:6379> discard
  OK
  127.0.0.1:6379> exec
  (error) ERR EXEC without MULTI
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10

• 当前没有正在执行的事务，则 discard 指令无效

  127.0.0.1:6379> discard
  (error) ERR DISCARD without MULTI
  1
  2

5.WATCH

用法：

• 在执行事务期间，某个键值被其他客户端修改了，其结果就容易令人产生歧义，例如下面这个场景

  time	client_1	client_2
  t1	execute command multi
  t2	execute command set key1 1
  ……
  t3		execute command set key1 2
  t4	execute command exec

• watch 与事务配合使用，它允许你监视多个 key，如果在事务的执行期间任何一个键被其他客户端修改，都会导致当前事务全部丢弃，从而确保了事务执行期间数据的一致性。watch 的作用时间从 multi 开始到执行 exec 结束。

  // client1
  127.0.0.1:6379> mset key1 1 key2 2
  OK
  127.0.0.1:6379> watch key1 key2
  OK
  127.0.0.1:6379> multi
  OK
  127.0.0.1:6379> mget key1 key2
  QUEUED
  127.0.0.1:6379> exec 
  (nil)    // 事务执行失败
  
  // client2：在client1事务执行期间进行如下修改
  127.0.0.1:6379> incr key1
  (integer) 2
  127.0.0.1:6379> decr key2
  (integer) 1
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17

• unwatch 的作用与 watch 相反，它用于清除对所有 key 的 “watch”。在执行 exec 或者 client 退出时，所有的 key 都会 “unwatched”

原理：

 watch 本质就是一把乐观锁，通过CAS机制实现：每个 "watched " 变量都有一个初始版本号，修改变量会让其版本号变大，在执行 exec 时会比较当前版本号与 watch 时的版本号是否一致，如果不一致，说明变量在事务执行期间发生了修改，当前事务就会被 discard

案例：

下面是官方文档提供的一个使用案例，通过 watch 去创造一个新的原子操作：

WATCH zset
element = ZRANGE zset 0 0
MULTI
ZREM zset element
EXEC
1
2
3
4
5

 从 zset 中删除一个元素有两部：1)找到最小的元素 2) 将最小的元素删除。如果删除失败，说明最小值被其他客户端修改，那么我们就重复上面操作，直到删除一个最小值

6.SCRIPT

 任何 redis 事务能完成的操作，我们都可以使用 redis script 完成。redis script 天生就有把多个指令打包执行的能力，感兴趣的可以去网上找找 lua 脚本操作 redis 的教程