分布式锁的坑
高并发场景下的问题
以下问题不是说在并发不高的场景下不容易出现,只是在高并发场景下出现的概率更高些而已。
性能问题来自于以下两方面:
**①获取锁的时间上。**如果 Redlock 运用在高并发的场景下,存在 N 个 Master 节点,一个一个去请求,耗时会比较长,从而影响性能。
这个好解决,通过上面描述不难发现,从多个节点获取锁的操作并不是一个同步操作,可以是异步操作,这样可以多个节点同时获取。
即使是并行处理的,还是得预估好获取锁的时间,保证锁的 TTL>获取锁的时间+任务处理时间。
**②被加锁的资源太大。**加锁的方案本身就是会为了正确性而牺牲并发的,牺牲和资源大小成正比,这个时候可以考虑对资源做拆分。
拆分的方式有如下两种:
**①从业务上将锁住的资源拆分成多段,每段分开加锁。**比如,我要对一个商户做若干个操作,操作前要锁住这个商户,这时我可以将若干个操作拆成多个独立的步骤分开加锁,提高并发。
**②用分桶的思想,将一个资源拆分成多个桶,一个加锁失败立即尝试下一个。**比如批量任务处理的场景,要处理 200w 个商户的任务,为了提高处理速度,用多个线程,每个线程取 100 个商户处理,就得给这 100 个商户加锁。
如果不加处理,很难保证同一时刻两个线程加锁的商户没有重叠,这时可以按一个维度。
比如某个标签,对商户进行分桶,然后一个任务处理一个分桶,处理完这个分桶再处理下一个分桶,减少竞争。
**重试的问题:**无论是简单实现还是 Redlock 实现,都会有重试的逻辑。
如果直接按上面的算法实现,是会存在多个 Client 几乎在同一时刻获取同一个锁,然后每个 Client 都锁住了部分节点,但是没有一个 Client 获取大多数节点的情况。
解决的方案也很常见,在重试的时候让多个节点错开,错开的方式就是在重试时间中加一个随机时间。这样并不能根治这个问题,但是可以有效缓解问题,亲试有效。
节点宕机
对于单 Master 节点且没有做持久化的场景,宕机就挂了,这个就必须在实现上支持重复操作,自己做好幂等。对于多 Master 的场景,比如 Redlock,我们来看这样一个场景:
-
假设有 5 个 Redis 的节点:A、B、C、D、E,没有做持久化。
-
Client1 从