MySQL 如何避免 RC 隔离级别下的 INSERT 死锁？

news2024/10/5 22:24:46

本文分析了 INSERT 及其变种（REPLACE/INSERT ON DUPLICATE KEY UPDATE）的几个场景的死锁及如何避免。

作者：张洛丹，DBA 数据库技术爱好者~

爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

本文共 3200 字，预计阅读需要 10 分钟。

说在前面

本文分析了 INSERT 及其变种（REPLACE/INSERT ON DUPLICATE KEY UPDATE）的几个场景的死锁及如何避免：

  • 场景一：INSERT 唯一键冲突
  • 场景二/三：REPLACE INTO 唯一键冲突（来自线上业务）
  • 场景四：INSERT 主键冲突（来自官方案例）

其实 Google 一番，也会有大量这样的文章。本文只是就几个场景进行了分析，不过一遍走下来，对 INSERT 加锁情况、如何导致的死锁也就掌握了，个人能力有限，如文中内容有错误和纰漏，也欢迎大佬指出。

有兴趣的就继续往下看吧~

回顾行锁

在此之前，先浅浅回顾一下 InnoDB 中的行锁类型。

记录锁（RECORD LOCK）

对索引记录加锁。

间隙锁（GAP LOCK，也叫范围锁）

对索引记录的所在间隙加锁，在 RR 隔离级别下，用于解决幻读的问题（实际上在 RC 隔离级别下，也会产生间隙锁）。

S 间隙锁和 X 间隙锁是兼容的，不同的事务可以在同一个间隙加锁。

NEXT-KEY 锁

相当于 RECORD LOCK + GAP LOCK。

插入意向锁（INSERT INTENTION LOCK）

GAP 锁的一种，在执行 INSERT 前，如果待插入记录的下一条记录上被加了 GAP 锁，则 INSERT 语句被阻塞，且生成一个插入意向锁。

仅会被 GAP 锁阻塞。

隐式锁

新插入的记录，不生成锁结构，但由于事务 ID 的存在，相当于加了隐式锁；别的事务要对这条记录加锁前，先帮助其生成一个锁结构，然后再进入等待状态。

这里产生死锁的关键就是 GAP 锁。GAP 锁是在 RR 隔离级别下用于解决幻读问题，但是 RC 隔离级别下，在重复键检查和外键检查时也会用到。

再浅浅回顾一下 INSERT 语句加锁类型：

  1. 被 GAP 锁阻塞时，生成一个插入意向锁。
  2. 遇到重复键冲突时
    • 主键冲突，产生 S 型记录锁（RR 和 RR 隔离级别，实际上在 INSERT 阶段时还是会请求 GAP 锁）。
    • 唯一键冲突，产生 S 型 NEXT-KEY 锁（RR 和 RR 隔离级别）。

注意：INSERT 语句正常执行时，不会生成锁结构。

另外，对于 INSERT ... ON DUPLICATE KEY UPDATE 和 REPLACE 稍有一些不同：

锁类型的不同

INSERT ... ON DUPLICATE KEY UPDATE 和 REPLACE 如果遇到重复键冲突。

  • 如果是主键冲突，加 X 型记录锁（RR 和 RR 隔离级别，实际上在 INSERT 阶段时还是会请求 GAP 锁）。
  • 如果是唯一键冲突，加 X 型 NEXT-KEY 锁（RR 和 RR 隔离级别）。

锁范围不同

  • INSERT 和 INSERT ... ON DUPLICATE KEY UPDATE 在插入或 UPDATE 的行上加 NEXT-KEY 锁。
  • REPLACE 在加 NEXT-KEY 锁时，会在 REPLACE 的记录及其下一条记录上加 NEXT-KEY 锁。

    这里和官方文档描述有些不同。如下，官方仅说了会在被 REPLACE 的行上加 NEXT-KEY 锁，但是测试下来其下一行也会加 NEXT-KEY 锁，具体见后文的场景。

最后浅浅回顾一下死锁的产生条件以及观测手段：

死锁的产生条件

两个或两个以上事务，互相等待对方持有的锁，且持有对方需要的锁，从而造成循环等待。

死锁观测手段

performance_schema.data_locks 查看会话产生的锁结构信息。

