一、结合关系型数据库的事务来看看Redis中事务有什么不同

Redis事务是指将多条命令加入队列，一次批量执行多条命令，每条命令会按顺序执行，事务执行过程中不会受客户端传入的命令请求影响。

总结说：Redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。

Redis事务和关系型数据库的事务不太一样，它不保证原子性，也没有隔离级别的概念。

Redis事务没有隔离级别的概念
1. 批量操作在发送 EXEC 命令前被放入队列缓存，并不会被实际执行，也就不存在事务内的查询要看到事务里的更新，事务外查询不能看到。
Redis不保证原子性
1. Redis中，单条命令是原子性执行的，但事务不保证原子性，且没有回滚。事务中任意命令执行失败，其余的命令仍会被执行。

一个事务从开始到执行会经历以下三个阶段：

第一阶段：开始事务
第二阶段：命令入队
第三阶段、执行事务。

Redis事务的相关命令如下：

MULTI：标识一个事务的开启，即开启事务；
EXEC：执行事务中的所有命令，即提交；
DISCARD：放弃事务；和回滚不一样，Redis事务不支持回滚。
WATCH：监视Key改变，用于实现乐观锁。如果监视的Key的值改变，事务最终会执行失败。
UNWATCH：放弃监视。

Redis事务和关系型数据库的事务不太一样，它不保证原子性，也没有隔离级别的概念。来，结合命令演示，实战说明一切：

没有隔离级别：

如上图所示，当事务开启时，事务期间的命令并没有执行，而是加入队列，只有执行EXEC命令时，事务中的命令才会按照顺序一一执行，从而事务间就不会导致数据脏读、不可重复读、幻读的问题，因此就没有隔离级别。

不保证原子性：

如上图所示，在通过EXEC执行事务时，其中命令执行失败不会影响到其他命令的执行，并没有保证同时成功和同时失败的原子操作，尽管这样，Redis事务中也没有提供回滚的支持，官方提供了两个理由：

大概的意思就是：

使用Redis命令语法错误，或是将命令运用在错误的数据类型键上(如对字符串进行加减乘除等)，从而导致业务数据有问题，这种情况认为是编程导致的错误，应该在开发过程中解决，避免在生产环境中发生；
由于不用支持回滚功能，Redis内部简单化，而且还比较快；

多数事务失败是由语法错误或者数据结构类型错误导致的，语法错误说明在命令入队前就进行检测的，而类型错误是在执行时检测的，Redis为提升性能而采用这种简单的事务，这是不同于关系型数据库的，特别要注意区分。Redis之所以保持这样简易的事务，完全是为了保证高并发下的核心问题——性能。

在事务命令入队过程中，发现相关命令逻辑使用错误，可以进行放弃该事务；如果使用错误的Redis命令，且没有放弃事务，最终也会导致事务整体执行失败，这也算是为原子性扳回一局，如下：

放弃事务：

命令语法错误导致事务执行失败：

事务失败处理：

语法错误（编译器错误），在开启事务后，修改k1值为11，k2值为22，但k2语法错误，最终导致事务提交失败，k1、k2保留原值。

node1:6379> flushdb
OK
node1:6379> keys *
(empty list or set)
node1:6379> set k1 v1
OK
node1:6379> set k2 v2
OK
node1:6379> multi
OK
node1:6379> set k1 11
QUEUED
node1:6379> sets k2 22
(error) ERR unknown command 'sets'
node1:6379> exec
(error) EXECABORT Transaction discarded because of previous errors.
node1:6379> get k1
"v1"
node1:6379> get k2
"v2"

Redis类型错误（运行时错误），在开启事务后，修改k1值为11，k2值为22，但将k2的类型作为List，在运行时检测类型错误，最终导致事务提交失败，此时事务并没有回滚，而是跳过错误命令继续执行，结果k1值改变、k2保留原值。

node1:6379> flushdb
OK
node1:6379> keys *
(empty list or set)
node1:6379> set k1 v1
OK
node1:6379> set k2 v2
OK
node1:6379> multi
OK
node1:6379> set k1 11
QUEUED
node1:6379> lpush k2 22
QUEUED
node1:6379> exec
1) OK
2) (error) WRONGTYPE Operation against a key holding the wrong kind of value
node1:6379> get k1
"11"
node1:6379> get k2
"v2"

使用WATCH实现乐观锁

说到乐观锁，就和悲观锁一起简单说说对其的理解：

乐观锁：就是非常乐观，做什么事都往好处想；对于数据库操作，就认为每次操作数据的时候都认为别的操作不会修改，所以不会加锁，而是通过一个类似于版本的字段来标识该数据是否修改过，在执行本次操作前先判断是否修改过，如果修改过就放弃本次操作重新再来。乐观锁适用于多读的应用类型，这样可以提高吞吐量;乐观锁策略:提交版本必须大于记录当前版本才能执行更新。

悲观锁：就是非常悲观，做什么事都觉得不好；对于数据库操作，每次操作数据数据都会认为别的操作会修改当前数据，所以都要对其进行加锁，类似于表锁和行锁。

WATCH通过监视指定Redis Key，如果没有改变，就执行成功，如果发现对应值发生改变，事务就会执行失败，如下图：

那会一直监视指定的Key吗？，答案当然是不会的，以下三种方式可以取消监视：

事务执行之后，不管是否执行成功还好是失败，都会取消对应的监视；
当监视的客户端断开连接时，也会取消监视；
可以手动UNWATCH取消所有Key的监视；

二、Redis事务优缺点

优点：

一次性按顺序执行多个Redis命令，不受其他客户端命令请求影响；
事务中的命令要么都执行(命令间执行失败互相不影响)，要么都不执行(比如中间有命令语法错误)；

缺点：

事务执行时，不能保证原子性；
命令入队每次都需要和服务器进行交互，增加带宽；

注意

当事务中命令语法使用错误时，最终会导致事务执行不成功，即事务内所有命令都不执行；
当事务中命令知识逻辑错误，就比如给字符串做加减乘除操作时，只能在执行过程中发现错误，这种事务执行中失败的命令不影响其他命令的执行。

Redis事务详解

一、结合关系型数据库的事务来看看Redis中事务有什么不同

二、Redis事务优缺点

相关推荐