热点锁的本质不是“锁慢”，而是：
大量请求同时争抢同一份状态
典型场景：
单账户余额
单库存
单交易对撮合
全局 ID / 全局配置
👉 所以：只要“共享状态不变”，锁永远存在
把 “一把锁” 拆成 N 把互不相关的锁
架构手段
状态拆分（State Sharding）——最根本
按 key / 用户 / 账户 / 交易对 分片
每个分片有独立状态 & 执行单元串行化执行（Single Writer Principle）
与其并发抢锁，不如明确只允许一个写者
架构方式
- Actor 模型
- 单线程事件循环
- 消息队列串行消费
从“共享内存” → “消息驱动”
锁出现，是因为多个线程同时读写共享内存
架构转化1
2
3共享变量 + 锁
↓
消息 + 本地状态读写分离 + 只写一次
写是热点，读不是
架构手段
- 写路径极短、极少
- 读全部走缓存 / 副本
- 把“同步竞争”变成“异步最终一致”
不要求所有操作立即完成
架构方案
- 下单：成功 ≠ 已结算
- 先返回accepted
- 后台异步处理
总结：
热点锁的根因是共享状态被高并发访问，
所以单纯优化锁实现解决不了。
我的思路是从架构上消除竞争：
- 第一，状态按业务维度拆分
- 第二，核心写路径采用单写者模型
- 第三，读写分离，异步化非核心流程
在交易系统中，比如撮合和资金，都是通过串行化和事件驱动，让锁本身不再存在