企业官网建设流程全解析

Redis分布式锁进阶第二十六篇：公平锁&读写锁深度实战 + 细分场景精准选型 + 规避锁饥饿&并发塌陷优化方案

一、本篇前置衔接

第二十五篇我们彻底吃透了联锁（MultiLock），解决了多资源交叉死锁、加锁无序、资源残留难题。截至目前，我们已经掌握：可重入锁、分片锁、双锁、联锁。但绝大多数企业开发只会用默认的非公平可重入锁，忽略了公平锁、读写锁两大高频特殊锁。流量倾斜、请求饥饿、读阻塞写、并发塌陷全部来源于锁类型选错。本篇第二十六篇，专项拆解公平锁与读写锁底层逻辑、生产坑点、选型标准，把容易被忽略的锁类型讲透，补齐分布式锁场景细分最后一块拼图。

二、核心痛点：清一色使用默认非公平锁，本身就是架构隐患

绝大多数业务开发，无论什么场景，无脑使用Redisson默认非公平锁。非公平锁吞吐量高、抢占效率高，适合绝大多数秒杀、下单高抢占场景。但如果滥用在排队业务、长耗时查询、批量任务中，会出现严重隐形问题：新请求持续插队、老请求长期等待产生锁饥饿；大量读请求互相阻塞、查询接口RT持续走高；批量任务抢占锁混乱、执行顺序不可控。锁类型不分场景乱用，是很多系统并发塌陷、莫名卡顿的根本原因。

三、公平锁深度拆解：解决排队乱序、线程饥饿、任务插队

1、公平锁底层原理：公平锁维护一条FIFO排队队列，严格按照请求到达顺序依次加锁，不允许插队、不允许抢占。底层依靠Redis List结构实现排队逻辑，每一个抢锁请求进入队列排序，前一个释放、后一个接续执行，保证绝对有序。

2、公平锁生产适用场景：夜间批量对账、定时结算、顺序扣款；用户排队审核、流程审批、状态流转；需要严格保证执行时序、不能插队、不能乱序的业务链路。这类业务不追求极致吞吐，追求顺序稳定、执行可控。

3、公平锁致命短板（严禁乱用）：公平锁存在队列维护开销，吞吐量远低于非公平锁；大促高并发场景下排队链过长，接口RT持续爬升，极易造成线程池堆积。秒杀、下单、爆款扣减禁止使用公平锁。

四、读写锁深度拆解：解决读多写少、查询拥堵、读写互斥难题

1、读写锁底层机制：Redisson读写锁分为读锁、写锁。读锁与读锁共享不互斥，大量查询并行通行；读锁与写锁互斥、写锁与写锁互斥。做到查询无限并行，修改串行互斥，专门适配读多写少业务。

2、读写锁黄金适用场景：商品详情、活动配置、字典缓存高频查询；店铺信息、公告配置、静态资源低频次修改；本地缓存+分布式缓存联动更新场景。读请求吞吐量可提升5~10倍，极大降低锁竞争压力。

3、读写锁线上高危坑点：大量读锁堆积会阻塞写锁，造成写饥饿。例如商品详情百万在读请求，后台修改商品价格一直排队阻塞，迟迟无法写入；读写锁不可嵌套重入，容易出现持锁合法但是二次加锁失败；读写锁禁止搭配异步线程，极易造成读锁残留无法释放。

五、线上高频疑难：锁饥饿现象成因与根治方案

第一类：非公平锁造成老请求饥饿。高并发下新请求不断插队，老旧排队请求一直抢不到锁，超时失败率持续攀升。根治：定时任务、有序流程强制改用公平锁，打散抢占无序性。

第二类：读写锁造成写请求饥饿。海量读请求压住写请求，后台配置修改卡死。根治：添加写锁优先级机制、低峰期执行配置修改、短暂限流读请求放行写入。

第三类：分片锁局部流量倾斜。某一分片持续被热点请求抢占，普通请求长期排队。根治：动态调整分片权重、异常分片临时熔断隔离。

六、六大锁类型终极选型对照表（生产直接抄）

1、可重入非公平锁：通用首选、下单、扣减、秒杀、绝大多数高并发业务；

2、公平锁：定时任务、对账、审核、有序流程、禁止插队业务；

3、读写锁：商品查询、配置读取、静态资源、读多写少场景；

4、联锁MultiLock：多资源联动、库存+优惠券+资产复合业务；

5、红锁RedLock：资金扣款、财务结算、强一致核心链路；

6、虚拟分片锁：爆款秒杀、超大流量、单Key热点承压场景。

七、代码评审硬性红线，锁类型严禁乱用

禁止高并发秒杀使用公平锁，队列堆积拖垮RT；禁止写频繁业务使用读写锁，放大写入阻塞风险；禁止复杂多资源业务使用单锁嵌套，必须使用联锁；禁止资金链路使用普通单节点锁，必须红锁兜底；禁止动态随意切换锁类型，线上锁类型变更必须低峰灰度发布。

八、本篇小结

锁没有好坏，选错必翻车。第二十六篇补齐公平锁、读写锁两大冷门高阶锁，完善全品类锁认知。前面二十五篇解决稳定性、性能、故障、多资源问题，本篇补齐业务细分选型，让每一类业务都有专属锁适配，不浪费性能、不预埋隐患。下一篇衔接高阶：过期时间、leaseTime底层原罪深度剖析，打通最后底层盲区。