Redis事务控制

Redis事务控制

1、Redis事务控制的相关命令汇总

命令名 作用
MULTI 表示开始收集命令,后面所有命令都不是马上执行,而是加入到一个队列中。
EXEC 执行MULTI后面命令队列中的所有命令。
DISCARD 放弃执行队列中的命令。
WATCH “观察”、“监控”一个KEY,在当前队列外的其他命令操作这个KEY时,放弃执行自己队列的命令
UNWATCH 放弃监控一个KEY

我们先测试一下

MULTI
SET number 100
INCR number
EXEC

执行效果如下所示:

当我们执行中间出错时,整个事务都会失败而且回滚。

这里如果我们之前学过数据库的话,应该觉得很正常

但是当我们执行以下命令时

MULTI
SET number 1000
incr number
incr number
incriby number aaa
exec

运行结果如下

我们会发现整个事务并没有回滚

对于此官方解释了:

如果你有使用关系式数据库的经验, 那么 “Redis 在事务失败时不进行回滚,而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。以下是这种做法的优点:
Redis 命令只会因为错误的语法而失败(并且这些问题不能在入队时发现),或是命令用在了错误类型的键上面:这也就是说,从实用性的角度来说,失败的命令是由编程错误造成的,而这些错误应该在开发的过程中被发现,而不应该出现在生产环境中。
因为不需要对回滚进行支持,所以 Redis 的内部可以保持简单且快速。
有种观点认为 Redis 处理事务的做法会产生 bug , 然而需要注意的是, 在通常情况下, 回滚并不能解决编程错误带来的问题。 举个例子, 如果你本来想通过 INCR 命令将键的值加上 1 , 却不小心加上了 2 , 又或者对错误类型的键执行了 INCR , 回滚是没有办法处理这些情况的。

因我我们需要加强对生产环境中的错误异常处理

2、Redis乐观锁的体现

我们先来执行以下代码

set num 100
get num
watch num
MULTI
incr num
incr num
get num

然后我们新开一个客户端,设置了一下num的值

然后在刚才的界面执行EXEC

这时候我们会发现命令执行失败了,整个事务回滚了。

这就是一个乐观锁的体现,
简而言之就是、如果别人在我的队列命令执行之前,修改了我的数据,那我就直接放弃了。

乐观锁和悲观锁需要依据具体的实现进行使用

  • 悲观锁(数据库中的行锁和表锁)
    • 认为当前环境非常容易发生碰撞,所以执行操作前需要把数据锁定,操作完成后释放锁其他操作才能继续进行操作。
  • 乐观锁
    • 认为当前环境不容易发生碰撞,所以执行操作前不锁定数据,万一碰撞真的发生了,那么放弃自己的操作

Redis 内只有乐观锁,并无悲观锁,因为Redis对性能的要求很高。

posted @ 2019-09-18 23:00 秃桔子 阅读(...) 评论(...) 编辑 收藏