亲宝软件园·资讯

展开

Redis事务

昂迪梵德 人气:0
# Redis事务 ### Redis 事务简介 Redis 事务的基本功能由 MULTI、EXEC、DISCARD 及 WATCH 等命令实现。其中, ● **MULTI** 命令用于启动 Redis 的事务,将客户端置为事务状态。 ● **EXEC** 命令用于提交事务,执行从 MULTI 到此命令前面的命令队列,此时客户端变为非事务状态。 ● **DISCARD** 命令用于取消事务,命令执行后,将会清空事务队列中的所有命令,并且客户端从事务状态中退出。你可以把它理解为事务回滚,但是 Redis 数据库并不具有事务回滚机制。 ● **WATCH** 命令用于监视键值对,它使得 EXEC 命令需要有条件地执行,在所有被监视键都没有被修改的前提下,事务才能正常被执行。如果这个被监视的键值对发生了改变,那么事务就不会被执行。 Redis事务本质是一组命令的集合,Redis服务器先序列化这一组命令,然后一次性、按顺序、排他性地串行(逐个)执行这一组命令,并且不会在执行事务的途中去执行其他客户端命令。 Redis事务只能保证一个客户端请求的事务中的命令可以连续地被执行 当服务器接收到客户端发送过来的命令是 MULTI、EXEC、WATCH、DISCARD 4 个命令中的任意一个时,服务器会立即执行这个命令。 相反,当服务器接收到客户端发送过来的命令是 MULTI、EXEC、WATCH、DISCARD 4 个命令以外的其他命令时,服务器不会立即执行这个命令,而是将该命令放入一个事务队列中,然后返回 QUEUED 标识给客户端。 ![file](https://img2020.cnblogs.com/other/1973632/202004/1973632-20200401085601861-103216564.jpg) 每个 Redis 客户端都有自己的事务状态,而 mstate 属性就保存了这个客户端的事务状态。事务状态由一个事务队列和一个入队命令的计数器组成。其中,事务队列是一个 multiCmd 类型的结构体数组,它采用先进先出(FIFO)的方式保存入队的命令,先入队的命令将会被放到数组的前面,先执行;而后入队的命令则被放到数组的后面,后执行。这个数组中的每个 multiCmd 结构都保存了一个入队命令的信息,具体包括指向命令实现函数的指针、命令的参数及参数数量等。 ### ACID 特性 **原子性**:当客户端使用 MULTI 命令成功开启一个事务上下文,执行 EXEC 命令,中间入队列的多个命令要不全部执行成功,要不全部失败。 当客户端处于事务开启状态时,每进入一条命令,都会返回一个内容为 QUEUED 的结果回复 在执行 EXEC 命令后,将会以数组的方式返回执行的结果,数组中的每个元素都是事务中的命令执行结果。结果的输出顺序与开启事务后命令进入队列的先后顺序一致。 然而 Redis 数据库并不支持事务回滚。向Redis事务队列中插入命令,如果遇到命令格式错误,入队失败,则会导致整个事务执行失败。如果遇到事务中某个命令的语法格式正确,但在执行时因为类型或者键不存在而报错,那么它的整个事务也会继续执行下去,而不是终止执行,直到这个事务的所有命令执行完毕为止。 **一致性**:事务的一致性说的是,数据库在执行事务之前是一致的,在执行事务之后,不管事务是执行成功还是执行失败,数据库中的数据也应该具有一致性。 当存在错误命令,或者命令格式错误。服务器会拒绝执行入队过程中出现错误的事务,导致了事务执行失败,从而保证了数据库的一致性。 当命令入队成功,但在执行过程中发生了错误。如 INCRBY username 8 命令,那么执行错误的命令会被服务器检测出来,并做相应的错误处理,所以这些执行错误的命令并不会影响其他命令的执行,也不会修改数据库,对事务的一致性并不会产生影响。 当发生突发情况(如断电、服务器停机、服务器崩溃等),导致事务执行出错。此时常常会根据服务器所使用的持久化方式来保证数据库的一致性,具体如下。 ➢ 服务器没有开启持久化,在服务器重启时,数据库中将没有任何数据,此时可以保证数据库的一致性。 ➢ 服务器开启了 RDB 或 AOF 持久化,在执行事务的过程中,发生故障,不会引起数据库的不一致性。RDB 或 AOF 文件中保存了数据库数据,可以根据 RDB 或 AOF 文件来将数据还原到事务执行之前的状态。如果开启了 RDB 或 AOF 持久化方式,但是找不到 RDB 或 AOF 文件,那么在服务器重启后,数据库会是空白的,也能保证数据库的一致性。 **隔离性**:Redis 数据库是采用单进程单线程模型实现的键值对存储数据库,它在执行事务命令及其他相关命令时,采用的就是单线程方式。在执行事务的过程中,服务器可以保证这个事务不会被中断,所以 Redis 事务总是以串行方式实现的,在上一个事务没有执行完之前,其他命令是不会被执行的,这就是 Redis 事务的隔离性。 **持久性**:Redis 数据库是采用单进程单线程模型实现的键值对存储数据库,它在执行事务命令及其他相关命令时,采用的就是单线程方式。在执行事务的过程中,服务器可以保证这个事务不会被中断,所以 Redis 事务总是以串行方式实现的,在上一个事务没有执行完之前,其他命令是不会被执行的,这就是 Redis 事务的隔离性。 ●如果 Redis 服务器没有采用任何持久化方式,那么事务不具有持久性。假如服务器发生故障(如停机、断电、崩溃),将会丢失服务器上包括事务数据在内的所有数据。 ● 如果 Redis 服务器使用了 AOF 持久化方式: ➢ 当 Redis 配置文件(redis.conf)中的 appendfsync 属性的值为 always 时,可以保证 Redis 事务具有持久性。每当服务器执行完相关命令后,包括事务命令在内,程序都会调用执行 sync 同步函数,将命令数据及时保存到系统硬盘中,这就保证了事务的持久性。 ➢ 当 Redis 配置文件中的 appendfsync 属性的值为 everysec 时,服务器程序会每隔 1 秒执行一次数据同步操作,并将数据保存到硬盘中。如果服务器发生停机故障,可能刚好发生在数据等待同步的那 1 秒之内,就会导致数据丢失,因此无法保证事务的持久性。 ➢ 当 Redis 配置文件中的 appendfsync 属性的值为 no 时,服务器命令数据同步保存到硬盘中的操作将由操作系统来控制,因此,事务数据在同步的过程中,可能会因为一些原因而丢失,这种情况也不能保证事务的持久性。后面的章节将会详细介绍 Redis 的持久化。 ● 如果 Redis 服务器使用了 RDB 持久化方式,那么,只有在特定的保存条件被满足时,服务器才会执行 BGSAVE 命令,实现数据的保存。而如果是异步执行 BGSAVE 命令,那么服务器并不能保证在第一时间将事务数据保存到硬盘中,因此也就不能保证事务的持久性。换句话说,RDB 持久化方式不能保证事务具有持久性。 #### 悲观锁和乐观锁 **悲观锁**:每次去数据库中取数据的时候都会认为别人会修改这些数据,所以它每次取数据的时候都会给这些数据加锁,不让别人使用,别人想拿这些数据就会阻塞直到它释放锁、别人获得锁为止。在传统的关系型数据库中,使用了大量的悲观锁,如行锁、表锁、读锁、写锁等 **乐观锁**:每次去数据库中取数据的时候,都认为别人不会修改这些数据,所以它不会给这些数据加锁。但是它也很细心,每次在更新这些数据的时候,都会判断一下在此期间有没有别人更新过这些数据。如果别人更新过这些数据,它就会放弃本次更新;相反,如果别人没有更新过这些数据,它就会更新这些数据。乐观锁比较适用于多读的应用类型,可以提高吞吐量。(下文中WATCH 命令就是一个乐观锁) #### 事务的 WATCH 命令 事务的 WATCH 命令用于监视事务中的命令。有了 WATCH 命令的监视,就会使得 EXEC 命令需要有条件地执行,只有在所有被 WATCH 命令监视的数据库键都没有被修改的前提下,这个事务才能执行成功。如果所有被监视的数据库键中有任意一个数据库键被修改,那么这个事务都会执行失败。 使用 UNWATCH 命令取消 WATCH 命令对数据库键的监视 使用方法: ``` WATCH name age#WATCH 命令同时监视 name 键和 age 键 MULTI#开启事务上下文 ... ```

加载全部内容

相关教程
猜你喜欢
用户评论