SELECT ENGINE_TRANSACTION_ID, OBJECT_NAME, INDEX_NAME, LOCK_TYPE, LOCK_MODE, LOCK_STATUS, LOCK_DATA FROM performance_schema.data_locks;

show engine innodb status 查看死锁信息。

正式开始

正式开始前还是要说一下基本的环境信息：

  • MySQL 8.0.32
  • transaction_isolation：READ-COMMITTED

准备数据

每个案例初始数据都是这些。

DROP TABLE IF EXISTS t1;
CREATE TABLE t1 (
    id INT NOT NULL AUTO_INCREMENT,
    a INT NULL,
    b INT NULL,
    PRIMARY KEY (id),
    UNIQUE INDEX uk_a (a ASC)
);
INSERT INTO t1 (id, a, b) VALUES (1, 10, 0);
INSERT INTO t1 (id, a, b) VALUES (2, 20, 0);
INSERT INTO t1 (id, a, b) VALUES (3, 30, 0);
INSERT INTO t1 (id, a, b) VALUES (4, 40, 0);
INSERT INTO t1 (id, a, b) VALUES (5, 50, 0);

场景一

时刻session1session2
T1BEGIN;
INSERT INTO t1(a,b) VALUES (35,0);
T2BEGIN;
INSERT INTO t1(a,b) VALUES (35,0); --被阻塞
T3INSERT INTO t1(a,b) VALUES (33,0)
T4DEADLOCK

不同时刻持有锁状态如下：

说明：示意图中仅画出我们分析的唯一索引上的锁，实际上在对唯一索引加上锁后，还会对对应的聚簇索引加记录锁，对主键索引但这里不去体现了，下文同。

过程解说

T1 时刻

session1 插入记录成功，此时对应的索引记录被隐式锁保护，未生成锁结构。

T2 时刻

session2 插入记录检测到插入值和 session1 唯一键冲突。

  • session2 帮助 session1 对 a=35 的记录产生了一个显式的锁结构。
  • session2 自身产生 S 型的 NEXT-KEY LOCK，请求范围为 (30,35]，但是其只能获取到 (30,35) 的 GAP LOCK，而被 session1 的 a=35 的记录锁阻塞。
mysql> SELECT ENGINE_TRANSACTION_ID, OBJECT_NAME, INDEX_NAME, LOCK_TYPE, LOCK_MODE, LOCK_STATUS, LOCK_DATA FROM performance_schema.data_locks;
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
| ENGINE_TRANSACTION_ID | OBJECT_NAME | INDEX_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA |
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
|               xxxxxx2 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|               xxxxxx2 | t1          | uk_a       | RECORD    | S             | WAITING     | 35, 7     |
|               xxxxxx1 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|               xxxxxx1 | t1          | uk_a       | RECORD    | X,REC_NOT_GAP | GRANTED     | 35, 7     |
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
4 rows in set (0.01 sec)
T3 时刻
  • session1 插入 a=33，被 session2 (30,35)间隙锁阻塞。

至此，形成闭环锁等待，死锁条件达成：

  • session1 持有 session2 需要的 a=35 记录锁，且请求 session2 持有的 (30,35) GAP 锁。
  • session2 持有 session1 需要的 (30,35) GAP 锁，且请求 session1 持有的记录锁。

下面是打印的死锁日志。

针对该场景的死锁该如何避免：

  • 在一个事务中的 INSERT 按照主键或唯一键的顺序增序插入，即 session1 可以先插入 a=33 的记录，再插入 a=35 的记录，可一定程度避免受到 GAP 锁的影响。
  • 一个事务中只插入一行记录，且尽快提交。

场景二

时刻session1session2session3
T1BEGIN; REPLACE INTO t1 (a, b) VALUES (40, 1);
T2BEGIN; REPLACE INTO t1 (a, b) VALUES (30, 1); -- 被阻塞
T3BEGIN; REPLACE INTO t1 (a, b) VALUES (40, 1);  -- 被阻塞
T4COMMIT;
T52 rows affected;DEADLOCK,ROLLBACK;

不同时刻持有锁状态如下：

过程解说

T1 时刻

