关于java:腾讯二面Redis-事务支持-ACID-么

45次阅读

共计 4618 个字符，预计需要花费 12 分钟才能阅读完成。

腾讯面试官：「数据库事务机制理解么？」

「内心独白：小意思，不就 ACID 嘛，转瞬一想，我面试的可是技术专家，不会这么简略的问题吧」

程许远：「balabala…… 极其自信且从容淡定的说了一通。」

腾讯面试官：「Redis 的事务理解么？它的事务机制能实现 ACID 属性么？」

程许远：「挠头，这个……我晓得 lua 脚本能实现事务…」

腾讯面试官：「好的，回去等告诉吧。」

码哥，我跟着你学习了《Redis 系列》斩获了很多 offer，没想到最初败在了「Redis 如何实现事务？」这个问题上。

咱们来一步步剖析：

  1. 什么是事务 ACID？
  2. Redis 如何实现事务？
  3. Redis 的事务能实现哪些属性？
  4. Lua 脚本实现。

什么是事务的 ACID

鬼吹灯之《云南虫谷》中的摸金校尉有句话叫「合则生，分则死」，为了寻找雮尘珠他们三人分工明确、群策群力共进退 方可胜利。

事务（Transaction）是并发管制单位，一个操作序列组合而成，这些操作要么都执行，要么都不执行。

「是一个不可分割的工作单位」。

事务在执行时，会提供专门的属性保障：

  • 原子性（Atomicity）：一个事务的多个操作必须实现，或者都不实现（ps：MySQL 的原子性靠什么实现呢？欢送留言区评论）；

  • 一致性（Consistency）：事务执行完结后，数据库的完整性束缚没有被毁坏，事务执行的前后程序都是非法数据状态。

    数据库的完整性束缚包含但不限于：

    • 实体完整性（如行的主键存在且惟一）；
    • 列完整性（如字段的类型、大小、长度要符合要求）
    • 外键束缚；
    • 用户自定义完整性（如转账前后，两个账户余额的和应该不变）。

  • 隔离性（Isolation）：事务外部的操作与其余事务是隔离的，并发执行的各个事务之间不能相互烦扰。

    考究的是不同事务之间的相互影响，严格的隔离性对应隔离级别中的可串行化（Serializable）。

  • 持久性（Durability）：事务一旦提交，所有的批改将永恒的保留到数据库中，即便零碎解体重启后数据也不会失落。

码哥，理解了 ACID 的具体要求后，Redis 是如何实现事务机制呢？

Redis 如何实现事务

MULTI、EXEC、DISCARD 和 WATCH 命令是 Redis 实现事务的的根底。

Redis 事务的执行过程蕴含三个步骤：

  1. 开启事务；
  2. 命令入队；
  3. 执行事务或抛弃；

显式开启一个事务

客户端通过 MULTI 命令显式地示意开启一个事务，随后的命令将排队缓存，并不会理论执行。

命令入队

客户端把事务中的要执行的一系列指令发送到服务端。

须要留神的是，尽管指令发送到服务端，然而 Redis 实例只是把这一系列指令暂存在一个命令队列中，并不会立即执行。

执行事务或抛弃

客户端向服务端发送提交或者抛弃事务的命令，让 Redis 执行第二步中发送的具体指令或者清空队列命令，放弃执行。

Redis 只需在调用 EXEC 时，即可安顿队列命令执行。

也可通过 DISCARD 抛弃第二步中保留在队列中的命令。

Redis 事务案例

通过在线调试网站执行咱们的样例代码：https://try.redis.io

失常执行

通过 MULTI 和 EXEC 执行一个事务过程：

# 开启事务
> MULTI
OK
# 开始定义一些列指令
> SET“公众号: 码哥字节”"粉丝 100 万"
QUEUED
> SET "order" "30"
QUEUED
> SET "文章数" 666
QUEUED
> GET "文章数"
QUEUED
# 理论执行事务
> EXEC
1) OK
2) OK
3) OK
4) "666"

咱们看到每个读写指令执行后的返回后果都是 QUEUED，示意谢谢操作都被暂存到了命令队列，还没有理论执行。

当执行了 EXEC 命令，就能够看到具体每个指令的响应数据。

放弃事务

通过 MULTI 和 DISCARD抛弃队列命令：

