参考/不再更新《Redis

Redis事务并不严格具备ACID属性。

在我们对数据库的常规理解中事务必然会严格遵守原子性/一致性/隔离性/持久性。

但由于Redis基于内存设计/实现的原因其对事务ACID属性的实现并不存在/彻底。

因此与其称之为事务将之称为批处理其实更加贴切…该知识点会在下文讲解ACID时详述。

Redis事务的意义是为了防止插队。

Redis事务中的指令会被打包一次执行因此可以避免多客户端指令交互执行的情况发生。

开启/执行/取消

开启事务并依次递增/递减/递增。

每个指令输入后都会返回QUEUED意味着指令已被成功加入

OKINCR

Redis事务分为组队/执行两个阶段。

组队阶段是Redis事务的第一阶段由指令“MULTI”在开启事务时同步开启。

在组队阶段中Redis会创建相应的事务队列用于顺序接收客户端发送的各项指令因此事务中的指令其实是多次发送的。

而由于Redis不可能在客户端发送全部指令/发送“EXEC”指令/发送“DISCARD”前无限等待因为整个事务指令发送过程的时长并不可控因此Redis实际上可以并发接受多个客户端指令。

这种并发接收可能是单线程在多客户端之间相互切换实现的也可能真的有多个线程在各自为政这具体与Redis的版本有关。

随着Redis的不断发展早期6.0之前版本的“单线程实现”描述其实已经不太准确了就比如现今绝大多数版本的Redis都会启用额外线程来实现数据持久化。

但一直以来始终不变的是指令必然只会由唯一的主线程执行因此在该设计被破坏前无论Redis如何引入多线程其都可以被称为单线程实现。

Redis事务可能无法进入执行阶段。

执行阶段顾名思义即是将已完成组队的事务指令整体交由主线程依次执行。

而由于执行阶段会由“EXEC”负责开启因此如果客户端事先发送了“DISCARD”指令那么事务/事务队列就会直接结束/丢弃而无法进入执行阶段。

而除此之外如果客户端发送的指令出现语法错误那事务也会因为原子性而直接结束…该知识点会在下文讲解原子性时详述。

原子性

Redis事务具备“伪”原子性。

原子性通俗的说法就是“要么一起成功要么一起失败”关于Redis事务的原子性一直是相当具有争议的点原因就是其未曾“完全”遵循原子性的定义即其允许在某些情况下部分成功。

因此Redis具备原子性虽然属于官方说法但仍有部分开发者坚持认为其并不具备原子性。

而对于作者本人而言我认为Redis是具有原子性的只是基于其功能定位而难以/无法实现的足够彻底而已因此我将这种原子性称为“伪”原子性。

Redis事务在组队阶段具备“真”原子性。

对于在组队阶段的事务而言如果客户端输入的指令在语法上存在错误那么其整个事务/事务队列都会直接结束/丢弃。

该行为符合原子性的标准定义因此Redis事务在组队阶段具备“真”原子性…具体图示/案例如下

SET

错误指令不同版本的Redis/图形客户端在此会有不同的表现我这里显示排队成功但有些版本会直接报错。

INCR1

num

errors.Redis事务在执行阶段具备“伪”原子性。

对于在执行阶段的事务而言即使其在过程中出现某指令执行异常的情况Redis也只会记录该异常并继续执行后续指令因此Redis事务并不具备数据回滚能力。

该行为明显违背了原子性的标准定义因此Redis事务在执行阶段只具备“伪”原子性…具体图示/案例如下

SET

执行后只有两个结果因为第二条指令会执行失败。

可能是因为Redis版本/图形客户端

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事务2T1商品总量为5000开启事务商品总量为5000开启事务T2组队指令

设置商品总量为4000-1000组队指令

Redis提供了乐观锁机制的{WTACH}指令用于监控事务的目标数据。

上述问题的本质还是线程安全问题其核心在于指令的执行依据被并发修改因此只要能够控制这一点就能为事务的正确执行提供基础可能。

对此Redis基于乐观锁机制提供了{WTACH}指令用于监控目标数据其本质是记录目标数据的快照。

而当事务进入执行阶段时其会将最新的目标数据与快照进行对比并在发现目标数据已变化的情况下拒绝执行事务并返回null…具体示例如下

WATCH

如果目标数据在事务组队期间被其它线程/事务修改当前事务将不会执行并返回null。

EXEC

null管道

管道可大幅提升多指令的执行效率。

管道相当于将事务的组队阶段从服务端转移到了客户端执行因此其不会像事务一样多次发送指令而是会直接将已完成打包/组队的命令集一次性发送至服务端执行。

而又因为Redis执行的高效性会使得指令/数据的RRT

Round

往返时间/网络传输时间远远多于指令的执行时间因此多指令/数据的一次性发送/返回能够有效提升批量操作的执行效率也因此管道被广泛用于数据大批量导入/导出的场景中。

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

public