redis事务解析

Allen.Lii

已于 2023-09-15 14:52:17 修改

阅读量557

点赞数 1

分类专栏： java 文章标签： redis

于 2019-09-20 16:37:51 首次发布

本文链接：https://blog.csdn.net/qq_39513155/article/details/101059681

版权

java 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

最近在使用redis搭建分布式锁时了解了一下redis事务，在此记录一下

1.redis事务相关命令

MULTI：

MULTI命令用于开启redis事务,MULTI会把执行该命令的客户端从非事务态转变为事务态，并且这个命令的返回值永远是OK。

EXEC：

EXEC命令用于执行事务中所有先前排队的命令，并将连接状态恢复为正常。服务端会顺序执行事务中的命令，并且把所有的命令的结果放在数组中返回给客户端，数组中的每个元素都是对原子事务中每个命令的回复。

WATCH：

WATCH命令主要用于实现乐观锁即CAS(我后面会写一篇介绍CAS算法的文章)，被WATCH的key的值如果在事务执行时如果被其他客户端修改了的话，服务端会直接拒绝事务执行，并返回代表失败的空恢复(nil)，即EXEC命令会返回null空值。

DISCARD：

DISCARD命令用于放弃事务，如果服务端在接收到DISCARD命令后收到客户端的EXEC命令也不会执行事务。此命令返回值永远是OK

UNWATCH

UNWATCH命令会刷新之前的事务的所有WATCH KEY的操作，如果调用EXEC或者DISCARD，则不需要手动调用UNWATCH。此命令返回值永远是OK

2.redis事务的执行过程

（1).开启事务

通过MULTI命令开始事务，MULTI命令把执行该命令的客户端从非事务状态改变为事务状态。

(2).命令入队

开启事务后，客户端给服务端发送的命令并不会立刻执行，服务端会将这些命令放入一个事务的队列，并同时返回给客户端QUEUED

(3).事务执行

客户端给服务端发送EXEC命令后，服务端事务队列中的任务将会顺序执行，并返回一个数组，数组中的元素是每个命令执行的结果。

127.0.0.1:6379> MULTI // 开始一个事务
OK
127.0.0.1:6379> SET key1 value1
QUEUED
127.0.0.1:6379> GET key1
QUEUED
127.0.0.1:6379> SADD set1 member1
QUEUED
127.0.0.1:6379> EXEC // 执行事务
1) OK
2) "value1"
3) (integer) 1

3.redis事务的特性

我们都知道数据库事务的特性ACID，那么redis满足ACID的特性吗?

A:原子性

数据库的原子性是指一个事务要么全部执行，要么不执行

redis事务是原子性的，事务队列中的命令要么全部成功，要么全部放弃。但是如果某个命令执行出错，是不会影响其他命令的执行的，这个在redis官方给出的解释中是认为只有在使用错误的语法或者使用了错误的数据类型的key时redis命令才会失败，并且命令在排队期间也没有检测到错误。另外也是因为redis官方觉得redis如果支持事务回滚的话会让redis变得很复杂。

C:一致性

数据库的一致性指事务的运行并不改变数据库中数据的一致性。

redis也支持一致性：

事务开启后，命令入队列时如果发生错误的话，不会返回给客户端QUEUED，客户端可以通过这种方法判断是否错误，从而调用DISCARD命令放弃事务。如果客户端此时仍然发送了EXEC命令的话，redis服务端也会拒绝执行，从而保证一致性。

在执行时如果某一个命令发生错误时，其他命令会正常执行，从而保证一致性。

服务器宕机时，由于redis的数据存放在内存中，此时内存中的数据会全部丢失，也保证了一致性

I:隔离性

数据库的隔离性是指两个以上的事务不会出现交错执行的状态。因为这样可能会导致数据不一致。

redis是单线程的，并且redis保证事务执行过程中不会被终端，所以redis也是支持隔离性的

D:持久性

数据库事务的持久性是指事务执行成功以后，该事务对数据库所作的更改便是持久的保存在数据库之中，不会无缘无故的回滚。

redis在无持久化的内存模式下是不支持持久性的，但是redis又提供两种持久化机制：AOF、RBD。RBD在满足特定条件下才会执行BGSAVE，所以也不具备持久性，而AOF模式下appendfsync为always时redis具有持久性。