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对性能的要求很高。
微信搜索桔子科研或者扫描二维码,第一时间获取编程有趣的知识和最新科研学术成果。
![](https://images.cnblogs.com/cnblogs_com/godoforange/1390071/o_211204035711_qrcode_for_gh_7f100002de19_344.jpg)