redis之事务

文章目录

• ​​1.概述​​

• ​​1.1.官网​​
• ​​1.2.redis特点总结：​​

• ​​1.2.1.顺序执行​​
• ​​1.2.2.不受其他客户端的影响​​

• ​​2.redis的四个命令符号​​

• ​​2.1.MULTI：开启事务​​
• ​​2.2.EXEC：执行事务​​
• ​​2.3.DISCARD：取消事务​​
• ​​2.4.WATCH：监事事务​​

• ​​2.4.1.案例​​

• ​​3.事务提交前后的问题​​

• ​​3.1.事务提交exec前出现异常：一般都是语句格式不符合规范导致​​
• ​​3.2.事务提交exec后出现异常：一般都是redis内部的数据冲突导致，比如类型​​
• ​​3.3.redis为什么不支持回滚​​

• ​​3.3.1.由于不需要回滚，这使得Redis内部更加简单，而且运行速度更快​​
• ​​3.3.2.数据冲突导致的错误，开发过程中一般都是能发现的，实际还是为了保证速度​​

1.概述

1.1.官网

​​https://redis.io/topics/transactions​​

All the commands in a transaction are serialized and executed sequentially. 
It can never happen that a request issued by another client is served in the middle of the execution of a Redis transaction. 
This guarantees that the commands are executed as a single isolated operation.
一个事务中的所有命令，需要被序列化，然后顺序执行;
在事务执行的过程中，永远不会发生另外一个事务的请求;
这样保证了所有命令单个隔离的去执行;

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

​​http://redisdoc.com/topic/transaction.html​​

1.2.redis特点总结：

1.2.1.顺序执行

1.2.2.不受其他客户端的影响

2.redis的四个命令符号

MULTI, EXEC, DISCARD and WATCH are the foundation of transactions in Redis. They allow the execution of a group of commands in a single step, with two important guarantees:

2.1.MULTI：开启事务

2.2.EXEC：执行事务

1.通过银行转账的案例去理解：
   gaoxinfu当前有1000元，zhaobolun当前有500元，gaoxinfu转账给zhaobolun 100元
2.multi 执行后，客户端可以继续向服务器发送任意多条命令， 这些命令不会立即被执行， 而是被放到一个队列中， 
  当 exec 命令被调用时， 所有队列中的命令才会被执行。

127.0.0.1:6379> set gaoxinfu 1000
OK
127.0.0.1:6379> set zhaobolun 500
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> DECRBY gaoxinfu 100
QUEUED
127.0.0.1:6379> INCRBY zhaobolun 100
QUEUED
127.0.0.1:6379> EXEC
1) (integer) 900
2) (integer) 600
127.0.0.1:6379> get gaoxinfu
"900"
127.0.0.1:6379> get zhaobolun
"600"
127.0.0.1:6379>

2.3.DISCARD：取消事务

通过exec 的命令执行事务。如果没有执行exec，所有的命令都不会被执行。如果中途不想执行事务了，怎么办？
  可以调用discard 可以清空事务队列，放弃执行。

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set name gaoxinfu
QUEUED
127.0.0.1:6379> set age 18
QUEUED
127.0.0.1:6379> set sex m
QUEUED
127.0.0.1:6379> DISCARD
OK
127.0.0.1:6379> get name 
(nil)
127.0.0.1:6379> get age
(nil)
127.0.0.1:6379> get sex
(nil)
127.0.0.1:6379>

2.4.WATCH：监事事务

在Redis 中还提供了一个watch 命令。
它可以为 Redis 事务提供CAS乐观锁行为（ Check and Set /

2.4.1.案例

1.首先在客户端A设置gaoxinfu的值为1000元
  然后进行watch监视，开启事务
2.在Client-A开启事务之后，exec执行之前，Client-b进行原子性操作：DECRBY gaoxinfu 100
3.在Client-A上 执行exec命令提交事务，发现提交失败，就是因为watch之后gaoxinfu的值发生了变化，导致的

3.事务提交前后的问题

3.1.事务提交exec前出现异常：一般都是语句格式不符合规范导致

127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> set name gaoxinfu
QUEUED
127.0.0.1:6379> hset ename frank
(error) ERR wrong number of arguments for 'hset' command
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379>

如何exec执行事务之前，事务中命令有异常，那么这个事务提交会失败，并且会回滚discard
这里exec执行之前发现的异常，一般都是语句格式不符合规范导致

3.2.事务提交exec后出现异常：一般都是redis内部的数据冲突导致，比如类型

127.0.0.1:6379> FLUSHALL
OK
127.0.0.1:6379> MULTI 
OK
127.0.0.1:6379> set name gaoxinfu
QUEUED
127.0.0.1:6379> hset name ename frank
QUEUED
127.0.0.1:6379> EXEC
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
127.0.0.1:6379>

上面的set name gaoxinfu和hset name ename frank格式上都是没有错误的，所以进入了执行队列；
set name gaoxinfu执行完成之后，name的type就是String类型的，所以在此执行hset name ename frank
相当于让name的type类型变为hash显然是不可能的
执行完上面的命令之后，我们过来查询name的值，发现第一个语句set name gaoxinfu已经提交成功

127.0.0.1:6379> get name
"gaoxinfu"
127.0.0.1:6379>

很明显，exec后执行命令，出现异常，前面执行的命令并没有回滚

3.3.redis为什么不支持回滚

3.3.1.由于不需要回滚，这使得Redis内部更加简单，而且运行速度更快

3.3.2.数据冲突导致的错误，开发过程中一般都是能发现的，实际还是为了保证速度