session1 检测到唯一键冲突，对 REPLACE 的记录和其下一条记录加 X 型 NEXT-KEY 锁，即锁范围为 (30,40],(40,50]。

注意：这里和 INSERT 区分，INSERT 遇到唯一键冲突被阻塞时，在插入的记录上加的 NEXT-KEY 锁，这里 REPLACE 是在插入记录和下一条记录上加的 NEXT-KEY 锁（官方文档描述似乎有欠妥当）。

锁情况

mysql> SELECT ENGINE_TRANSACTION_ID, OBJECT_NAME, INDEX_NAME, LOCK_TYPE, LOCK_MODE, LOCK_STATUS, LOCK_DATA FROM performance_schema.data_locks;
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
| ENGINE_TRANSACTION_ID | OBJECT_NAME | INDEX_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA |
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
|               xxxxxx1| t1          | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|               xxxxxx1| t1          | uk_a       | RECORD    | X             | GRANTED     | 40, 4     |
|               xxxxxx1| t1          | uk_a       | RECORD    | X             | GRANTED     | 50, 5     |
|               xxxxxx1| t1          | PRIMARY    | RECORD    | X,REC_NOT_GAP | GRANTED     | 4         |
|               xxxxxx1| t1          | uk_a       | RECORD    | X,GAP         | GRANTED     | 40, 10    |
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
5 rows in set (0.00 sec)
T2 时刻

session2 遇到唯一键冲突，对 REPLACE 的记录和其下一条记录加 X 型 NEXT-KEY 锁，即锁范围是 (20,30],(30,40]，对 (20,30],(30,40) 加锁成功，但是等待 session1 a=40 的记录锁。

mysql> SELECT ENGINE_TRANSACTION_ID, OBJECT_NAME, INDEX_NAME, LOCK_TYPE, LOCK_MODE, LOCK_STATUS, LOCK_DATA FROM performance_schema.data_locks;
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
| ENGINE_TRANSACTION_ID | OBJECT_NAME | INDEX_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA |
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
|               xxxxxx2 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|               xxxxxx2 | t1          | uk_a       | RECORD    | X             | GRANTED     | 30, 3     |
|               xxxxxx2 | t1          | PRIMARY    | RECORD    | X,REC_NOT_GAP | GRANTED     | 3         |
|               xxxxxx2 | t1          | uk_a       | RECORD    | X             | WAITING     | 40, 4     |
|               xxxxxx1 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|               xxxxxx1 | t1          | uk_a       | RECORD    | X             | GRANTED     | 40, 4     |
|               xxxxxx1 | t1          | uk_a       | RECORD    | X             | GRANTED     | 50, 5     |
|               xxxxxx1 | t1          | PRIMARY    | RECORD    | X,REC_NOT_GAP | GRANTED     | 4         |
|               xxxxxx1 | t1          | uk_a       | RECORD    | X,GAP         | GRANTED     | 40, 10    |
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
9 rows in set (0.00 sec)
T3 时刻

session3 请求的锁类型和 session1 相同，锁范围为（30,40],(40,50]，在获取(30,40] NEXT-KEY 锁时，只获取到了(30,40) GAP 锁，等待 session1 a=40 的记录锁。

注意：这里还未对（40，50] 加上锁，InnoDB 行锁是逐行获取的，无法获取到则被阻塞。

锁情况

mysql> SELECT ENGINE_TRANSACTION_ID, OBJECT_NAME, INDEX_NAME, LOCK_TYPE, LOCK_MODE, LOCK_STATUS, LOCK_DATA FROM performance_schema.data_locks;
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
| ENGINE_TRANSACTION_ID | OBJECT_NAME | INDEX_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA |
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
|               xxxxxx3 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|               xxxxxx3 | t1          | uk_a       | RECORD    | X             | WAITING     | 40, 4     |
|               xxxxxx2 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|               xxxxxx2 | t1          | uk_a       | RECORD    | X             | GRANTED     | 30, 3     |
|               xxxxxx2 | t1          | PRIMARY    | RECORD    | X,REC_NOT_GAP | GRANTED     | 3         |
|               xxxxxx2 | t1          | uk_a       | RECORD    | X             | WAITING     | 40, 4     |
|               xxxxxx1 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|               xxxxxx1 | t1          | uk_a       | RECORD    | X             | GRANTED     | 40, 4     |
|               xxxxxx1 | t1          | uk_a       | RECORD    | X             | GRANTED     | 50, 5     |
|               xxxxxx1 | t1          | PRIMARY    | RECORD    | X,REC_NOT_GAP | GRANTED     | 4         |
|               xxxxxx1 | t1          | uk_a       | RECORD    | X,GAP         | GRANTED     | 40, 10    |
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
11 rows in set (0.01 sec)
T4 时刻
  • session1 提交后，持有的锁释放。
  • session2 获取到 a=40 的记录锁，至此，session2 持有的锁为 (20,30],(30,40] NEXT-KEY 锁 ；session2获取到锁后，执行插入操作，由于插入的间隙是 (20,40)，被 session3 的 (30,40) GAP 锁阻塞，产生插入意向锁，并进入等待状态。

