九游登录方式

2020-04-19由程序员日记发表于数据库教程 浏览14次

目录

写在前面的话

之前在某个网站上看到一个问题:redis在什么情况下出现事务不会滚的情况,以此为由并结合redis官方文档整理这边笔记。不足之处,请指出,谢谢。

事务

redis支持事务,提供两条重要的保证: - 在同一个事务的命令都是序列化的和有序执行的。这保证这些命令执行像单个隔离操作。

  • 要么所有的命令都执行,要么都不执行。所以事务也是原子性的。exec命令执行事务中的所有命令,如果在调用exce命令前,客户端和服务端断开连接,那么没有一个命令执行,如果exce命令调用,所有的命令执行。当使用aof时,redis确保使用一个系统调用write(2)将事务写到磁盘。然而如果redis服务崩溃或者系统管理员强制杀死,就会有可能只有一部分操作被注册。redis在重启时会发现这种情况,并且错误退出。使用redis-check-aof工具修复aof文件,移除部分事务,因为服务可以重启。

事务内部错误

在事务期间可能会出现两种命令错误: - 命令可能失败排队,因此在exec调用之前,就会出现错误。如命令的语法错误(参数个数错误,命令名错误),或者其他灾难环境如oom。

  • 命令失败可能在exec调用之后,例如操作一个key使用错误的值(如调用list操作却调用string的命令)。

客户端知道第一种错误,在执行exec之前,通过检测返回值:如果是queued 表明正确的排队,否则返回失败信息。如果在期间出现异常,大多数客户端取消执行事务。

为什么redis不支持回滚

如果你了解数据库,就应该知道事务回滚,事实上redis命令在事务期间失败,仍然执行剩余的操作,而不是回滚,对于你来说,可能太古怪。 - redis命令只有调用错误语法才可能失败(在命令队列队列中可能发现不了),或者操作key使用错误的数据类型:这意味着实际这种命令会导致程序错误,并且这种错误应该在开发环境发现,而不是生产。

  • redis内部实现简单和快速的,因为它不需要支持事务回滚。

事务操作命令

multi //开启事务
exec // 执行事务
discard //取消事务块执行
watch
unwatch

事务执行事务回滚失败

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key1 value1
QUEUED //语法校验通过。
127.0.0.1:6379> set key2 value2
QUEUED
127.0.0.1:6379> incr key1
QUEUED
127.0.0.1:6379> exec
1) OK
2) OK
3) (error) ERR value is not an integer or out of range
127.0.0.1:6379> get key1
"value1"
127.0.0.1:6379> get key2
"value2"

事务执行完成,但是没有因为错误而失败,这种失败是Key对应的数据类型错误,属于开发阶段的错误,redis检测不出来这种错误,只有实际执行才能校测出问题。

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set key1 value1
QUEUED
127.0.0.1:6379> set key2 value2
QUEUED
127.0.0.1:6379> incre key1
(error) ERR unknown command `incre`, with args beginning with: `key1`, 
127.0.0.1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
127.0.0.1:6379> get key1
(nil)

这种错误属于语法错误,没有incre命令,redis能检测出这种错误,所以事务执行失败。

取消事务

127.0.0.1:6379> multi 
OK
127.0.0.1:6379> set key1 value1
QUEUED
127.0.0.1:6379> discard
OK
127.0.0.1:6379> get key1
(nil)
127.0.0.1:6379>