前言

---

 相关系列

• 《Redis & 目录》（持续更新）
• 《Redis & 事务 & 源码》（学习过程/多有漏误/仅作参考/不再更新）
• 《Redis & 事务 & 总结》（学习总结/最新最准/持续更新）
• 《Redis & 事务 & 问题》（学习解答/持续更新）
   

 参考文献

• 《Redis事务详解》
   
   

概述

---

    Redis事务并不严格具备ACID属性。在我们对数据库的常规理解中，事务必然会严格遵守原子性/一致性/隔离性/持久性。但由于Redis基于内存设计/实现的原因，其对事务ACID属性的实现并不存在/彻底。因此与其称之为事务，将之称为批处理其实更加贴切…该知识点会在下文讲解ACID时详述。

    Redis事务的意义是为了防止插队。Redis事务中的指令会被打包一次执行，因此可以避免多客户端指令交互执行的情况发生。
 
 

使用

---

 开启/执行/取消

    事务的开启/执行/取消指令具体如下：

• MULTI：开启事务；
• EXEC：执行事务；

// ---- 设置一个键/值为num/1的键值对。
> SET num 1
OK
// ---- 开启事务，并依次递增/递减/递增。每个指令输入后都会返回QUEUED，意味着指令已被成功加入
// 事务队列中，等待最终被执行。
> MULTI
OK
> INCR num
QUEUED
> DECR num
QUEUED
> INCR num
QUEUED
// ---- 执行事务，并返回每条指令的执行结果。
> EXEC
2
1
2

• DISCARD：在执行前取消事务。

> SET num 1
OK
// ---- 开启事务，并添加递增/递减/递增指令。
> MULTI
OK
> INCR num
QUEUED
> DECR num
QUEUED
> INCR num
QUEUED
// ---- 取消事务。
> DISCARD
OK
// ---- 取消事务后再执行会抛出错误。
> EXEC
(error) ERR EXEC without MULTI

 

 阶段

    Redis事务分为组队/执行两个阶段。组队阶段是Redis事务的第一阶段，由指令“MULTI”在开启事务时同步开启。在组队阶段中Redis会创建相应的事务队列用于顺序接收客户端发送的各项指令，因此事务中的指令其实是多次发送的。而由于Redis不可能在客户端发送全部指令/发送“EXEC”指令/发送“DISCARD”前无限等待，因为整个事务指令发送过程的时长并不可控，因此Redis实际上可以并发接受多个客户端指令。这种并发接收可能是单线程在多客户端之间相互切换实现的，也可能真的有多个线程在各自为政，这具体与Redis的版本有关。随着Redis的不断发展，早期（6.0之前）版本的“单线程实现”描述其实已经不太准确了，就比如现今绝大多数版本的Redis都会启用额外线程来实现数据持久化。但一直以来始终不变的是指令必然只会由唯一的主线程执行，因此在该设计被破坏前，无论Redis如何引入多线程，其都可以被称为单线程实现。

    Redis事务可能无法进入执行阶段。执行阶段顾名思义，即是将已完成组队的事务指令整体交由主线程依次执行。而由于执行阶段会由“EXEC”负责开启，因此如果客户端事先发送了“DISCARD”指令，那么事务/事务队列就会直接结束/丢弃而无法进入执行阶段。而除此之外如果客户端发送的指令出现语法错误，那事务也会因为原子性而直接结束…该知识点会在下文讲解原子性时详述。
 
 

实现

---

 原子性

    Redis事务具备“伪”原子性。原子性通俗的说法就是“要么一起成功，要么一起失败”，关于Redis事务的原子性一直是相当具有争议的点，原因就是其未曾“完全”遵循原子性的定义，即其允许在某些情况下部分成功。因此Redis具备原子性虽然属于官方说法，但仍有部分开发者坚持认为其并不具备原子性。而对于作者本人而言我认为Redis是具有原子性的，只是基于其功能定位而难以/无法实现的足够彻底而已，因此我将这种原子性称为“伪”原子性。

    Redis事务在组队阶段具备“真”原子性。对于在组队阶段的事务而言，如果客户端输入的指令在语法上存在错误，那么其整个事务/事务队列都会直接结束/丢弃。该行为符合原子性的标准定义，因此Redis事务在组队阶段具备“真”原子性…具体图示/案例如下：

> SET num 1
OK
> MULTI
OK
> INCR num
QUEUED
// ---- 错误指令，不同版本的Redis/图形客户端在此会有不同的表现，我这里显示排队成功，但有些版本会直接报错。
> INCR1 num
QUEUED
> INCR num
QUEUED
// ---- 执行时由于存在错误指令会抛出异常，整体不执行。
> EXEC
ReplyError: EXECABORT Transaction discarded because of previous errors.

    Redis事务在执行阶段具备“伪”原子性。对于在执行阶段的事务而言，即使其在过程中出现某指令执行异常的情况，Redis也只会记录该异常并继续执行后续指令，因此Redis事务并不具备数据回滚能力。该行为明显违背了原子性的标准定义，因此Redis事务在执行阶段只具备“伪”原子性…具体图示/案例如下：