至此，形成闭环锁等待，死锁条件达成：

  • session2 持有 (20,30],(30,40] NEXT-KEY 锁，请求插入意向锁，被 session3 的 (30,40) GAP 锁阻塞。
  • session3 持有阻塞 session2 的 (30,40) GAP 锁，请求 sesion2 持有的 a=40 记录锁。

下面是打印的死锁日志。

场景三

时刻session1session2session3
T1BEGIN; SELECT * FROM t1 WHERE a=40 for UPDATE;
T2BEGIN; REPLACE INTO t1 (a, b) VALUES (30, 1);-- 被阻塞
T3BEGIN; REPLACE INTO t1 (a, b) VALUES (40, 1); -- 被阻塞
T4COMMIT;
T52 rows affected;DEADLOCK,ROLLBACK;

不同时刻持有锁状态如下：

该场景和场景二死锁情况基本相同，只是 session1 持有锁类型不同，就不一一解说了。

下面是打印的死锁日志。

针对场景二和场景三的死锁该如何避免？

从前面的分析中，可以看到在唯一键冲突时，INSERT、INSERT ... ON DUPLICATE KEY UPDATE 的加锁范围要比 REPLACE 加锁范围小，在该场景下，可使用 INSERT ... ON DUPLICATE KEY UPDATE 代替 REPLACE 来避免死锁，有兴趣的可以自己测试下。

场景四

说明

  • 本案例测试主键冲突的情况，先删除了表上的唯一键，避免干扰。
  • 对于唯一键冲突的该种场景下同样会产生死锁，死锁情况相同，有兴趣可自行验证。
时刻session1session2session3
T1BEGIN;INSERT INTO t1 (id,a, b) VALUES (6,60, 0);
T2BEGIN;INSERT INTO t1 (id,a, b) VALUES(6,70, 0); --被阻塞
T3BEGIN;INSERT INTO t1 (id,a, b) VALUES(6,80, 0);-- 被阻塞
T4ROLLBACK;
T51 rows affected;DEADLOCK,ROLLBACK;

锁情况

在 T1、T2、T3 阶段锁情况如下，此时并没有 GAP 锁，是记录锁，相应的锁状态如下：

mysql>  SELECT ENGINE_TRANSACTION_ID, OBJECT_NAME, INDEX_NAME, LOCK_TYPE, LOCK_MODE, LOCK_STATUS, LOCK_DATA FROM performance_schema.data_locks;
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
| ENGINE_TRANSACTION_ID | OBJECT_NAME | INDEX_NAME | LOCK_TYPE | LOCK_MODE     | LOCK_STATUS | LOCK_DATA |
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
|               xxxxxx3 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|               xxxxxx3 | t1          | PRIMARY    | RECORD    | S,REC_NOT_GAP | WAITING     | 6         |
|               xxxxxx2 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|               xxxxxx2 | t1          | PRIMARY    | RECORD    | S,REC_NOT_GAP | WAITING     | 6         |
|               xxxxxx1 | t1          | NULL       | TABLE     | IX            | GRANTED     | NULL      |
|               xxxxxx1 | t1          | PRIMARY    | RECORD    | X,REC_NOT_GAP | GRANTED     | 6         |
+-----------------------+-------------+------------+-----------+---------------+-------------+-----------+
6 rows in set (0.00 sec)
T4 时刻

