事务

在关系型数据库中，事务对应着最熟悉的ACID原则，但在非关系型数据库redis中，事务的规则有所不同:

  • redis单条命令是保存原子性的，但事务不保证原子性！
  • redis事务没有隔离界别的概念
  • 在入队的时候，事务中的命令并没有执行，只有在执行了执行命令的情况下，才会开始顺序执行

Redis事务本质：一组命令的集合！一个事务中的所有命令都会被序列化，然后按照顺序执行。

一次性、顺序性、排他性！

redis的事务步骤：

  1. 开启事务（multi）
  2. 命令入队（其他命令）
  3. 执行事务（exec）

事务的执行

正常执行

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 k3 v3
QUEUED
127.0.0.1:6379> get k3
QUEUED
127.0.0.1:6379> get k2
QUEUED
127.0.0.1:6379> exec		#执行事务
1) OK
2) OK
3) OK
4) "v3"
5) "v2"

放弃事务

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> discard			#放弃事务
OK
127.0.0.1:6379> exec
(error) ERR EXEC without MULTI
127.0.0.1:6379> get k2
(nil)

编译型异常

代码有问题，命令出错，事务中的命令都不会执行

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> getset k3		#错误命令
(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 k2
(nil)

运行时异常

如1/0这样的语法错误，那么出语法错误的命令不会被执行，而其他命令可以被执行，错误命令抛出异常

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"

监控（面试高频）

悲观锁

  • 很悲观，认为什么时候都会出现问题，无论做什么都会加锁

乐观锁

  • 很乐观，认为什么时候都不会出现问题，所以不会上锁！更新数据的时候去判断一下，在此期间是否有人修改过这个数据
  • 获取version
  • 更新的时候比较version，如果二者不一致，就会提交事务失败

Redis监视测试

redis事务默认使用watch乐观锁

正常执行

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
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

错误执行

比如在事务执行前，加锁key的值发生了改变，那么事务提交会失败

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
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> decrby money 10
QUEUED
127.0.0.1:6379> incrby out 10
QUEUED
127.0.0.1:6379> exec		#提交事务前，money被另外一个线程改变了，所以事务提交失败
(nil)
#模拟另一个线程改变上锁的key
127.0.0.1:6379> keys *
1) "out"
2) "money"
127.0.0.1:6379> set money 200
OK

当然，我们可以使用unwatch释放所有的锁

所以，当我们事务提交失败的时候，一般先unwatch，再给监控的key加锁