> SET name aaa
OK
> MULTI
OK
> SET name bbb
QUEUED
// ---- 该指令没有语法错误，但字符串类型是无法递增的。
> INCR name
QUEUED
> SET name ccc
QUEUED
// ---- 执行后只有两个结果，因为第二条指令会执行失败。可能是因为Redis版本/图形客户端
// 的原因，我这里没有抛出异常。
> EXEC
OK
OK

 

 一致性/持久性

    Redis事务具备结构一致性，但不具备内容一致性。Redis并不像Mysql一样对数据存在为空/大小/长度/范围/唯一/外键等结构性约束，故而事务数据只要计算成功其结构就必然合理，因此Redis事务具备结构一致性。但与此同时Redis事务却不具备内容一致性，因为其“伪”原子性无法保证所有指令全都执行成功。例如Redis事务就无法保证账号A/B在收/支上的一致性，因为两者的指令都存在失败可能，而任意一方的失败都将导致收支上的不平衡，因为Redis事务不具备内容一致性。

    Redis事务不（直接）具备持久性。所谓持久性是指数据被永久保存的特性，Redis存在RDB/AOF两种持久化机制，在两者被打开至少一个的情况下，Redis可以将内存中的数据持久化至磁盘中永久保存，从而“尽可能”避免在宕机/关机/重启/断电时丢失数据。该知识点会在Redis持久化的专项文章中详述，此处我们只需知道的是：虽然Redis具备全局性的数据持久化能力，但遗憾的是该机制的运行与事务是完全独立的，即事务的执行并不会强制触发该机制以实现对事务数据的持久化。因此Redis事务是不具备持久性的，虽然全局性的持久化机制可以在一定程度上间接达成这个效果。
 

 隔离性/WATCH

    Redis事务具备“读已递交”级别的隔离性。所谓隔离性是指事务并发期间的相互影响程度，这种相互影响在数据库的标准定义中被从低到高的被分为四个级别，其具体名称/问题/效果如下所示。而Redis没有设计任何专项机制去提升事务的隔离性，因此Redis事务仅天然具有“读已递交”级别的隔离性。为什么不是“读未递交”级别的隔离性呢？这是因为Redis事务压根没有统一递交的说法…其指令的每次执行都可以直接视作数据的一次递交。

名称	问题	效果
读未递交	脏读/不可重复度/幻读	会读取到其它事务未递交的数据，并且即无法保证数据的内容不变化，也无法保证数据的数量不变化
读已递交	不可重复度/幻读	不会读取到其它事务未递交的数据，但即无法保证数据的内容不变化，也无法保证数据的数量不变化
可重复读	幻读	不会读取到其它事务未递交的数据，并且可以保证数据的内容不变化，但无法保证数据的数量不变化
序列化	/	事务串行执行，相互之间完全不影响

    Redis事务在执行阶段具备“序列化”等级的隔离级别。由于单线程实现的原因，Redis事务在执行阶段其实具备“序列化”等级的隔离级别。因为在此期间其它事务最多只能处于组队阶段而无法处于执行阶段，甚至在早期版本中都可能不存在其它事务，因此对于当前正在执行的事务来说是绝对不可能出现目标数据被并发修改的情况的。那为什么说Redis事务只具备“读已递交”级别的隔离性呢？这是因为如果反过来看正处于组队阶段的当前事务，那么其目标数据就完全可能被处于执行阶段的其它事务所并发修改，从而导致出现执行前提被破坏的“竞态条件”情况…具体示例时间表如下：

时间	事务1	事务2
T1	商品总量为5000，开启事务	商品总量为5000，开启事务
T2	组队指令 – 设置商品总量为4000（-1000）	组队指令 – 设置商品总量为3000（-2000）
T3	单线程执行指令 – 商品总量被设置为3000T4	单线程执行指令 – 商品总量被设置为4000但正确总量应该为2000

    Redis提供了乐观锁机制的{WTACH}指令用于监控事务的目标数据。上述问题的本质还是线程安全问题，其核心在于指令的执行依据被并发修改，因此只要能够控制这一点就能为事务的正确执行提供基础可能。对此Redis基于乐观锁机制提供了{WTACH}指令用于监控目标数据，其本质是记录目标数据的快照。而当事务进入执行阶段时其会将最新的目标数据与快照进行对比，并在发现目标数据已变化的情况下拒绝执行事务并返回null…具体示例如下：

• WATCH key [key …]：监控目标数据集，并在目标数据发生变化时拒绝执行事务。
      ------------------------- 入参 -------------------------
      key [key …] @ 键集：需监控目标数据集的键集，多个键之间使用" "分割。

// ---- 设置/监控目标数据，并开启事务。
> SET goal aaaa
OK
> WATCH goal
OK
> MULTI
OK
// ---- 更新目标数据。
> SET goal bbbb
QUEUED
// ---- 如果目标数据在事务组队期间被其它线程/事务修改，当前事务将不会执行并返回null。
> EXEC
null

 
 

管道

---

    管道可大幅提升多指令的执行效率。管道相当于将事务的组队阶段从服务端转移到了客户端执行，因此其不会像事务一样多次发送指令，而是会直接将已完成打包/组队的命令集一次性发送至服务端执行。而又因为Redis执行的高效性会使得指令/数据的RRT @ Round Trip Time @ 往返时间/网络传输时间远远多于指令的执行时间，因此多指令/数据的一次性发送/返回能够有效提升批量操作的执行效率，也因此管道被广泛用于数据大批量导入/导出的场景中。

    Redis管道无法通过原生指令开启…下文展示的是通过Jedis使用管道的模板：

public static void testPipeLineAndNormal(Jedis jedis) throws InterruptedException {
    // ---- 开启管道。
    Pipeline pipeline = jedis.pipelined();
    // ---- 在管道中添加多个SET指令。
    for (int i = 0; i < 10000; i++) {
        pipe.set(String.valueOf(i), String.valueOf(i));
    }
    // ---- 一次性发送/执行管道指令。
    pipe.sync();
}