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

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

redis 2x版本锁：3x版本已移除
redis setnx锁：1.死锁问题，2.哨兵模式会有多个线程同时获取锁，舍弃 3.无法动态控制程序执行时间
redis+lua锁：1.哨兵模式会有多个线程同时获取锁，舍弃
redLock算法锁：1.主观念抛弃了主从集群
redisson锁：是对redis锁加强，需要续约，短时间续约性能消耗比zk高，且文档较少；
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支持的线程池

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