互联网常识：详细了解Redis中的事务

导读跟大家讲解下有关详细了解Redis中的事务，相信小伙伴们对这个话题应该也很关注吧，现在就为小伙伴们说说详细了解Redis中的事务，小编也

跟大家讲解下有关详细了解Redis中的事务，相信小伙伴们对这个话题应该也很关注吧，现在就为小伙伴们说说详细了解Redis中的事务，小编也收集到了有关详细了解Redis中的事务的相关资料，希望大家看到了会喜欢。

本篇文章带大家详细了解一下Redis中的事务。有一定的参考价值有需要的朋友可以参考一下希望对大家有所帮助。

【相关推荐：Redis视频教程】

相关命令命令格式作用返回结果WATCHWATCH key [key …]将给出的
Keys标记为
监测态作为事务执行的条件always OK.UNWATCHUNWATCH清除事务中
Keys的
监测态如果调用了EXEC or DISCARD则没有必要再手动调用UNWATCHalways OK.MULTIMULTI
显式开启
redis事务后续
commands将排队等候使用EXEC进行原子执行always OK.EXECEXEC执行事务中的
commands队列恢复连接状态。如果WATCH在之前被调用只有
监测中的
Keys没有被修改命令才会被执行否则停止执行（详见下文
CAS机制）成功： 返回数组 —— 每个元素对应着原子事务中一个
command的返回结果;失败： 返回
NULL（
Ruby小苏打的作用与功效返回
`nil`）;DISCARDDISCARD清除事务中的
commands队列恢复连接状态。如果WATCH在之前被调用
释放
监测中的
Keysalways OK.

注意：

——MULTI,EXEC,DISCARD才是显式开启并控制事务的常用命令可类比关系型数据库中的BEGAIN,COMMIT,ROLLBACK（事实上差距很大）；

——WATCH命令的使用是为了解决事务并发产生的不可重复读和幻读的问题（简单理解为给Key加锁）；

Redis事务

MULTI, EXEC, DISCARD and WATCH 是Redis事务的基础。用来显式开启并控制一个事务它们允许在一个步骤中执行一组命令。并提供两个重要的保证：

事务中的所有命令都会被序列化并按顺序执行。在执行Redis事务的过程中不会出现由另一个客户端发出的请求。这保证
命令队列作为一个单独的原子操作被执行。队列中的命令要么全部被处理要么全部被忽略。EXEC命令触发事务中所有命令的执行因此当客户端在事务上下文中失去与服务器的连接如果发生在调用MULTI命令之前则不执行任何
commands；如果在此之前EXEC命令被调用则所有的
commands都被执行。

同时redis使用AOF(append-only file)使用一个额外的write操作将事务写入磁盘。如果发生宕机进程奔溃等情况可以使用redis-check-aof tool 修复append-only file使服务正常启动并恢复部分操作。

用法

使用MULTI命令显式开启Redis事务。 该命四边形的定义令总是以OK回应。此时用户可以发出多个命令Redis不会执行这些命令而是将它们排队。EXEC被调用后所有的命令都会被执行。而调用DISCARD可以清除事务中的commands队列并退出事务。

以下示例以原子方式递增键铁路最好的5个专业foo和bar。

>MULTIOK>INCR fooQUEUED>INCR barQUEUED>EXEC1）（整数）12）（整数）1

从上面的命令执行中可以看出EXEC返回一个数组其中每个元素都是事务中单个命令的返回结果而且顺序与命令的发出顺序相同。当Redis连接处于MULTI请求的上下文中时所有命令将以字符串QUEUED（从Redis协议的角度作为状态回复发送）作为回复并在命令队列中排队。只有EXEC被调用时排队的命令才会被执行此时才会有真正的返回结果。

事务中的错误

事务期间可能会遇到两种命令错误：

在调用
EXEC命令之前出现错误（
COMMAND排队失败）。例如命令可能存在
语法错误（参数数量错误错误的命令名称…）；或者可能存在
某些关键条件如内存不足的情况（如果服务器使用
maxmemory指令做了
内存限制）。

客户端会在EXEC调用之前检测第一种错误。 通过检查排队命令的状态回复（***注意：这里是指排队的状态回复而不是执行结果***）如果命令使用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操作）

EXEC命令执行之后发生的错误并不会被特殊对待：即使事务中的某些命令执行失败其他命令仍会被正常执行。

示例如下：

>MULTI+OK>SET a 3+QUEUED>LPOP a+QUEUED>EXEC*2+OK-ERR Operation against a ke《寻隐者不遇》y 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）这种更简单快捷的方法。

清除命令队列

DISCARD被用来中止事务。事务中的所有命令将不会被执行,连接将恢复正常状态。

> SET foo 1OK> MULTIOK> INCR fooQUEUED> DISCARDOK> GET foo"1"

更多编程相关知识请访问：编程视频！！

以上就是详细了解Redis中的事务的详细内容！

来源：php中文网