转自： https://blog.csdn.net/u011277123/article/details/89539391
【原创】 沙茶敏碎碎念 2019-04-24 21:41:53
在之前我们简单地介绍了分布式架构，今天我们来聊一聊分布式一个常用的组建，分布式锁。相信大家都遇到过这样的业务场景，我们有一个定时任务需要定时执行，但是这个任务又不是同一段时间执行幂等的，所以我们只能让一台机器一个线程来执行
大家都知道，如果我们一台机器上多个不同线程抢占同一个资源，并且如果多次执行会有异常，我们称之为非线程安全。一般，我们为了解决这种问题，通常使用锁来解决，像java语言，我们可以使用synchronized。如果是同一台机器里面不同的java实例，我们可以使用系统的文件读写锁来解决，如果再扩展到不同的机器呢？我们通常用分布式锁来解决。
分布式锁的实现有很多种，常见的有redis，zookeeper,谷歌的chubby等，今天我们选择我们最常使用的redis，简单介绍一下。相信大家这里已经想到了解决方案，那就是每次执行任务的时候，先查询redis里面是否已经有锁的key，如果没有就写入，然后就开始执行任务。
这个看起来很对，不过存在什么问题呢，例如进程A跟进程B同时查询Redis，他们都发现Redis中没有对应的值，然后都开始写入，由于不是带版本读写，两个人都写成功了，都获得了锁。还好，Redis给我们提供原子写入的操作，setnx(SET if Not Exists， 一个命令我们最好把全称也了解一下，有助于我们记住这个命令)。
如果你以为只要这样就完成一个分布式锁，那就太天真了，我们不妨考虑一些极端情况，例如某个线程取到了锁，但是很不幸，这个机器死机了，那么这个锁没有被释放，这个任务永远就不会有人执行了。所以一种比较好的解决方案是，申请锁的时候，预估一个程序的执行时间，然后给锁设置一个超时时间，如果超过这个时间其他人也能取到这个锁。但这又引发另外一个问题，有时候负载很高，任务执行得很慢，结果过了超时时间任务还没执行完，这个时候又起了另外一个任务来执行。
架构设计的魅力正是如此，当你解决一个问题的时候，总会引发一些新的问题，需要逐步攻破逐个解决。这种方法，我们一般可以在抢占到锁之后，就开一个守护线程，定时去redis哪里询问，是不是还是由我抢占着当前的锁，还有多久就要过期，如果发现要过期了，就赶紧续期。
好了，看到这里，相信你已经学会了如何用Redis实现一个分布式锁服务了，然而，事情并没有结束，因为还有一些极限情况，例如Redis实例突然挂掉，如果你的Redis是主从同步的，刚好发生在挂掉瞬间，也有可能造成锁失效。为了解决这些问题，还有很多有意思的框架，不过他们也会带来新的问题，下次，我们将介绍另外一个分布式锁框架，Chubby,欢迎大家关注我，一起学习一起探讨。