在电商小程序的秒杀业务中，瞬时高并发请求集中涌入，库存数量有限，多个请求同时读取库存并尝试扣减，极易出现超卖现象。超卖的本质是并发环境下的共享资源竞争问题：多个执行流同时访问同一份库存数据，在缺乏有效互斥机制的情况下，各自基于旧值完成计算并写入，最终导致实际扣减量超过可用库存。
解决这一问题的核心手段是引入分布式锁。分布式锁的作用是在分布式部署环境下，保证同一时刻只有一个执行流能够进入临界区操作共享资源。对于秒杀场景而言，一把合格的分布式锁需要同时满足互斥性、防死锁、可重入、高可用和高性能这五项基本要求。
目前主流的分布式锁实现方式主要有三类：基于数据库的分布式锁、基于缓存中间件的分布式锁、基于协调服务的分布式锁。下面从原理、实现细节、优缺点和适用场景四个维度进行对比分析。
基于数据库的分布式锁通常有两种思路：悲观锁和乐观锁。
悲观锁依赖数据库原生的行级锁机制。在扣减库存前，通过SELECT ... FOR UPDATE语句锁定目标库存行，其他事务在锁释放前无法对该行进行修改，从而保证同一时刻只有一个事务能够操作库存。锁的释放依赖事务的提交或回滚。
乐观锁则不依赖数据库锁，而是在库存表中增加一个版本号字段。每次读取库存时同时读取版本号，扣减时在更新语句的条件中带上版本号判断，即UPDATE stock SET count = count - 1, version = version + 1 WHERE id = ? AND version = ?。如果更新影响行数为零，说明版本号已被其他事务修改，当前操作失败，需要重试。
此外，还可以通过一张专门的锁表来实现互斥：利用唯一索引约束，插入一条记录代表获取锁，删除记录代表释放锁。
数据库方案的最大优势是实现简单、易于理解，不需要引入额外的中间件，对于并发量不高的系统来说成本最低。乐观锁方案在冲突较少的场景下性能表现尚可，且不会产生死锁问题。
但其局限性也十分明显。悲观锁在高并发下会导致大量事务阻塞等待，数据库连接资源被迅速耗尽，吞吐量急剧下降，完全无法支撑秒杀级别的流量。乐观锁在冲突激烈时重试率极高，大量更新操作失败后反复重试，反而给数据库带来更大压力。锁表方案则存在单点故障、非阻塞、不可重入等问题，且锁的释放依赖应用主动删除，一旦服务宕机可能导致死锁。
总体而言，数据库分布式锁适用于并发量较低、对性能要求不高的业务场景，不适合作为秒杀系统的核心锁方案。
基于缓存中间件的分布式锁是目前秒杀场景中应用最广泛的方案。其核心思路是利用缓存系统原子性的SET命令，在缓存中设置一个带有唯一标识和过期时间的键值对来表示锁。
获取锁时执行SET lock_key unique_value NX PX expire_time，其中NX保证只有键不存在时才能设置成功，PX设置过期时间防止死锁，unique_value是一个全局唯一标识，用于在释放锁时验证锁的持有者身份，避免误删其他线程持有的锁。
释放锁时不能直接删除键，而应通过Lua脚本保证"判断锁归属"和"删除锁"两个操作的原子性：先比对键的值是否等于当前线程的唯一标识，相等则删除，否则不做操作。
在主从架构的缓存系统中，由于主从复制存在延迟，主节点加锁成功后尚未同步到从节点时主节点宕机，从节点提升为主节点后锁信息丢失，可能导致两个客户端同时持有锁。为解决这一问题，业界提出了多节点分布式锁算法，通过向多个独立节点依次申请锁，超过半数节点加锁成功且总耗时小于锁有效期时才算获取成功，从而降低单点故障带来的风险。
缓存方案的核心优势是性能极高，读写操作均在内存中完成，延迟在毫秒级别，能够轻松支撑秒杀场景的高并发请求。过期时间机制天然避免了死锁问题，实现复杂度适中。
但该方案也存在一些需要关注的问题。首先是锁续期问题：如果业务执行时间超过锁的过期时间，锁会自动释放，其他线程获取锁后进入临界区，导致并发问题。解决方案是引入看门狗机制，在锁即将过期时自动续期。其次是主从架构下的锁丢失风险，虽然多节点算法可以缓解，但也增加了实现复杂度和运维成本，且在极端网络分区场景下仍存在理论上的不安全可能。此外，缓存方案本身不支持可重入，需要通过在值中记录持有者信息和重入次数来实现。
总体而言，缓存分布式锁在性能、可用性和实现成本之间取得了较好的平衡，是秒杀场景的首选方案。对于绝大多数电商小程序而言，单节点缓存锁配合合理的过期时间和Lua原子释放已经足够。
基于协调服务的分布式锁利用其临时顺序节点和Watcher监听机制来实现。临时节点的生命周期与客户端会话绑定，会话断开后节点自动删除，从根本上避免了死锁。
获取锁的流程如下：客户端在指定锁路径下创建一个临时顺序节点，然后获取该路径下所有子节点，判断自己创建的节点是否是序号最小的。如果是，则获取锁成功；如果不是，则监听前一个节点的删除事件，当前一个节点被删除（锁被释放）时收到通知，再次尝试获取锁。
释放锁时只需删除自己创建的临时节点即可，会话异常断开时节点也会自动删除。
协调服务方案的最大优势是强一致性和高可靠性。基于一致性协议保证数据在集群中的强一致，不存在缓存方案中主从复制延迟导致的锁丢失问题。临时节点机制天然解决了死锁问题，Watcher机制实现了锁的公平性——按照节点创建顺序依次获取锁，避免了惊群效应。可重入性也可以通过在节点中记录持有者信息来实现。
但其缺点同样突出。协调服务的写入性能远低于缓存系统，每次创建和删除节点都需要经过一致性协议的多轮投票，延迟较高，吞吐量有限。在秒杀这种瞬时高并发场景下，大量客户端同时创建节点和监听，可能给协调服务带来巨大压力，甚至触发集群限流。此外，协调服务的部署和运维复杂度较高，需要维护一个至少三节点的集群，对于中小团队来说成本不低。
总体而言，协调服务分布式锁适用于对一致性要求极高、并发量相对可控的场景，如分布式任务调度、配置中心选主等，不太适合作为秒杀场景的核心锁。
| 对比维度 | 数据库锁 | 缓存锁 | 协调服务锁 |
|---|---|---|---|
| 性能 | 低 | 高 | 中 |
| 一致性 | 强（悲观锁） | 最终一致 | 强 |
| 可靠性 | 依赖数据库 | 依赖过期时间和多节点算法 | 高（临时节点） |
| 实现复杂度 | 低 | 中 | 中高 |
| 运维成本 | 低（已有数据库） | 中 | 高 |
| 死锁风险 | 悲观锁可能 | 过期时间可避免 | 无（临时节点） |
| 公平性 | 不保证 | 不保证 | 保证 |
| 适用并发量 | 低 | 高 | 中 |
对于电商小程序的秒杀场景，选型的核心考量是性能和可靠性的平衡。
如果秒杀量级在每秒数百请求以内，且团队不想引入额外中间件，数据库乐观锁配合合理的重试策略可以作为入门方案，但需要做好数据库连接池的监控和限流。
如果秒杀量级在每秒数千到数万请求，缓存分布式锁是最佳选择。单节点缓存锁配合Lua原子释放、看门狗续期和限流降级，已经能够满足绝大多数业务需求。对于金融级别的高可靠性要求，可以考虑多节点缓存锁方案，但需要权衡实现复杂度。
协调服务锁在秒杀场景中一般不作为核心锁使用，更适合作为辅助手段，例如用于秒杀活动的全局开关控制、库存预热的选主等对一致性要求高但并发量不大的场景。
此外需要强调的是，分布式锁只是秒杀系统的一环，不能替代其他防护手段。完整的秒杀架构还应包括前端限流、页面静态化、库存预热、消息队列异步下单、服务降级等多层防护，将流量层层过滤，最终到达数据库的请求已经非常有限，分布式锁才能在可控的并发下发挥最大效用。
三种分布式锁实现方式各有优劣：数据库锁简单但性能不足，缓存锁性能优异但一致性存在理论短板，协调服务锁一致性强但性能和成本不占优。在电商小程序秒杀场景下，缓存分布式锁凭借其高性能和适中的实现成本，成为目前的主流选择。但无论选择哪种方案，都需要结合业务的实际并发量、一致性要求和团队运维能力综合判断，并配合限流、异步、降级等架构手段，才能构建一个稳定可靠的秒杀系统。
