Redis｜事务

文章目录

- 是什么
- 能干嘛
- Redis 事务 VS 数据库事务
- 怎么玩
- 小总结

是什么

首先回想一下什么是数据库的事务？数据库事务是指作为单个逻辑单元执行的一系列操作，具备以下四个关键特性（ACID）：
- 原子性（Atomicity）：事务中的所有操作要么全部完成，要么全部不完成，不存在部分执行的情况。如果中途出错，已执行的操作会回滚，确保数据一致性。
- 一致性（Consistency）：事务执行前后，数据库必须保持一致性状态，即符合预定义的规则和约束。
- 隔离性（Isolation）：多个事务并发执行时，彼此互不干扰，每个事务都像是在独立运行。数据库通过锁机制或多版本控制来实现隔离性。
- 持久性（Durability）：事务一旦提交，其结果将永久保存在数据库中，即使系统故障也不会丢失。
事务的状态：
- 活动（Active）：事务正在执行。
- 部分提交（Partially Committed）：操作执行完毕，但未最终提交。
- 提交（Committed）：事务成功完成，结果永久保存。
- 失败（Failed）：无法继续执行。
- 中止（Aborted）：事务回滚，数据库恢复到事务开始前的状态。
官网：https://redis.io/docs/manual/transactions/
可以一次执行多个命令，本质是一组命令的集合，一个事务中的所有命令都会序列化，按顺序地串行化执行而不会被其他命令插入，不许加塞

在这里插入图片描述

能干嘛

一个队列中，一次性、顺序性、排他性的执行一系列命令

Redis 事务 VS 数据库事务

对比	详细解释
单独的隔离操作	Redis的事务仅仅是保证事务里的操作会被连续独占的执行，redis命令执行是单线程架构，在执行完事务内所有指令前是不可能再去同时执行其他客户端的请求的
没有隔离级别的概念	因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这种问题了
不保证原子性	Redis的事务不保证原子性（部分支持），也就是不保证所有指令同时成功或同时失败，只有决定是否开始执行全部指令的能力，没有执行到一半进行回滚的能力
排它性	Redis会保证一个事务内的命令依次执行，而不会被其它命令插入

怎么玩

官网：https://redis.io/docs/manual/transactions/

在这里插入图片描述

常用命令

在这里插入图片描述

case1:正常执行 MULTI、EXEC
case2:放弃事务 MULTI、DISCARD
case3:全体连坐，一个语法出错，全体连坐。如果任何一个命令语法有错，Redis 会直接返回错误，所有的命令都不会执行
case4:源头债主
注意和传统数据库事务的区别，不一定要么全部成功要么全部失败
case5:watch监控
- Redis使用 Watch 来提供乐观锁定，类似于 CAS(Check-and-Set)
  1. 悲观锁：悲观锁(Pessimistic Lock)，顾名思义，就是很悲观，每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会block直到它拿到锁。
  2. 乐观锁：乐观锁(Optimistic Lock)，顾名思义，就是很乐观，每次去拿数据的时候都认为别人不会修改，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。
    - 乐观锁策略：提交版本必须【大于】记录当前版本才能执行更新。
    - 与悲观锁不同，乐观锁不会在操作前加锁，而是在提交修改时检查数据是否被其他客户端修改过。如果数据未被修改，则提交成功；否则，操作失败，客户端可以选择重试或放弃。
  3. CAS
- watch
  - 初始化 k1 和 balance 两个 key，先监控在开启 multi，保证两个 key 变动在同一个事务内
  - 有加塞篡改：watch 命令是一种乐观锁的实现，Redis 在修改的时候会检测数据是否被更改，如果被更改了，则执行失败
- unwatch
小结：
- 一旦执行了 exec 之前加的监控锁都会被取消掉
- 当客户端连接丢失的时候(比如退出链接)，所有东西都会被取消监视