redis分布式锁原理面试题,java面试老是面试不上

前言

随着互联网的发展，各种高同时、大容量处理的场景在增加。 为了提供高可用性和可扩展性的系统，经常使用分布式系统，避免了单点故障和普通计算机的cpu、内存等瓶颈。

但是，分布式系统带来了数据一致性问题，如用户抢购秒杀商品的多台机器联合运行，出现超卖。 有些同学容易混淆分布式锁定和线程安全。 线程安全是指线程之间的协作。 当多个进程之间的协作需要分布式锁定时，本文总结了几种常见的分布式锁定。

数据库

悲观锁定-事务

例如，在用户抢购商品的情况下，多个设备收到抢购的请求，可以将多个数据库操作合并为一个事务处理，如获取库存、判断有无商品、用户支付、扣除库存等。 以这种方式，如果一台设备链接到数据库并请求进行商品抢购事务处理，则其他设备在该机器完成请求之前无法操作数据库。 在实际的APP应用方案中，库存和交易往往是两个独立的系统，这种情况下的事务是分布式事务，需要两个阶段、三个阶段的提交。

优点：是一种比较安全的实现方法。

缺点：高合并的场景下无法忍受费用。 容易发生数据库死锁等。

乐观锁定-基于版本号

乐观锁通常用于分布式系统对数据库中的特定表执行update操作。 考虑到在线选择座位的情况，用户a和b同时选择某部电影的座位，然后去将座位状态设定为已售。

假设这样的执行序列。

1、用户a判断该座位处于未销售状态；

2、用户b判断该座位处于未销售状态；

3、用户a执行更新的座位已经销售完毕

4、用户b已售出更新座位。

这可能会导致同一座位销售两次。 解决方案是将版本号字段添加到此数据库表中。 在执行操作之前读取当前数据库表的版本号，并在执行update语句时将版本号放入where语句中。 如果记录已更新࿰