分布式锁的应用场景
高并发场景下电商下单超卖Bug复现
高并发场景下JVM锁现场压测实战
高并发场景下分布式锁思路分析
高并发秒杀场景下MySQL分布式锁实战
高并发秒杀场景下Redis分布式锁实战
JVM下，分布式锁的终极问题
业务场景
电商下单
10个人抢2部手机
分析原因
因为没有锁就会出现超卖的现象
解决方案：JVM锁
synchronized
lock
集群问题
高可用
分布式的问题分析
分布式解决方案
分布式的问题解决
- mysql 方案
- Redis 思路
- zookeeper 思路
学习思路：file 目录
Mysql方案
MySQL分布式锁分析
mysql自带行级锁,可以考虑使用它的行级锁,可以保证数据的安全,但是不足之处也跟着来了,使用MySql的行级锁,系统的中压力就全部集中在mysql,那mysql就是系统吞吐量的瓶颈了,系统的吞吐量也会收到mysql的限制
看MySQL LOCK代码
MySQL分布式锁性能分析
https://help.aliyun.com/document_detail/150351.html?spm=a2c4g.11174283.6.1675.426d5b832FNSKW
Redis方案
Redis单节点方案
SETNX
格式：setnx key value 将 key 的值设为 value ，当且仅当 key 不存在。
若给定的 key 已经存在，则 SETNX 不做任何动作。
SETNX 是『SET if Not eXists』(如果不存在，则 SET)的简写
Redis分布式锁
获取锁：setnx key value
释放锁：del key
Redis分布式锁：死锁
死锁：解决方案
过期时间问题
Key : Value 10s 过期，引发的问题
防止释放别人的锁：
if(getKey() == 我自己加的值){
del key;
}
Redis锁性能如何提升
Redis 单节点故障
Redis集群方案
Redis 主从问题
Redis红锁方案
它以毫秒为单位获取当前时间。
它尝试在所有N个实例中顺序获取锁，在所有实例中使用相同的密钥名和随机值。在步骤2中，当在每个实例中设置锁时，客户端使用一个超时，该超时与锁自动释放的总时间相比很小，以便获取它。例如，如果自动释放时间为10秒，则超时时间可能在~5-50毫秒范围内。这可以防止客户端在尝试与已关闭的Redis节点通话时长时间处于阻塞状态：如果某个实例不可用，我们应该尽快尝试与下一个实例通话。
客户端通过从当前时间中减去在步骤1中获得的时间戳来计算获取锁所用的时间。如果且仅当客户端能够在大多数实例（至少3个）中获取锁，并且获取锁所用的总时间小于锁有效时间，则认为已获取锁。
如果获得了锁，其有效时间将被视为初始有效时间减去经过的时间，如步骤3中计算的。
如果客户端由于某种原因（无法锁定N/2+1实例或有效期为负）未能获取锁，它将尝试解锁所有实例（即使是它认为无法锁定的实例）。
红锁问题
中间redis挂了，怎么办？
只要保证有三个以上可用就能继续运行，如果需要重启redis则需要等待其他redis中的锁过期
终极问题
1、利用临时节点特性
zookeeper的临时节点有两个特性，一是节点名称不能重复，二是会随着客户端退出而销毁，因此直接将key作为节点名称，能够成功创建的客户端则获取成功，失败的客户端监听成功的节点的删除事件
缺点：所有客户端监听同一个节点，但是同时只有一个节点的事件触发是有效的，造成资源的无效调度
2、利用顺序临时节点特性
zookeeper的顺序临时节点拥有临时节点的特性，同时，在一个父节点下创建创建的子临时顺序节点，会根据节点创建的先后顺序，用一个32位的数字作为后缀，我们可以用key创建一个根节点，然后每次申请锁的时候在其下创建顺序节点，接着获取根节点下所有的顺序节点并排序，获取顺序最小的节点，如果该节点的名称与当前添加的名称相同，则表示能够获取锁，否则监听根节点下面的处于当前节点之前的节点的删除事件，如果监听生效，则回到上一步重新判断顺序，直到获取锁。