session1 ROLLBACK，session2 和 session3 都获取到了 S 锁，在 INSERT 阶段，却产生了 NEXT-KEY 锁，锁范围为 (5,supremum]。

至此，形成闭环锁等待，死锁条件达成： session2 和 session3 分别想要在插入的间隙 (5,supremum) 获得插入意向锁，但分别被对方持有的 GAP 锁阻塞。

下面是打印的死锁日志。

触发死锁后，我们再看锁持有情况。

此时 session2 持有 (5,supremum)，再插入该范围内的记录都会被阻塞了。

mysql>  SELECT ENGINE_TRANSACTION_ID, OBJECT_NAME, INDEX_NAME, LOCK_TYPE, LOCK_MODE, LOCK_STATUS, LOCK_DATA FROM performance_schema.data_locks;
+-----------------------+-------------+------------+-----------+--------------------+-------------+------------------------+
| ENGINE_TRANSACTION_ID | OBJECT_NAME | INDEX_NAME | LOCK_TYPE | LOCK_MODE          | LOCK_STATUS | LOCK_DATA              |
+-----------------------+-------------+------------+-----------+--------------------+-------------+------------------------+
|               xxxxxx2 | t1          | NULL       | TABLE     | IX                 | GRANTED     | NULL                   |
|               xxxxxx2 | t1          | PRIMARY    | RECORD    | S                  | GRANTED     | supremum pseudo-record |
|               xxxxxx2 | t1          | PRIMARY    | RECORD    | X,INSERT_INTENTION | GRANTED     | supremum pseudo-record |
|               xxxxxx2 | t1          | PRIMARY    | RECORD    | S,GAP              | GRANTED     | 6                      |
+-----------------------+-------------+------------+-----------+--------------------+-------------+------------------------+
4 rows in set (0.00 sec)

小结

从前面的实验中可以看到无论是 INSERT 还是 REPLACE，在高并发的情况下由于唯一键的存在，即使在 RC 隔离级别下，仍然有较大概率会触发到死锁。当前只能在业务端做好容错处理，以下是一些小建议来减少或避免 INSERT 死锁：

  1. RC 隔离级别相较 RR 隔离级别产生死锁的概率小，但仍不可避免。
  2. INSERT ... ON DUPLICATE KEY UPDATE 比 REPLACE 产生死锁的几率小且更安全高效。
  3. 并发事务按照相同的顺序处理数据。
  4. 事务尽快提交，避免大事务、长事务。

另外，通过前面的实验，大家可能会有以下疑问：

  1. 为什么 RC 隔离级别要使用 GAP 锁？
  2. 为什么主键和唯一键的处理方式不同？
  3. ...？？？

有兴趣的可以到下面文章寻找答案： http://mysql.taobao.org/monthly/2022/05/02/ 更多技术文章，请访问：https://opensource.actionsky.com/

关于 SQLE

爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者，支持多场景审核，支持标准化上线流程，原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。

SQLE 获取

类型地址
版本库https://github.com/actiontech/sqle
文档https://actiontech.github.io/sqle-docs/
发布信息https://github.com/actiontech/sqle/releases
数据审核插件开发文档https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.coloradmin.cn/o/975015.html

如若内容造成侵权/违法违规/事实不符，请联系多彩编程网进行投诉反馈，一经查实，立即删除！

相关文章

Python类的方法

Python类的方法

