Redis篇之Redis事务

Redis事务

Redis事务的本质是一组命令的集合

一个事务中所有命令会按照顺序串行化执行队列中的命令,其他客户端提交的命令请求不会插入到事务执行命令序列中。

事务执行三阶段:

  1. 开启:以 MULTI 开始一个事务

  2. 入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面

  3. 执行:由 EXEC 命令触发事务

1、事务相关命令

命令 描述
MULTI 开启事务,redis会将后续的命令逐个放入队列中,然后使用EXEC命令来原子化执行这个命令系列
EXEC 执行事务中的所有操作命令
DISCARD 取消事务,放弃执行事务块中的所有命令
WATCH 监视一个或多个key,如果事务在执行前,这个key(或多个key)被其他命令修改,则事务被中断,不会执行事务中的任何命令
UNWATCH 取消WATCH对所有key的监视

2、相关操作

# 标准事务执行
127.0.0.1:6379> MULTI # 开启事务
OK
127.0.0.1:6379> set k1 hello # 命令入队
QUEUED
127.0.0.1:6379> set k2 redis # 命令入队
QUEUED
127.0.0.1:6379> EXEC # 执行事务
1) OK
2) OK
127.0.0.1:6379> get k1 # 验证是否执行
"hello"
127.0.0.1:6379> get k2
"redis"

# 事务取消
127.0.0.1:6379> MULTI # 开始事务
OK
127.0.0.1:6379> set k3 test1
QUEUED
127.0.0.1:6379> set k4 test2
QUEUED
127.0.0.1:6379> DISCARD # 取消事务
OK
127.0.0.1:6379> EXEC # 因为事务被取消了,所以执行报错
(error) ERR EXEC without MULTI

# 事务出现从错误处理
# 1、语法错误(编译器错误)
# 语法错误会使得事务提交失败,数据恢复原样
127.0.0.1:6379> MULTI # 开启事务
OK
127.0.0.1:6379> set k1 11
QUEUED
127.0.0.1:6379> set k2 22
QUEUED
127.0.0.1:6379> error k3 33 # 执行一条错误的命令
(error) ERR unknown command `error`, with args beginning with: `k3`, `33`, 
127.0.0.1:6379> exec # 执行事务,报错,命令皆未执行
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get k1 # 验证是否执行
"hello" # 值未变
127.0.0.1:6379> get k2
"redis"

# 2、类型错误(运行时错误)
# 触发运行时错误时,事务将会跳过错误的命令继续执行,其他正常的命令可以被执行成功
# 此处可以说明:Redis单条指令保证原子性,但是Redis事务不能保证原子性
127.0.0.1:6379> MULTI # 开启事务
OK
127.0.0.1:6379> set k1 11
QUEUED
127.0.0.1:6379> INCR k2 # 类型错误,对string类型进行自增操作
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> EXEC # 执行事务,可以发现虽然第二条命令报错了,但是其他的命令正常执行了
1) OK
2) (error) ERR value is not an integer or out of range
3) "redis"
127.0.0.1:6379> get k1 # 获取k1的值为事务中修改后的值
"11"

3、监控

3.1、乐观锁和悲观锁

悲观锁(Pessimistic Lock)

  • 很悲观,认为什么时候都会出现问题,无论做什么都会加锁
  • 传统的关系型数据库里边就用到了很多这种锁机制,比如行锁、表锁,读锁,写锁等,都是在操作之前先上锁
  • 在Java中,synchronized的思想也是悲观锁

乐观锁(Optimistic Lock)

  • 很乐观,认为什么时候都不会出现问题,做什么都不加锁。只有在更新数据的时候去判断一下该数据在此期间是否有过变更
  • 乐观锁适用于多读的应用类型,这样可以提高吞吐量
  • 乐观锁策略:提交版本必须大于记录当前版本才能执行更新

乐观锁一般会使用版本号机制或CAS操作实现

一般会使用版本号机制或CAS操作实现:

  1. version方式:一般是在数据表中加上一个数据版本号version字段,表示数据被修改的次数,当数据被修改时,version值会加一。当线程A要更新数据值时,在读取数据的同时也会读取version值,在提交更新时,若刚才读取到的version值为当前数据库中的version值相等时才更新,否则重试更新操作,直到更新成功。

    核心SQL代码:

    update table set x=x+1, version=version+1 where id=#{id} and version=#{version};

  2. CAS(Check And Set【先检查再动手设置】)

    CAS操作方式:即 compare and set,CAS是乐观锁技术,涉及到三个操作数,数据所在的内存值,预期值,新值。当需要更新时,判断当前内存值与之前取到的值是否相等,若相等,则用新值更新,若失败则重试,一般情况下是一个自旋操作,即不断的重试。

3.2、Watch监控

使用watch key监控指定数据,相当于乐观锁加锁,其执行流程如下

Redis篇之Redis事务_第1张图片
上图源自:http://c.biancheng.net/view/4544.html

# 正常执行
127.0.0.1:6379> set money 100 # 设置初始金额
OK
127.0.0.1:6379> set use 0 # 设置已消费金额
OK
127.0.0.1:6379> WATCH money # 监控money,相当于给money上锁
OK
127.0.0.1:6379> MULTI # 开启事务
OK
127.0.0.1:6379> DECRBY money 20 # 消费20,初始金额-20
QUEUED
127.0.0.1:6379> INCRBY use 20 # 消费金额+20
QUEUED
127.0.0.1:6379> EXEC # 执行事务,正常无报错
1) (integer) 80
2) (integer) 20

# 模拟多线程修改值
# 开启两个Xshell客户端连接同一个redis
# 在第一个客户端1开始操作
127.0.0.1:6379> WATCH money
OK
127.0.0.1:6379> MULTI
OK
127.0.0.1:6379> DECRBY money 20
QUEUED
127.0.0.1:6379> INCRBY use 20
QUEUED
127.0.0.1:6379> # 执行到此处,停止操作,模拟另一个线程修改数据,切换到另一个客户端2

127.0.0.1:6379> INCRBY money 500 # 操作money,改变其值+500
(integer) 580
127.0.0.1:6379> # 无需再操作,切回客户端1执行事务

127.0.0.1:6379> EXEC # 发现事务执行返回空,即所有命令都未执行
(nil)
127.0.0.1:6379> get money # 查询money,发现和客户端2增加后的值一致,说明客户端1后来的事务并未执行
"580"
127.0.0.1:6379> get use # 同理
"20"

UNWATCH命令用于解除WATCH的监控,但是需要注意的是:每次提交执行EXEC后都会自动释放锁,不管是否成功,所以UNWATCH无需在EXEC后执行

你可能感兴趣的:(数据库相关笔记,redis,数据库,缓存)