# 初始化订单数
> SET "order:mobile" 100
OK
# 开启事务
> MULTI
OK
# 订单 - 1
> DECR "order:mobile"
QUEUED
# 抛弃丢列命令
> DISCARD
OK
# 数据没有被批改
> GET "order:mobile"
"100"

码哥，Redis 的事务能保障 ACID 个性么？

这个问题问得好，咱们一起来剖析下。

Redis 事务满足 ACID？

Redis 事务能够一次执行多个命令，并且带有以下三个重要的保障：

  1. 批量指令在执行 EXEC 命令之前会放入队列暂存；
  2. 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令仍然被执行；
  3. 事务执行过程中，其余客户端提交的命令不会插入到以后命令执行的序列中。

原子性

码哥，如果事务执行过程中产生谬误了，原子性能保障么？

在事务期间，可能遇到两种命令谬误：

  • 在执行 EXEC 命令前，发送的指令自身就谬误。如下：

    • 参数数量谬误；
    • 命令名称谬误，应用了不存在的命令；
    • 内存不足（Redis 实例应用 maxmemory指令配置内存限度）。
  • 在执行 EXEC 命令后，命令可能会失败。例如，命令和操作的数据类型不匹配（对 String 类型 的 value 执行了 List 列表操作）；
  • 在执行事务的 EXEC 命令时。Redis 实例产生了故障导致事务执行失败。

EXEC 执行前报错

在命令入队时，Redis 就会 报错并且记录下这个谬误。

此时，咱们 还能持续提交命令操作。

等到执行了 EXEC命令之后，Redis 就会 拒绝执行所有提交的命令操作，返回事务失败的后果。

这样一来，事务中的所有命令都不会再被执行了，保障了原子性。

如下是指令入队产生谬误，导致事务失败的例子：

# 开启事务
> MULTI
OK
#发送事务中的第一个操作，然而 Redis 不反对该命令，返回报错信息
127.0.0.1:6379> PUT order 6
(error) ERR unknown command `PUT`, with args beginning with: `order`, `6`,
#发送事务中的第二个操作，这个操作是正确的命令，Redis 把该命令入队
> DECR b:stock
QUEUED
#理论执行事务，然而之前命令有谬误，所以 Redis 拒绝执行
> EXEC
(error) EXECABORT Transaction discarded because of previous errors.

EXEC 执行后报错

事务操作入队时，命令和操作的数据类型不匹配，但 Redis 实例没有查看出谬误。

然而，在执行完 EXEC 命令当前，Redis 理论执行这些指令，就会报错。

敲黑板了：Redis 尽管会对谬误指令报错，然而事务仍然会把正确的命令执行完，这时候事务的原子性就无奈保障了！

码哥，为什么 Redis 不反对回滚？

其实，Redis 中并没有提供回滚机制。尽管 Redis 提供了 DISCARD 命令。

然而，这个命令只能用来被动放弃事务执行，把暂存的命令队列清空，起不到回滚的成果。

EXEC 执行时，产生故障

如果 Redis 开启了 AOF 日志，那么，只会有局部的事务操作被记录到 AOF 日志中。

咱们须要应用 redis-check-aof 工具查看 AOF 日志文件，这个工具能够把未实现的事务操作从 AOF 文件中去除。

这样一来，咱们应用 AOF 复原实例后，事务操作不会再被执行，从而保障了原子性。

简略总结：

  • 命令入队时就报错，会放弃事务执行，保障原子性；
  • 命令入队时没报错，理论执行时报错，不保障原子性；
  • EXEC 命令执行时实例故障，如果开启了 AOF 日志，能够保障原子性。

一致性

一致性会受到谬误命令、实例故障产生机会的影响，依照命令出错实例故障两个维度的产生机会，能够分三种状况剖析。

EXEC 执行前，入队报错

事务会被放弃执行，所以能够保障一致性。

EXEC 执行后，理论执行时报错

有谬误的执行不会执行，正确的指令能够失常执行，一致性能够保障。

EXEC 执行时，实例故障

实例故障后会进行重启，这就和数据恢复的形式无关了，咱们要依据实例是否开启了 RDB 或 AOF 来分状况探讨下。

如果咱们没有开启 RDB 或 AOF，那么，实例故障重启后，数据都没有了，数据库是统一的。