Python类的方法主要分为实例方法、类方法和静态方法三种。 1 实例方法 以self作为第一个参数的方法，就是类的实例方法。该方法由类的实例调用，Python会把调用该方法的实例对象传递给self。 如下代码定义了一个名为A的类。 class A:def __init__(self…
阅读更多...
无频闪护眼灯哪个好？什么是无频闪

无频闪护眼灯哪个好？什么是无频闪

随着科技的不断发展，工作时使用电子设备越来越普遍,如何保护我们的眼睛不受蓝光、频闪等危害就变得极其重要了。护眼台灯，顾名思义就是保护眼睛的台灯，其工作原理是在光源处使用特殊的防蓝光灯珠，并通过控制电流的稳定性来达到防频…
阅读更多...
【STM32】文件系统FATFS与Flash的初步使用

【STM32】文件系统FATFS与Flash的初步使用

文件系统简介 简介可以不看，直接看移植步骤 文件系统是介于应用层和底层间的模糊层。底层提供API，比如说使用SDIO或者SPI等读写一个字节。文件系统把这些API组合包装起来，并且提供一些列函数，我们可以使用这些函数进行更进一步的…
阅读更多...
开发指导—利用组件插值器动画实现 HarmonyOS 动效

开发指导—利用组件插值器动画实现 HarmonyOS 动效

一. 组件动画 在组件上创建和运行动画的快捷方式。具体用法请参考通用方法。 获取动画对象 通过调用 animate 方法获得 animation 对象&#xff0c;animation 对象支持动画属性、动画方法和动画事件。 <!-- xxx.hml --><div class"container"> <di…
阅读更多...
IntelliJ IDEA中用git提交代码时忽略文件的设置

IntelliJ IDEA中用git提交代码时忽略文件的设置

设置IDEA自动过滤掉不需要提交的文件或文件夹&#xff1a;如*.iml, .idea,target 文件夹 1、进入idea设置界面 Windows环境&#xff1a;File - Settings - Editor - File Types Mac环境&#xff1a;Preferences… - Editor - File Types 2、在下面的ignore files and folders…
阅读更多...
SPA和MPA

SPA和MPA

SPA与MPA是什么 **SPA&#xff08;Single Page Application&#xff0c;单页应用&#xff09;**在首次加载时会下载一个单独的HTML文件&#xff0c;然后通过JavaScript动态加载内容&#xff0c;无需每次页面刷新时重新加载整个页面。**MPA&#xff08;Multi-Page Application&…
阅读更多...
【校招VIP】java语言考点之关键字string

【校招VIP】java语言考点之关键字string

考点介绍&#xff1a; string作为一个特殊类&#xff0c;正常情况下&#xff0c;是遵循对象的值和引用的使用。有一定的考察频度&#xff0c;但有的时候也能代表相等&#xff0c;与常量区的插入有关。 java语言考点之关键字string-相关题目及解析内容可点击文章末尾链接查看&a…
阅读更多...
redis缓存失效时间没到，数据莫名丢失问题排查

redis缓存失效时间没到，数据莫名丢失问题排查

述&#xff1a;redis缓存了token&#xff0c;失效时间为24小时&#xff0c;可是每次不到多久&#xff0c;就提示token失效&#xff0c;重新登录后&#xff0c;没用多久&#xff0c;又提示token失效。查看了下缓存&#xff0c;发现数据全部没掉了&#xff0c;并且多了几个back1&…
阅读更多...
电脑提示“系统找不到指定的文件”怎么办？

电脑提示“系统找不到指定的文件”怎么办？

“系统找不到指定的文件”对于Windows用户来说是一个很常见的错误&#xff0c;尤其是Win10用户&#xff0c;经常会遇到Win10提示找不到指定文件。在此错误后面有时还会出现错误代码&#xff1a;0x80070002&#xff0c;但是&#xff0c;故障类型或代码在不同的操作系统规范上是不…
阅读更多...
史上最全PMP学习资料、项目管理资料、备考经验包，3A一次通过

史上最全PMP学习资料、项目管理资料、备考经验包，3A一次通过

你是否也有过类似的经历&#xff1f; 为了获取备考资料&#xff0c;有的同学在论坛、知乎或者相关垂直类网站下载了很多的资料&#xff0c;这些资料大部分是机构进行获客引流的资料&#xff0c;没有真正的干货。 经常会看到10G、20G的资料包&#xff0c;感觉内容很丰富&#xf…
阅读更多...
Spring学习|Spring简介、IOC控制反转理解、IOC创建对象方式

Spring学习|Spring简介、IOC控制反转理解、IOC创建对象方式

Spring Spring:春天------>给软件行业带来了春天! 2002&#xff0c;首次推出了Spring框架的雏形: interface21框架! Spring框架即以interface21框架为基础,经过重新设计,并不断丰富其内涵,于2004年3月24日发布了1.0正式版。 RodJohnson&#xff0c;Spring Framework创始人&…
阅读更多...
关于某次授权的大型内网渗透测试

关于某次授权的大型内网渗透测试

背景&#xff1a; 接到朋友邀请&#xff0c;要进行一个授权站点的渗透&#xff0c;但是进去实际环境才发现是多域控主机。也学习了很多后渗透手法&#xff0c;比较受益匪浅。 前期渗透&#xff1a; 打点&#xff1a;&#xff08;任意文件上传&#xff09; 直接发现头像处任…
阅读更多...
目录与文件系统

目录与文件系统

无论在哪个计算机系统中&#xff0c;文件系统结构都应该是一样的一层或者几层的话太多太乱不适用用目录实现一个树状结构&#xff0c;划分后层次清晰如果把目录下所有的文件的FCB都存取&#xff0c;然后对比没必要太麻烦了 所以数据盘块集合中存放目录下文件字符串和对应的编号…
阅读更多...
Rocky(Centos)安装中文字体（防止中文乱码）

Rocky(Centos)安装中文字体（防止中文乱码）

1、查看字体列表 运行下列命令 fc-list 若出现&#xff0c;下面截图&#xff0c;则需要安装字体管理软件 安装字体库&#xff0c;运行&#xff1a; yum -y install fontconfig 当看到下图的提示信息时说明已安装成功&#xff1a; 二、添加中文字体 1&#xff09;window…
阅读更多...
文件夹怎么安全加密？文件夹加密软件怎么样？

文件夹怎么安全加密？文件夹加密软件怎么样？

我们在使用电脑的过程中&#xff0c;习惯用文件夹来管理电脑数据&#xff0c;为了文件夹数据安全&#xff0c;我们需要使用加密的方式来进行保护。那么&#xff0c;文件夹该怎么安全加密呢&#xff1f;下面我们就来了解一下。 文件夹加密软件安全吗&#xff1f; 文件夹加密软…
阅读更多...
功率放大器主要作用是什么呢

功率放大器主要作用是什么呢

功率放大器是一种电子设备&#xff0c;主要作用是将输入信号的功率增加到更高的水平&#xff0c;以便能够驱动高功率负载。在许多应用中&#xff0c;信号源产生的信号往往具有较低的功率&#xff0c;无法直接满足一些要求较高的设备或系统的需求。而功率放大器则可以增强信号的…
阅读更多...
当面试被问到 Java 内存模型，不妨反问面试官：您问得是 Java Memory Model 呢？还是 JVM 运行时数据区？

当面试被问到 Java 内存模型，不妨反问面试官：您问得是 Java Memory Model 呢？还是 JVM 运行时数据区？

目录 1. JVM 运行时数据区 2. Java 内存模型 最近在牛客上看到这样一个帖子&#xff0c;大概就是在面试中呢&#xff0c;被面试官问到了 Java 内存模型&#xff0c;面试的这位小伙呢&#xff0c;也是掌握了 JVM 内存布局的相关知识&#xff0c;但是不知道面试官问的 Java 内存…
阅读更多...
行测图形推理规律（一）元素组成

行测图形推理规律（一）元素组成

题库&#xff1a;粉笔网题库 (fenbi.com) 不知道和测评的行测题库是不是一样的&#xff0c;但是总结的规律应该是一样的。 规律并不唯一&#xff0c;题库的答案也只是参考答案&#xff0c;切勿当杠精&#xff0c;你觉得你的规律更合适就别管。本人所归纳的规律仅代表本人想法…
阅读更多...
淘宝数据库，主键如何设计的？

淘宝数据库，主键如何设计的？

聊一个实际问题&#xff1a;淘宝的数据库&#xff0c;主键是如何设计的&#xff1f; 某些错的离谱的答案还在网上年复一年的流传着&#xff0c;甚至还成为了所谓的 MySQL 军规。其中&#xff0c;一个最明显的错误就是关于MySQL 的主键设计。 大部分人的回答如此自信&#xff…
阅读更多...
uni-app点击复制指定内容（点击复制）

uni-app点击复制指定内容（点击复制）

官方api uni.setClipboardData(OBJECT) uni.setClipboardData({data: 要被复制的内容,success: function () {console.log(success);} });
阅读更多...
推荐文章
最新文章

Copyright @ 2022~2023