在高并发场景下，多个线程争抢同一把分布式锁导致 Redis CPU 飙升，这是典型的“热点 Key” + “自旋重试（Spin）风暴”问题。 大量线程不断发起 或 Lua 脚本请求，导致 Redis 的单线程事件循环被打满，CPU 飙升，甚至拖垮整个 Redis 节点。 要优化这个问题，我们需要从客户端控制、锁机制设计、业务架构三个维度来进行改造。以下是循序渐进的优化方案： --- 一、 客户端与锁机制优化（见效最快，首选） 1. 将“自旋轮询”改为“发布订阅（Pub/Sub）”机制 如果是你自己手写的 这种自旋锁，请立即放弃。 优化方案： 使用 Redisson 客户端。 原理： Redisson 的分布式锁在获取锁失败时，不会疯狂轮询，而是会订阅该锁的 Redis Channel，然后线程进入阻塞状态。当持有锁的线程释放锁时，会往该 Channel 发布一条消息，唤醒等待的线程再去抢锁。 效果： 极大地减少了对 Redis 的无效请求，直接干掉 CPU 飙升的根源。 2. 引入“本地锁（JVM 锁）”进行两级拦截（极度推荐） 虽然用了 Redisson，但如果有 10000 ...
播面