绝命一问：秒杀Redis分段锁，如何设计？

尼恩说在前面

秒杀，是一个非常常见的高并发面试题，很多面试官也非常熟悉，上来就让面试者设计一个秒杀系统。

在40岁老架构师 尼恩的读者交流群(50+)中，最近有小伙伴拿到了一线互联网企业如得物、阿里、滴滴、极兔、有赞、shein 希音、百度、网易的面试资格，遇到很多很重要的面试题：

分布式锁，如何实现高并发？

小伙伴 没有回答好，导致面试挂了。

小伙伴面试完了之后，来求助尼恩：如何才能回答得很漂亮，才能 让面试官刮目相看、口水直流。所以，尼恩给大家做一下系统化、体系化的梳理，使得大家内力猛增，可以充分展示一下大家雄厚的 “技术肌肉”，让面试官爱到 “不能自已、口水直流”，然后实现 ”offer自由”。

当然，这道面试题，以及参考答案，也会收入咱们的 《尼恩Java面试宝典》V173版本PDF集群，供后面的小伙伴参考，提升大家的 3高 架构、设计、开发水平。

注：本文以 PDF 持续更新，最新尼恩 架构笔记、面试题 的PDF文件，请到文末公号【技术自由圈】取。

问题场景：热点库存扣减问题

秒杀场景，有一个难度的问题：热点库存扣减问题。

• 既要保证不发生超卖

• 又要保证高并发

如何解决这个高难度的问题呢？ 答案就是使用redis 分段锁。

首先说说什么是分布式锁，普通分布式锁的不足

比如说在一个分布式系统中，存在客户端多个用户，同时通过多个业务微服务，发起一个数据修改。

如果没有分布式锁机制保证，在那多台机器上的多个服务可能进行并发修改操作，导致数据修改的不一致，出现脏读脏写，这就会造成问题。

而分布式锁机制就是为了解决类似这类问题，保证多个服务之间互斥的访问共享资源，如果一个服务抢占了分布式锁，其他服务没获取到锁，就不进行后续操作。

上图中，客户端1的服务抢占了分布式锁，可以去扣减库存。

其他服务没获取到分布式锁，就不进行后续操作。

什么是分布式锁？

• 当在分布式模型下，数据只有一份（或有限制），此时需要利用锁的技术控制某一时刻修改数据的进程数。
• 用一个状态值表示锁，对锁的占用和释放通过状态值来标识。

分布式锁的条件：

• 互斥性。在任意时刻，只有一个客户端能持有锁。
• 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。
• 具有容错性。只要大部分的 Redis 节点正常运行，客户端就可以加锁和解锁。
• 解铃还须系铃人。加锁和解锁必须是同一个客户端，客户端自己不能把别人加的锁给解了。

普通的分布式锁的如何实现？

分布式锁的实现由很多种，文件锁、数据库、redis等等，比较多；分布式锁常见的多种实现方式：

1. 数据库悲观锁、
2. 数据库乐观锁；
3. 基于Redis的分布式锁；
4. 基于ZooKeeper的分布式锁。

在实践中，还是redis做分布式锁性能会高一些

尼恩提示：基于ZooKeeper的分布式锁，请参见尼恩面试宝典 专题15.

尼恩提示：基于redis 的分布式锁，请参见尼恩面试宝典 专题15.