如果咱们应用了 RDB 快照，因为 RDB 快照不会在事务执行时执行。

所以，事务命令操作的后果不会被保留到 RDB 快照中，应用 RDB 快照进行复原时，数据库里的数据也是统一的。

如果咱们应用了 AOF 日志，而事务操作还没有被记录到 AOF 日志时，实例就产生了故障，那么，应用 AOF 日志复原的数据库数据是统一的。

如果只有局部操作被记录到了 AOF 日志，咱们能够应用 redis-check-aof 革除事务中曾经实现的操作，数据库复原后也是统一的。

隔离性

事务执行又能够分成命令入队（EXEC 命令执行前）和命令理论执行（EXEC 命令执行后）两个阶段。

所以在并发执行的时候咱们针对这两个阶段分两种状况剖析：

  1. 并发操作在 EXEC 命令前执行，隔离性须要通过 WATCH 机制保障；
  2. 并发操作在 EXEC 命令之后，隔离性能够保障。

码哥，什么是 WATCH 机制？

咱们重点来看第一种状况：一个事务的 EXEC 命令还没有执行时，事务的命令操作是暂存在命令队列中的。

此时，如果有其它的并发操作，同样的 key 被批改，须要看事务是否应用了 WATCH 机制。

WATCH 机制的作用是：在事务执行前，监控一个或多个键的值变动状况，当事务调用 EXEC 命令执行时，WATCH 机制会先查看监控的键是否被其它客户端批改了。

如果批改了，就放弃事务执行，防止事务的隔离性被毁坏。

同时，客户端能够再次执行事务，此时，如果没有并发批改事务数据的操作了，事务就能失常执行，隔离性也失去了保障。

没有 WATCH

如果没有 WATCH 机制，在 EXEC 命令执行前的并发操作对数据读写。

当执行 EXEC 的时候，事务外部要操作的数据曾经扭转，Redis 并没有做到事务之间的隔离。

并发操作在 EXEC 之后接管执行

至于第二种状况，因为 Redis 是用单线程执行命令，而且，EXEC 命令执行后，Redis 会保障先把命令队列中的所有命令执行完再执行之后的指令。

所以，在这种状况下，并发操作不会毁坏事务的隔离性。

持久性

如果 Redis 没有应用 RDB 或 AOF，那么事务的长久化属性必定得不到保障。

如果 Redis 应用了 RDB 模式，那么，在一个事务执行后，而下一次的 RDB 快照还未执行前，如果产生了实例宕机，数据失落，这种状况下，事务批改的数据也是不能保障长久化的。

如果 Redis 采纳了 AOF 模式，因为 AOF 模式的三种配置选项 no、everysec 和 always 都会存在数据失落的状况。

所以，事务的持久性属性也还是得不到保障。

不论 Redis 采纳什么长久化模式，事务的持久性属性是得不到保障的。

总结

  • Redis 具备了肯定的原子性，但不反对回滚。
  • Redis 不具备 ACID 中一致性的概念。(或者说 Redis 在设计时就忽视这点)
  • Redis 具备隔离性。
  • Redis 无奈保障持久性。

Redis 的事务机制能够保障一致性和隔离性，然而无奈保障持久性。

不过，因为 Redis 自身是内存数据库，持久性并不是一个必须的属性，咱们更加关注的还是原子性、一致性和隔离性这三个属性。

原子性的状况比较复杂，当事务中应用的命令语法有误时，原子性得不到保障，在其它状况下，事务都能够原子性执行。

好文举荐

Redis 外围篇：为什么这么快

Redis 长久化篇：AOF 与 RDB 如何保证数据高可用

Redis 高可用篇：主从架构数据一致性同步原理

Redis 高可用篇：哨兵集群原理

Redis 高可用篇：Cluster 集群原理

Redis 实战篇：巧用 Bitmap 实现亿级海量数据统计

Redis 实战篇：通过 Geo 类型实现左近的人邂逅女神

Redis 新个性篇：多线程模型解读

Redis 6.0 新个性篇：客户端缓存带来的反动

正文完
java
发表至： java
2022-01-14
 0
关于java:APK反编译与证书签名
关于java:JavaWeb学习笔记01-TomcatMaven
关于java:JVM参数调优
关于java:Fastjson-的-3-种漏洞利用链一起来看看