【面试干货】数据库乐观锁,悲观锁的区别,怎么实现
- 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💖点点关注,收藏不迷路💖 |