【面试干货】数据库乐观锁，悲观锁的区别，怎么实现
- 1、乐观锁，悲观锁的区别
- 2、总结
|
💖The Begin💖点点关注，收藏不迷路💖
|
1、乐观锁，悲观锁的区别
- 悲观锁（Pessimistic Lock）
定义： 每次去拿数据的时候都认为别人会修改，所以每次在拿数据的时候都会上锁，这样别人想拿这个数据就会阻塞挂起直到它拿到锁。
实现： 传统的关系型数据库里边就用到了很多这种锁机制，比如行锁，表锁，读锁，写锁等，都是在做操作之前先上锁。
特点：适用于写操作频繁的场景，但可能会降低并发性能，因为上锁会阻塞其他操作的进行。
示例代码（伪代码）：
-- 悲观锁示例（以行锁为例）
SELECT * FROM table_name WHERE id = 1 FOR UPDATE; -- 对id为1的行加锁
- 乐观锁（Optimistic Lock）
定义： 每次去拿数据的时候都认为别人不会修改数据，所以不会上锁，但是在更新的时候会判断一下在此期间别人有没有去更新这个数据。
实现：版本号机制（如：为数据表增加一个版本号字段，在更新数据时判断版本号是否变化）或者时间戳机制（使用数据的最后更新时间戳，在更新时判断时间戳是否发生变化）是常见的乐观锁实现方式。
特点：适用于多读少写的场景，可以提高系统的整体吞吐量。但如果冲突频繁，上层应用会不断重试，降低性能。
示例代码（伪代码）:
-- 乐观锁示例（以版本号为例）
UPDATE table_name SET column1 = value1, version = version + 1 WHERE id = 1 AND versio
old_version 是之前读取到的版本号，如果更新操作影响的行数为0，则表示在此期间有其他事务已经修改了数据，需要重试。
2、总结
选择：
1、根据实际应用场景选择使用悲观锁还是乐观锁。 如果写操作较少，且希望提高系统吞吐量，可以考虑使用乐观锁；
2、如果写操作频繁，且希望减少数据冲突，可以考虑使用悲观锁。
注意： 在使用乐观锁时，需要合理设置重试次数和重试间隔，避免频繁重试导致性能下降。同时，需要确保在更新数据时能够正确判断数据是否被其他事务修改过。
|
💖The End💖点点关注，收藏不迷路💖
|
