【Redis】事务和锁机制

一、事务的基本操作

1、redis中事务的概念不同于Mysql数据库中的事务
它是一个单独的隔离操作:事务中所有的命令都会序列化、按照顺序依次执行
事务在执行的过程中,不会被其他客户端发送的命令请求打断

Redis事务的主要作用:串联多个命令防止别的命令插队

2、基本命令Multi、Exec、discard

  • Multi:组队命令,将命令依次放入队列中,但是不会执行
  • Exec:执行,redis将之前命令队列中的命令依次执行
  • discard:放弃,可以在组队过程中使用discard放弃组队
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> get k1
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) "v1"
127.0.0.1:6379>
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> get k2
QUEUED
127.0.0.1:6379(TX)> discard
OK
127.0.0.1:6379>
127.0.0.1:6379> get k1
"v1"
127.0.0.1:6379> get k2
(nil)
127.0.0.1:6379>

3、事务的错误处理

  • 场景一:使用multi过程中,出现错误,执行时整个队列的命令都会被取消
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set k1 v1
QUEUED
127.0.0.1:6379(TX)> set k2 v2
QUEUED
127.0.0.1:6379(TX)> set k3
(error) ERR wrong number of arguments for 'set' command
127.0.0.1:6379(TX)>
127.0.0.1:6379(TX)> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379>
127.0.0.1:6379>
127.0.0.1:6379> get k1
(nil)
127.0.0.1:6379>
  • 场景二:命令组队过程中没有出错,但是使用exec执行的过程中出错,那么只有出错的命令不会被执行,其他的命令正常执行
127.0.0.1:6379>
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> set key1 value1
QUEUED
# 这里key1的value值不是数字,所以执行自增会报错
127.0.0.1:6379(TX)> incr key1
QUEUED
127.0.0.1:6379(TX)> set key2 value2
QUEUED
127.0.0.1:6379(TX)> exec
1) OK
2) (error) ERR value is not an integer or out of range
3) OK
127.0.0.1:6379>
127.0.0.1:6379> get key2
"value2"
127.0.0.1:6379>

二、事务冲突(悲观锁和乐观锁)

1、悲观锁
悲观锁在操作数据时比较悲观,认为别人会同时修改数据。 因此操作数据时直接把数据锁住,直到操作完成后才会释放锁,上锁期间其他人不能修改数据,从而使这个数据处于一个block的状态

例如Mysql中的行锁与表锁等

2、乐观锁
乐观锁在操作数据时认为别人不会同时修改数据,所以不会对数据进行上锁

但是在更新数据时,会去判断在此期间是否有人修改过此数据,如果有人修改那就放弃更新,可以将这个过程理解为check-and-set

乐观锁大多是基于数据版本( Version )记录机制实现

3、乐观锁演示
在执行事务之前,我们可以使用watch key [key..]命令对可能同时被两个客户端修改的数据做一个监视,如果事务执行之前,这个key的值被修改,那么事务将被打断

执行unwatch取消对所有key的监视

客户端A

127.0.0.1:6379>
127.0.0.1:6379> set price 100
OK
127.0.0.1:6379> watch price
OK
127.0.0.1:6379>
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)> incrby price 20
QUEUED
127.0.0.1:6379(TX)> exec
1) (integer) 120
127.0.0.1:6379>
127.0.0.1:6379> unwatch
OK
127.0.0.1:6379>

客户端B

127.0.0.1:6379> keys *
1) "price"
127.0.0.1:6379>
127.0.0.1:6379> watch price
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379(TX)>
127.0.0.1:6379(TX)> incrby price 10
QUEUED
127.0.0.1:6379(TX)> exec
(nil)
127.0.0.1:6379>

可以看到,客户端A对price这个key做了修改,所以客户端B在执行事务时,发现数据被修改了,无法成功执行

三、redis事务特性

1、单独的隔离操作

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

2、没有隔离级别的概念

  • 队列中的命令,在提交之前都不会实际被执行

3、不保证原子性

  • 事务执行过程中,如果有一条命令执行失败,其他命令仍然继续执行,不会回滚

如有错误,欢迎指正!!!

你可能感兴趣的:(Redis,redis,数据库,缓存,后端)