分布式锁框架分析
Posted 服务端技术杂谈
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了分布式锁框架分析相关的知识，希望对你有一定的参考价值。
三大引擎分析
zookeeper引擎分析
优点：
锁安全性高，zk可持久化，且能实时监听获取锁的客户端状态。
zookeeper支持watcher机制，这样实现阻塞锁，可以watch锁数据，等到数据被删除，zookeeper会通知客户端去重新竞争锁。
zookeeper的数据可以支持临时节点的概念，即客户端写入的数据是临时数据，在客户端宕机后，临时数据会被删除，这样就实现了锁的异常释放。使用这样的方式，就不需要给锁增加超时自动释放的特性了。
缺点：
性能开销比较高。因为其需要动态产生、销毁瞬时节点来实现锁功能。所以不太适合直接提供给高并发的场景使用。
zk使用的Zab的一致性协议，写是一个两阶段协议，效率上要差一些。
使用watch时，由于watch使用较多，watch对zookeeper性能有一定影响。
适用场景：
对可靠性要求非常高，且并发程度不高的场景下使用。如核心数据的定时全量/增量同步等。
tair引擎分析
优点：
同时支持分布式缓存和持久化存储。
自动的复制和迁移，自动扩容。
tair支持Version、原子计数、和Item支持。
使用的中心化的架构设计和一致性 hash 算法的数据分布，同时支持在线数据迁移。
数据可靠性⾼、成本低。
缺点：
在⼤并发访问下性能可能会有较⼤抖动
在某些情况下（如客户端gc、磁盘io、慢请求阻塞）会导致请求超时问题，在分布式锁的使用中会导致获取锁失败。
场景：
数据规模较⼤、冷热数据显著的业务场景，对分布式锁可靠性有一定要求，但并发量要求没有太高的时候使用。
redis引擎分析
优点：
并发高效，redis自3.0自身支持集群，同时支持哨兵机制，高性能低延迟。
redis可以持久化数据。
redis使用单进程单线程，内存存储，速度非常快，比memcached还要快很多，所以支持的并发访问量可以很高。
现已有成熟的java客户端，如jedis。
缺点：
redis采用某些淘汰策略，所以如果内存不够，可能导致缓存中的锁信息丢失。
一旦缓存服务宕机，锁数据就丢失了。像redis自带复制功能，可以对数据可靠性有一定的保证，但是由于复制也是异步完成的，因此依然可能出现master节点写入锁数据而未同步到slave节点的时候宕机，锁数据丢失问题。
需要加入超时机制避免死锁。
成本较高。
场景：
高并发，需要加入超时机制避免死锁，提供足够的支撑锁服务的内存空间，稳定的集群化管理，同时没有对数据的可靠性有较高要求。
自研分布式锁分析
优点：
提供了引擎的多种选择，多种可靠性和不同并发量的阶梯选择。
可扩展性强，可以加入其他引擎。
zk引擎和tair引擎目前都支持可重入读写锁。
作为一个sdk，可以使用jar包直接导入，业务使用简单。
缺点：
目前相对而言，相对粗糙，多种功能未完成，已有功能需完善。
目前没有管理界面和工具，排错需要到集群上和业务机器上进行。
没有建立容灾机制。
tair请求超时问题未解决。
tair的可重入读写锁暂时支持的不够好，需要研究改进。
redis存在redlock的问题：锁失效问题和单点问题。
没有提供引擎的降级方案，也不能一键切换引擎，需要业务机器停下业务逐个切换。
需要提供专属集群。
代码层次需要优化，注释相对较少。
项目的改进
curator最流行的zookeeper的客户端，对分布式锁有很好的支持，有提供模仿jdk锁的API，对项目的后期改进空间较大，故zookeeper引擎内部zookeeper客户端换成curator。
由于业务在运行时对引擎进行切换，服务端会丢失锁的记录信息，而且没有较好的解决方案；同时大多数业务在给出需求时就可以确定最合适的引擎，故除去引擎降级方案，增加另一集群进行切换。
需要建立容灾机制，双中心容灾或异地容灾后期研究。
目前已知tair引擎在并发量大的时候会出现请求超时问题，需要查看集群状态，后期研究改进。
提供鉴权，同时对appkey和secret的校验移至服务端进行。
提供统计功能：统计单个机器调用分布式锁次数，调用成功和失败次数，异常统计。
解决redlock的问题，同时squirrel的redission的方案进行研究。
以上是关于分布式锁框架分析的主要内容，如果未能解决你的问题，请参考以下文章