分布式锁框架分析

三大引擎分析

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的问题：锁失效问题和单点问题。
• 没有提供引擎的降级方案，也不能一键切换引擎，须要业务机器停下业务逐个切换。
• 须要提供专属集群。
• 代码层次须要优化，注释相对较少。

项目的改进

1. curator最流行的zookeeper的客户端，对分布式锁有很好的支持，有提供模仿jdk锁的API，对项目的后期改进空间较大，故zookeeper引擎内部zookeeper客户端换成curator。
2. 增长一个服务端以及web界面，管理分布式锁客户端机器的状态信息（记录链接机器的IP地址、持有锁的机器的IP地址、机器的appkey等），以及集群的锁的记录等信息管理和查看。
3. 因为业务在运行时对引擎进行切换，服务端会丢失锁的记录信息，并且没有较好的解决方案；同时大多数业务在给出需求时就能够肯定最合适的引擎，故除去引擎降级方案，增长另外一集群进行切换。
4. 须要创建容灾机制，双中心容灾或异地容灾后期研究。
5. 目前已知tair引擎在并发量大的时候会出现请求超时问题，须要查看集群状态，后期研究改进。
6. 提供鉴权，同时对appkey和secret的校验移至服务端进行。
7. 提供统计功能：统计单个机器调用分布式锁次数，调用成功和失败次数，异常统计。
8. 解决redlock的问题，同时squirrel的redission的方案进行研究。