8种分布式锁解决方案推荐

最新推荐文章于 2024-07-14 16:53:45 发布

置顶

{"nickName":"白某"}

最新推荐文章于 2024-07-14 16:53:45 发布

阅读量550

点赞数

分类专栏： redis 文章标签：分布式锁解决方案 redis死锁 redis分布式锁分布式锁 zk分布式锁

本文链接：https://blog.csdn.net/qq_39276448/article/details/104890960

版权

本文探讨了多种分布式锁实现，包括基于Redis的2x版本锁、SetNX锁、Lua脚本锁、RedLock算法及Redisson，以及基于Zookeeper的临时节点锁。在分析各方案的优缺点后，建议在对性能要求较高的场景下使用RedLock，而对可控时间要求较高的场景则推荐Redisson。Zookeeper因支持集群高可用，在某些情况下是更好的选择。在使用Redisson时，需注意版本、超时时间设置和线程池的配置，以避免性能消耗和异常情况。

摘要由CSDN通过智能技术生成

本文会陆续更新；先写下大纲和劣势
博主：只针对JAVA其他语言未知未测；

redis 2x版本锁：3x版本已移除
redis setnx锁：1.死锁问题，2.哨兵模式会有多个线程同时获取锁，舍弃 3.无法动态控制程序执行时间
redis+lua锁：1.哨兵模式会有多个线程同时获取锁，舍弃
redLock算法锁：1.主观念抛弃了主从集群
redisson锁：是对redis锁加强，需要续约，不好把控续约时间，有SpringBoot整合版；
spring-boot-klock-starter：一个开源项目基于redisson锁

以上全是基于redis的锁，redis主从模式下全部不推荐，全部会导致多个线程（进程）同时获取锁；但可以考虑TTL（锁过期时间）>从节点上位时间的方案，但是TTL可能很久，也非常耗性能与时间，所以全部抛弃；

mysql单机实现比较粗暴；集分库表很麻烦，方案不多不推荐

zookeper临时节点锁：目前2020/3/17看来是比较好的方案，性能消耗比redis单机高，需要持续监听节点，还支持集群高可用；

总结：
如果对性能要求较高，redLock，是你的选择，如果可控时间redisson是你的选择（需要保证多数以上成功，且集群必须要高可用）
反之zookeper

注意事项：
1.使用redisson注意版本，一定要测试！！！
2.使用redisson一定要自定义权衡超时时间（默认30s），太短会持续续约消耗性能，太长会阻塞大量线程等待获取锁；在大量线程阻塞等待时锁注意使用redistemplte时，redis超时时间小心超过等待时间导致超时（不合理将会导致大量异常返回超时），那么超时后会不会导致程序混乱，这时候需要认认真真的控制代码（ps：不想烦躁方案：直接锁根方法，并控制代码反应时间）
3.尽量使用redis线程池技术，可间接避免获取超时；使用线程池时，注意redis包版本对应的线程池，以及redission支持的线程池

特别注意：
博主表述不清楚的地方可以指出来，我没办法写出所有的细节考虑（文笔不好）；比如：网络抖动，内存爆满，交换区爆满，丢失等等组合情况，也一般比较少遇到所以不写了。可以提问哟

下面是redisson单机整合版和zk，我已经测试过的了
加入依赖