redis事务

概述

mysql 原子性，一致性，持久性，隔离性

特点	mysql	redis
原子性	通过回滚日志日志来保证事务的原子性	单条命令是保存原子性，但是事务不保证原子性
一致性	通过执行重做日志来保证数据的一致性
隔离性	Mysql通过锁实现隔离性
持久性	数据保存在磁盘	需要开启持久化，EDB模式需要特定条件下才能将数据保存在磁盘

redis事务本质：一组命令的集合。一个事务中的所有命令都会被序列化，在事务执行过程中，会按照顺序执行。其他客户端提交的命令请求会等到事务执行完毕再执行。

redis事务没有隔离级别的概念！

所有命令在事务中，并没有直接被执行！只有发起执行命令的时候才会执行！（本质是一组命令的集合）

redis在什么情况下会回滚？

redis在命令加入事务命令队列的时候，如果检测到错误，会回滚，一旦输入执行指令exec，即使有命令执行出错也不会回滚

MULTI、EXEC、DISCARD和WATCH命令是Redis事务功能的基础。Redis事务允许在一次单独的步骤中执行一组命令，并且可以保证如下两个重要事项：

Redis会将一个事务中的所有命令序列化，然后按顺序执行。Redis不可能在一个Redis事务的执行过程中插入执行另一个客户端发出的请求。这样便能保证Redis将这些命令作为一个单独的隔离操作执行。

在一个Redis事务中，Redis要么执行其中的所有命令，要么什么都不执行。因此，Redis事务能够保证原子性。

EXEC命令会触发执行事务中的所有命令。因此，当某个客户端正在执行一次事务时，如果它在调用MULTI命令之前就从Redis服务端断开连接，那么就不会执行事务中的任何操作；

相反，如果它在调用EXEC命令之后才从Redis服务端断开连接，那么就会执行事务中的所有操作。当Redis使用只增文件（AOF：Append-only File）时，Redis能够确保使用一个单独的write(2)系统调用，这样便能将事务写入磁盘。

然而，如果Redis服务器宕机，或者系统管理员以某种方式停止Redis服务进程的运行，那么Redis很有可能只执行了事务中的一部分操作。

Redis将会在重新启动时检查上述状态，然后退出运行，并且输出报错信息。

使用redis-check-aof工具可以修复上述的只增文件，这个工具将会从上述文件中删除执行不完全的事务，这样Redis服务器才能再次启动。

从2.2版本开始，除了上述两项保证之外，Redis还能够以乐观锁的形式提供更多的保证，这种形式非常类似于“检查再设置”（CAS：Check And Set）操作。本文稍后会对Redis的乐观锁进行描述。

案例

开启事务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


127.0.0.1:6379> multi      #开启事务
OK
127.0.0.1:6379> set k1 v1  #命令入队
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> exec       #执行事务
1) OK
2) OK
3) "v2"
4) OK

取消事务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


127.0.0.1:6379> multi       #开启事务
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> discard       #取消事务
OK
127.0.0.1:6379> get k4        #事务队列中命令都不会被执行！
(nil)

编译型异常（代码有问题！命令有错！）事务中所有的命令都不会被执行！

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


127.0.0.1:6379> multi
OK
127.0.0.1:6379> set k1 v1
QUEUED
127.0.0.1:6379> getset k1      #错误的命令
(error) ERR wrong number of arguments for 'getset' command
127.0.0.1:6379> set k4 v4
QUEUED
127.0.0.1:6379> exec            #执行事务报错
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k4          #所有的命令都不会被执行
(nil)

运行时异常（1/0），如果事务队列中存在语法型错误，那么执行命令的时候，其他命令是可以正常执行的，错误命令抛出异常！

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> incr k1
QUEUED
127.0.0.1:6379> set k2 v2
QUEUED
127.0.0.1:6379> set k3 v3
QUEUED
127.0.0.1:6379> get k3
QUEUED
127.0.0.1:6379> exec
1) (error) ERR value is not an integer or out of range  #虽然第一条命令报错了，但是依旧正常执行成功了！
2) OK
3) OK
4) "v3"
127.0.0.1:6379> get k2
"v2"
127.0.0.1:6379> get k3
"v3"

通过CAS操作实现乐观锁

那么WATCH命令实际做了些什么呢？

WATCH用于监控一个或多个key，如果在事务执行之前这个key被其他命令所改动，那么事务会被打断

WATCH命令可以被调用多次。简单说来，所有的WATCH命令都会在被调用之时立刻对相应的键进行监控，直到EXEC命令被调用之时为止。你可以在单条的WATCH命令之中，使用任意数量的键作为命令参数。

当调用EXEC命令时，所有的键都会变为未受监控的状态，Redis不会管事务是否被中止。当一个客户单连接被关闭时，所有的键也都会变为未受监控的状态。

如何使用WATCH命令实现ZPOP操作呢？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


127.0.0.1:6379> set money 100
OK
127.0.0.1:6379> set out 0
OK
127.0.0.1:6379> watch money        #监视money对象
OK
127.0.0.1:6379> multi              #事务正常结束，数据期间没有发生变动，这个时候就正常执行成功！
OK
127.0.0.1:6379> decrby money 20
QUEUED
127.0.0.1:6379> incrby out 20
QUEUED
127.0.0.1:6379> exec
1) (integer) 80
2) (integer) 20

测试多线程修改值，使用watch可以当做redis的乐观锁操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


127.0.0.1:6379> watch money        #监视money
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> incrby money 10
QUEUED
127.0.0.1:6379> exec                #执行之前，另一个线程修改了我们的值，这个时候，就会导致事务执行失败
(nil)


[root@snailsir ~]# redis-cli -p 6379
127.0.0.1:6379> set money 1000
OK

可以使用UNWATCH命令（不需要任何参数），这样便能清除所有的受监控键。当我们对某些键施加乐观锁之后，这个命令有时会非常有用。因为，我们可能需要运行一个用来修改这些键的事务，但是在读取这些键的当前内容之后，我们可能不打算继续进行操作，此时便可以使用UNWATCH命令，清除所有受监控的键。在运行UNWATCH命令之后，Redis连接便可以再次自由地用于运行新事务。

redis事务

概述

相关命令

案例

通过CAS操作实现乐观锁