本文探讨了在高并发环境下使用分布式锁遇到的性能问题，如资源加锁时间过长和资源过大，以及解决方案，如资源拆分和重试策略。还讨论了节点宕机和任务执行时间超过锁的TTL带来的挑战，并提出了相应的解决办法。最后总结了面试中常见的技术问题，如算法、MySQL、Redis和网络知识。
分布式锁的坑
高并发场景下的问题
以下问题不是说在并发不高的场景下不容易出现，只是在高并发场景下出现的概率更高些而已。
性能问题来自于以下两方面：
**①获取锁的时间上。**如果 Redlock 运用在高并发的场景下，存在 N 个 Master 节点，一个一个去请求，耗时会比较长，从而影响性能。
这个好解决，通过上面描述不难发现，从多个节点获取锁的操作并不是一个同步操作，可以是异步操作，这样可以多个节点同时获取。
即使是并行处理的，还是得预估好获取锁的时间，保证锁的 TTL>获取锁的时间+任务处理时间。
**②被加锁的资源太大。**加锁的方案本身就是会为了正确性而牺牲并发的，牺牲和资源大小成正比，这个时候可以考虑对资源做拆分。
拆分的方式有如下两种：
**①从业务上将锁住的资源拆分成多段，每段分开加锁。**比如，我要对一个商户做若干个操作，操作前要锁住这个商户，这时我可以将若干个操作拆成多个独立的步骤分开加锁，提高并发。
**②用分桶的思想，将一个资源拆分成多个桶，一个加锁失败立即尝试下一个。**比如批量任务处理的场景，要处理 200w 个商户的任务，为了提高处理速度，用多个线程，每个线程取 100 个商户处理，就得给这 100 个商户加锁。
如果不加处理，很难保证同一时刻两个线程加锁的商户没有重叠，这时可以按一个维度。
比如某个标签，对商户进行分桶，然后一个任务处理一个分桶，处理完这
最低0.47元/天 解锁文章
250
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
