分布式或微服务架构中的分布式锁应用

1. 分布式锁特征

  在不少分布式或微服务架构产品应用中，有些场景须要加锁处理，要求分布式锁具有以下特性：

一、要求每一个事物都有各自一把锁。

二、锁互斥，无论任什么时候候，只有一个客户端能持有同一个锁。

三、锁具备自动释放特征（超时后会自动释放），确保不会死锁，最终客户端必定会获得锁，就算一个持有锁的客户端宕掉。

四、锁的时效设置。避免单点故障形成死锁，影响其余客户端获取锁。可是也要保证一旦一个客户端持锁，在客户端可用时不会被其余客户端解锁。

五、加锁的事务或者操做尽可能粒度小，减小其余客户端申请锁的等待时间，提升处理效率和并发性。

六、客户端在再也不须要锁或者任务执行完成以后须要主动释放锁，这样其余客户端就不用等到超时时间再去获取这个锁。

七、当一个客户端尝试获取锁时，若是这个锁被其余客户端占用，则当即返回，不作任何业务处理，此目的在于确保同一时刻只有一个客户端在执行特定网元告警同步操做便可。

八、提供分布式锁的中间件，须要具备高可靠、容灾等特性，确保分布式锁稳定性。

2. 分布式锁选型

  分布式锁以往大部分的解决方案是基于数据库来实现的，这种方式业务实现比较复杂，好比须要开发人员自行实现锁超时释放机制，避免死锁问题。那么如何找到一款可以知足各类应用场景的分布式锁组件呢？

2.1 ZooKeeper分布式锁

  ZooKeeper是一个分布式应用程序协调服务，为分布式应用提供一致性服务的组件。ZooKeeper节点结构是一个和文件系统相似的小型的树状的目录结构，同时Zookeeper机制规定：同一个目录下只能有一个惟一的文件名。例如：在ZooKeeper的根目录下，由两个客户端同时建立一个名为/locks/ne_node，则只有一个客户端能够建立成功。所以，能够经过ZooKeeper节点为每一个待告警同步的网元来建立一个锁，例如/locks/10.63.204.101就能够定义为一个锁。ZooKeeper分布式锁架构示意图以下：

 

  另外，ZooKeeper有一种临时类型的节点，临时节点由某个客户端建立，当客户端由于宕机，与ZooKeeper集群断开链接时，则该临时节点会被自动删除，从而避免了死锁问题。

客户端在获取到锁以后，开始执行互斥业务逻辑，执行完成后，显示删除临时节点，便可释放锁。
 

2.2 Redis分布式锁

  Redisson在基于NIO的Netty框架上，充分的利用了Redis键值数据库提供的一系列优点，在Java实用工具包中经常使用接口的基础上，为使用者提供了一系列具备分布式特性的经常使用工具类。Redisson提供了分布式锁特性，开发者可直接利用开发相关业务。

Redis分布式锁架构示意图以下：

2.3 分布式锁比对

	可重入锁	持锁断开链接后释放锁	锁持久化	优缺点
ZK	支持	支持，临时节点当链接中断会删除锁	支持	安全性较高，支持锁持久化存储，但效率稍低
Redis	支持	支持，过时时间	不支持	安全性较低，不支持锁持久化存储，但效率较高

 

3 分布式锁总结

  除了上面提到的ZooKeeper和Redis外，还有不少技术能够实现分布式锁。在思考是否采用分布式锁以及采用哪一种实现方案的时候，仍是要基于业务，技术方案必定是基于业务基础，服务于业务，而且衡量过投入产出比的。因此若是有成熟的解决方案，在业务可承受规模确定是不要重复造轮子，固然还要通过严谨的选型和测试。开发者在实际开发中，可权衡利弊，选择一种最合适业务场景的分布式锁来实现相关业务。