Redis事务详解 | 「笔耕不辍」-CSDN博客

本文链接：https://blog.csdn.net/qq_63992577/article/details/127008582

文章目录

🌕博客x主页：不止于梦想 🌕!
🌎文章说明：Redis入门分享🌎
✅系列专栏：Redis
🌴本篇内容：Redis的事务（对所需知识点进行选择阅读呀~）
☕️每日一语：人生恰恰像马拉松赛跑一样只有坚持到最后的人,才能称为胜利者。 ☕️
🕤作者详情:作者是一名双非大三在校生，喜欢Java，欢迎大家探讨学习，喜欢的话请给博主一个三连。

事务简介

事务介绍

事务（transaction）：数据库操作的最小的不可再分的工作单元；通常一个事务对应一个完整的业务。

事务只和DML语句有关，或者说只有DML语句才有事务。

在事物进行过程中，未结束之前，DML语句不会更改底层数据，它只是将历史操作记录一下，在内存中完成记录。只有在事物结束的时候，而且是成功的结束的时候，才会修改底层硬盘文件中的数据。

事务的特点：

事务具有四个特征：原子性（ Atomicity ）、一致性（ Consistency ）、隔离性（Isolation ）和持续性（ Durability ），简称ACID。
事务是为了保证对同一数据表操作的一致性。
即多条语句放在事务中执行的时候，要么一起成功，要么全不成功。
数据库中的事务就是需要捆绑在一起执行的操作集合，他们应不能被部分的完成。
虽然事务并不都是用在数据库中的，但他们都有以下共同性质
事务应当具有ACID性质，
A是原子性(atomic)：事务中包含的各项操作必须全部成功执行或者全部不执行。任何一项操作失败，将导致整个事务失败，其他已经执行的任务所作的数据操作都将被撤销，只有所有的操作全部成功，整个事务才算是成功完成。
C是一致性(consistent)：保证了当事务结束后，系统状态是一致的。比如A用户给B用户转了10000元，转账之前和转账之后两个用户的账户综合是相等的、称为一致性。
I是隔离性(isolated)：多个并发执行的事务，彼此无法看到对方的中间状态。保证了并发执行的事务顺序执行，而不会导致系统状态不一致。
D是持久性(durable)：保证了事务完成后所作的改动都会被持久化，即使是发生灾难性的失败。可恢复性资源保存了一份事务日志，如果资源发生故障，可以通过日志来将数据重建起来。

redis事务的特点

1、单独的隔离操作：事务中的所有命令都会序列化、顺序地执行。事务在执行过程中，不会被其它客户端发来的命令请求所打断，除非使用watch命令监控某些键。
2、不保证事务的原子性：redis同一个事务中如果一条命令执行失败，其后的命令仍然可能会被执行，redis的事务没有回滚。Redis已经在系统内部进行功能简化，这样可以确保更快的运行速度，因为Redis不需要事务回滚的能力。
3、redis事务没有隔离级别，这与mysql是不同的。

Redis事务的常用命令

常用命令概述

multi：

用于标记事务块的开始。Redis会将后续的命令逐个放入队列中，然后才能使用EXEC命令原子化地执行这个命令序列。
执行成功返回ok

代码块：

set k1 v1
set k2 v2
set k3 v3
set k4 v4

在没有检查出错误的情况下，这些命令没有直接执行，而是按照输入顺序依次入队列，等待exec命令之后统一执行，

exec:

在一个事务中执行所有先前放入队列的命令，然后恢复正常的连接状态。
值得注意的是：
- 如果在把命令压入队列的过程中报错，则整个队列中的命令都不会执行，执行结果报错；
  
  还是用上面数据做一个图片，上面数据都没有报错，则exec结果为：
  
  如果在压入过程中报错呢？请看下边
- 如果在压队列的过程中正常，在执行队列中某一个命令报错，则只会影响本条命令的执行结果，其它命令正常运行；
- 当使用WATCH命令时，只有当受监控的键没有被修改时，EXEC命令才会执行事务中的命令;而一旦执行了exec命令，之前加的所有watch监控全部取消。

discard：

清除所有先前在一个事务中放入队列的命令，并且结束事务。
如果使用了WATCH命令，那么DISCARD命令就会将当前连接监控的所有键取消监控。

set k1 v1
set k2 v2
set k3 v3
discard

在这里插入图片描述

Redis的锁机制

乐观锁

乐观锁，顾名思义就是很乐观，认为别人在拿数据的时候不会更改，所以就不会上锁。一般在想要更新数据的时候，会在更新前检查在读取至更新这段时间别人有没有修改过这个数据。如果修改过，则重新读取，再次尝试更新，循环上述步骤直到更新成功。

悲观锁

悲观锁（Pessimistic Lock）：从字面来看就是很悲观，每次去拿数据的时候都认为别人会修改。所以每次在拿数据的时候都会上锁。这个过程中别人是拿不到锁的，除非悲观锁被释放，悲观锁中的共享资源每次只给一个线程使用，其它线程阻塞，直到用完后再把资源转让给其它线程
所以在效率方面，处理加锁的机制会产生额外的开销，还有增加产生死锁的机会。另外还会降低并行性，如果已经锁定了一个线程A，其他线程就必须等待该线程A处理完才可以处理

数据库中的行锁，表锁，读锁，写锁都是悲观锁。