分布式锁
在并发场景下，为保证临界区资源的数据一致性，这时需要使用锁，让混乱的并发访问有序化
本地：多进程间通过共享进程资源，使用本地锁
分布式：分布式锁
分布式锁应当具备如下几项核心性质：
- 独占性：对于同一把锁，在同一时刻只能被一个取锁方占有，这是作为“锁”工具最基础的一项性质
- 健壮性：即不能产生死锁（dead lock）. 假如某个占有锁的使用方因为宕机而无法主动执行解锁动作，锁也应该能够被正常传承下去，被其他使用方所延续使用
- 对称性：加锁和解锁的使用方必须为同一身份. 不允许非法释放他人持有的分布式锁
- 高可用：当提供分布式锁服务的基础组件中存在少量节点发生故障时，不应该影响到分布式锁服务的稳定性
阻塞/唤醒 （适合并发竞争严重）
- 优点: 精准打击，不浪费CPU时间片。
- 劣势：需要挂起协程，进行上下文切换，操作较重
自旋+CAS （适合并发强度低）
- 优点：无需阻塞协程，短期来看操作较轻
- 劣势：长期来看，浪费CPU时间片
分类：
主动轮询
适用于 并发竞争较低的场景
redis 中使用 SETNX 加锁
使用lua脚本 自定义 组装同一个redis节点下的形成操作具备原子性的事务
使用过期机制，避免死锁
一锁多持问题
- 过期机制带来了新的问题：若实际需要处理时长大于过期时间，这时，事务还未完成，锁就释放了。
- redis使用 的是AP（可用性+分区容错性）->数据弱一致性。为保证服务的可用性和吞吐量，redis在进行数据的主从同步时，采用的时异步执行。若master挂了，数据也没同步到从结点，某个follower成为了master的情形。
使用redis红锁（redis distribution lock）解决
监听回调
适用于并发竞争激烈
etcd
zk
ref：