后端 - 求助，我不确定自己是否正确理解了数据库的锁机制？

Question

求后端前辈帮忙看一下我绘制的时序图中，我对数据库锁的理解是否正确？？？

今天看见一篇讲解 “先删除缓存还是先更新数据库” 的文章看不懂，

我主要是没搞懂“数据库的‘锁’机制”在“并发删除缓存+更新数据库”这个问题中，究竟是怎么运作的？？

因为我在学习mysql时，了解到进行更新操作时，会加上互斥锁，所以理论上更新和查询操作必定是串行的，但按照这篇文章的描述，似乎出现了“数据库更新操作”与“数据库查询操作”同时发生的情况？？？？

我绘制了如下的并发时序图，希望大家判断一下我对于数据库锁的的理解是否正确？？？？

以下是原文链接，请各位大佬直接跳去阅读“「先删缓存，再更新数据库」”这段描述：
https://mp.weixin.qq.com/s?__biz=MzU1NTA0NTEwMg==&mid=2247484...

我比较希望知道我绘制的详细版时序图是不是正确理解了数据库中的 “锁” 对于 “先删除缓存还是先更新数据库” 这个问题产生的影响。

Answer 1

你的问题的是什么，先删除缓存 还没有更新数据库之前，其他请求线程查询到了缓存为空就会去查数据库更新到缓存里面去，这个理解没问题，查询数据库跟锁没有关系吧

Answer 2

似乎出现了“数据库更新操作”与“数据库查询操作”同时发生的情况

mysql的读默认是非锁定读，也叫快照读，就是不加锁的，所以尽管当一条数据在更新的时候加了排他锁，但是读操作是不需要加锁的，所以读操作和更新操作可以同时进行，了解下mysql的MVCC机制。而当你使用select ... for update进行查询时，这时候就会加上排他锁，其他线程需要等待锁释放才能更新该数据

Answer 3

首先，让我们了解一下数据库的锁机制。在数据库中，锁是用于控制并发访问的一种机制。当多个事务试图同时访问同一数据时，数据库系统会使用锁来确保数据的完整性和一致性。根据锁的范围和粒度，锁可以分为多种类型，如行锁、表锁等。行锁允许对单个行进行加锁，而表锁则对整个表进行加锁。

在MySQL中，InnoDB存储引擎支持行级锁和表级锁。当执行更新操作时，InnoDB会为被更新的行加上行锁，以确保在事务提交之前其他事务不能修改这些行。然而，需要注意的是，虽然行锁可以提高并发性能，但在某些情况下，如死锁或锁竞争较激烈时，仍然可能影响性能。

现在，让我们来讨论“先删除缓存还是先更新数据库”的问题。在这个问题中，主要的挑战在于确保缓存和数据库之间的数据一致性。如果先删除缓存，然后更新数据库，那么在缓存被重建之前，查询操作可能会从数据库中获取到旧的数据。相反，如果先更新数据库，然后删除缓存，那么在缓存被删除和新的查询请求到达缓存之前，查询操作可能会从数据库中获取到最新的数据，但此时缓存中仍然保存着旧的数据。

为了避免这种情况，可以采用以下策略之一：

1. 延迟双删：首先更新数据库，然后删除缓存，并在一段时间后再次删除缓存。这样做可以确保在缓存重建之前，查询操作能够获取到最新的数据。
2. 先更新数据库，再删除缓存：与延迟双删类似，但只在更新数据库后删除缓存。这种方法可能导致在缓存重建之前，查询操作从数据库中获取到最新的数据，但缓存中仍然保存着旧的数据。然而，这通常被认为是一个可接受的风险，因为随着时间的推移，缓存中的数据会逐渐被新的数据替代。
3. 使用分布式锁：在更新数据库和删除缓存之间引入一个分布式锁。当一个操作获得锁时，其他操作必须等待该操作完成。这样可以确保在同一时间只有一个操作能够更新数据库和删除缓存，从而避免数据不一致的问题。

至于你绘制的时序图，由于你没有提供具体的时序图，我无法直接判断你对于数据库锁的理解是否正确。然而，你可以根据上述讨论和策略来检查你的时序图是否正确地反映了数据库锁对于“先删除缓存还是先更新数据库”这个问题的影响。