Redis中的事务_redis事务

1.Redis事务的定义

Redis事务是一个单独的隔离操作,事务中的所有命令都会序列化,然后按照顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
其实就是一个缓存队列,将所有任务放入,然后再某一个阶段,将其中的任务拿出来依次执行。
Redis事务和关系型数据库的事务不太一样,它不保证原子性,也没有隔离级别的概念,放入缓存队列中的任务并不会被执行,更不会返回什么。
在Redis中单条命令是原子性的但是事务并不是原子性的,事务其中一条命令执行失败其他的任务照常执行,更不存在回滚。

(1) 关于队列

注:队列(Queue)简称队,是一种操作受限的线性表,只允许在表的一端进行插入,而在表的另一端进行删除。向队列中插入元素称为入队或进队,删除元素称为出队或离队。其操作特性为先进先出(First In First Out，FIFO),并且只允许在队尾进，队头出。

(2) 关于原子性

注:原子性(Atomicity)在场景中理解就是一个不会被中断的线程操作,这种操作一旦开始,就一直运行到结束,中间不会有任何 context switch (切换到另一个线程)。在单线程中,能够在单条指令中完成的操作都可以认为是"原子操作(atomic operation)",因为中断只能发生于指令之间。在多线程中,不能被其它进程x线程打断的操作就叫原子操作。
Redis单命令的原子性主要得益于Redis的单线程。

2. Multi / Exec / discard

Multi / Exec / discard 三条命令都是Redis操作事务使用的命令,从输入Multi命令开始,输入的命令都会依次进入命令队列中,但不会执行,直到输入Exec后,Redis会将之前的命令队列中的命令依次执行。

(1) Redis事务的三个阶段

1. 第一阶段: 开启事务
2. 第二阶段: 命令入队
3. 第三阶段: 执行事务

小编画了一张图,希望有助于大家的理解,下面的内容也将按照这张图片来讲解。

(2) Multi

执行 Multi 命令,标识一个事务的开启,Redis进入组队阶段,接下来执行的命令都将放入一个缓存队列,注意命令并不会被执行只是加入缓存队列,只有执行Exec命令队列里面的命令才会按照顺序一一开始执行,从而Redis的事务就不会导致数据脏读,不可重复读,幻读的问题,因此就没有隔离级别。

本地Redis:0>Multi // 开启事务
"OK"
本地Redis:0>set j1 1 // 命令组队
"QUEUED" // 组队成功
本地Redis:0>set j2 2
"QUEUED"
本地Redis:0>Exec // 开始执行事务中的命令
1) "OK"
2) "OK"
1
2
3
4
5
6
7
8
9

注意: 在开始事务后组队阶段某个命令出现了报告错误,整个队列都将会被取消,缓存队列中的命令全部作废取消

本地Redis:0>Multi // 开启事务
"OK" // 开启成功
本地Redis:0>set k1 1 // 命令入队
"QUEUED" // 入队成功
本地Redis:0>set k2 // 没有设置value 命令错误
"ERR wrong number of arguments for 'set' command" // 发生报错 整个队列取消
本地Redis:0>
1
2
3
4
5
6
7

(3) discard

在命令组队阶段可以执行 discard 命令,放弃在组队的事务,对于已经存在缓存队列中的命令不会执行全部作废,关闭当前事务

本地Redis:0>Multi // 开启事务
"OK" // 开启成功
本地Redis:0>set j1 1 // 命令入队
"QUEUED" // 入队成功
本地Redis:0>set j2 2
"QUEUED"
本地Redis:0>discard  // 中断关闭事务
"OK" // 关闭成功
本地Redis:0>
1
2
3
4
5
6
7
8
9

(4) Exec

在开始事务后,要入队的命令全部入队后,可以执行Exec命令,缓存队列中的命令将会按照顺序一一执行

本地Redis:0>Multi // 开启事务
"OK"
本地Redis:0>set j1 1 // 命令组队
"QUEUED" // 组队成功
本地Redis:0>set j2 2
"QUEUED"
本地Redis:0>Exec // 开始执行事务中的命令
1) "OK"
2) "OK"
1
2
3
4
5
6
7
8
9

注意: 在执行完Exec命令队列里执行的命令发生错误的话,只有发生错误的命令不执行,其他没有报错的命令照常执行

本地Redis:0>Multi // 开启事务
"OK"
本地Redis:0>set v1 v1 // 命令入队
"QUEUED"
本地Redis:0>incr v1 // 字符串值无法加一 这条命令是有问题的
"QUEUED" // 命令入队成功
本地Redis:0>Exec // 开始执行命令
1) "OK"
2) "OK" // 其他命令照常执行
3) "OK"
4) "ERR value is not an integer or out of range" // 其中一条命令发生错误
5) "OK"
本地Redis:0>
1
2
3
4
5
6
7
8
9
10
11
12
13

3.悲观锁和乐观锁

接下来要讲解的WATCH和UNWATCH两条命令会设置到悲观锁和乐观锁两个概念,所以小编在这里简单介绍一下悲观锁和乐观锁。

(1) 悲观锁

悲观锁(Pessimistic Lock), 顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。
但是在效率方面，处理加锁的机制会产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，如果已经锁定了一个线程A，其他线程就必须等待该线程A处理完才可以处理。

(2) 乐观锁

乐观锁(Optimistic Lock), 顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据，可以使用版本号等机制。乐观锁适用于多读的应用类型，这样可以提高吞吐量。Redis就是利用这种check-and-set机制实现事务的。
相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本（version）或者是时间戳来实现，不过使用版本记录是最常用的。
乐观控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。

(3) 总结

悲观锁阻塞事务,乐观锁回滚重试：它们各有优缺点，不要认为一种一定好于另一种。像乐观锁适用于写比较少的情况下，即冲突真的很少发生的时候，这样可以省去锁的开销，加大了系统的整个吞吐量。但如果经常产生冲突，上层应用会不断的进行重试，这样反倒是降低了性能，所以这种情况下用悲观锁就比较合适。

4. WATCH / UNWATCH

(1) WATCH key [ key…]

在执行multi命令之前,可以先执行WATCH key (监视一个或者多个key),如果在事务执行之前watch监视的一个或者多个key被其他命令改动,那么事务将会被打断,有点类似我们上面介绍的乐观锁

(2) UNWATCH

取消 WATCH 命令对所有 key 的监视,如果在执行 WATCH 命令之后,EXEC 命令或DISCARD 命令先被执行了的话,那么就不需要再执行UNWATCH 了。

5.Redis中的三个特性

(1) 单独隔离操作

事务中的所有命令都会序列化,按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。

(2) 没有隔离级别的概念

队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行

(3) 不保证原子性

事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

6. 结尾

那么关于Redis中的事务小编就介绍到这里了,如果有错误的地方或者需要补充的地方,各位读者朋友可以在评论区提出来,后续专栏将会推出更多优质内容,期待的小伙伴可以给小编点个关注。