互联网常识:详细了解Redis中的事务( 二 )

EXEC返回一个数组其中每个元素都是事务中单个命令的返回结果而且顺序与命令的发出顺序相同 。当Redis连接处于MULTI请求的上下文中时所有命令将以字符串QUEUED(从Redis协议的角度作为状态回复发送)作为回复并在命令队列中排队 。只有EXEC被调用时排队的命令才会被执行此时才会有真正的返回结果
事务中的错误 事务期间可能会遇到两种命令错误:
在调用 EXEC命令之前出现错误( COMMAND排队失败) 。例如命令可能存在 语法错误(参数数量错误错误的命令名称...);或者可能存在 某些关键条件如内存不足的情况(如果服务器使用 maxmemory指令做了 内存限制) 。 。通过检查排队命令的状态回复(***注意:这里是指排队状态回复而不是执行结果***)如果命令使用QUEUED进行响应则它已正确排队否则Redis将返回错误 。如果排队命令时发生错误大多数客户端将中止该事务并清除命令队列 。然而:
Redis 2.6.5之前这种情况下在 EXEC命令调用后客户端会执行命令的子集(成功排队的命令)而忽略之前的错误 。从 Redis 2.6.5开始服务端会记住在累积命令期间发生的错误当 EXEC命令调用时 将拒绝执行事务并返回这些错误同时自动清除命令队列 。示例如下: >MULTI+OK>INCR a b c-ERR wrong number of arguments for 'incr' command

这是由于INCR命令的语法错误将在调用EXEC之前被检测出来并终止事务(version2.6.5+) 。
在调用 EXEC命令之后出现错误 。例如使用 错误的值对某个 key执行操作(如针对 String值调用 List操作) :即使事务中的某些命令执行失败其他命令仍会被正常执行
示例如下: >MULTI+OK>SET a 3+QUEUED>LPOP a+QUEUED>EXEC*2+OK-ERR Operation against a key holding the wrong kind of value
EXEC返回一个包含两个元素的字符串数组一个元素是OK另一个是-ERR…… 。能否将错误合理的反馈给用户这取决于客户端library(如:Spring-data-redis.redisTemplate)的自身实现 。需要注意的是即使命令失败队列中的所有其他命令也会被处理----Redis不会停止命令的处理 。
Redis事务不支持Rollback( 重点) 事实上Redis命令在事务执行时可能会失败但仍会继续执行剩余命令而不是Rollback(事务回滚) 。如果你使用过关系数据库这种情况可能会让你感到很奇怪 。然而针对这种情况具备很好的解释:
Redis命令可能会执行失败仅仅是由于错误的语法被调用(命令排队时检测不出来的错误)或者使用错误的数据类型操作某个 Key: 这意味着实际上失败的命令都是编程错误造成的都是开发中能够被检测出来的生产环境中不应该存在 。(这番话彻底甩锅“都是你们自己编程错误与我们无关” 。)由于不必支持 Rollback, Redis内部简洁并且更加高效 。“如果错误就是发生了呢”这是一个反对Redis观点的争论 。然而应该指出的是通常情况下回滚并不能挽救编程错误 。鉴于没有人能够挽救程序员的错误并且Redis命令失败所需的错误类型不太可能进入生产环境所以我们选择了不支持错误回滚(Rollback)这种更简单快捷的方法 。


以上关于本文的内容,仅作参考!温馨提示:如遇健康、疾病相关的问题,请您及时就医或请专业人士给予相关指导!

「四川龙网」www.sichuanlong.com小编还为您精选了以下内容,希望对您有所帮助: