经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 数据库/运维 » Redis » 查看文章
Redis事务控制
来源:cnblogs  作者:秃桔子  时间:2019/9/19 9:07:36  对本文有异议

Redis事务控制

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

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

我们先测试一下

  1. MULTI
  2. SET number 100
  3. INCR number
  4. EXEC

执行效果如下所示:

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

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

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

  1. MULTI
  2. SET number 1000
  3. incr number
  4. incr number
  5. incriby number aaa
  6. exec

运行结果如下

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

对于此官方解释了:

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

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

2、Redis乐观锁的体现

我们先来执行以下代码

  1. set num 100
  2. get num
  3. watch num
  4. MULTI
  5. incr num
  6. incr num
  7. get num

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

然后在刚才的界面执行EXEC

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

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

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

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

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

原文链接:http://www.cnblogs.com/godoforange/p/11546203.html

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号