Zookeeper异常宕机重启失败分析

Posted 2023-03-20

参考技术A 一体机中使用了单机模式的zookeeper（开机自启服务），一体机经常会遇到断电重启的场景，在运行过程中偶现无法开机启动问题，再次断电重新启动可以正常启动

kill -0 pid 不发送任何信号，但是系统会进行错误检查。所以经常用来检查一个进程是否存在，存在返回0；不存在返回1

查看脚本 zkServer.sh 内容

查看脚本 zkServer.sh 内容

查看脚本 zkServer.sh 内容

假设当兵设备异常断电关机，此时zookeepr的进程号是9966，此时pid的文件内容为9966，当一体机开机自启动时，如果已经有其他进程的进程号为9966时，此时zookeepr的启动脚本发现pid文件存在，且9966进程活着，则认为zookeepr已经正常启动，此时启动脚本啥事也不做只打印日志 already running as process pid ,此时zookeepr进程没有启动，紧接着skynet启动发现无法连接zookeeper，此时启动失败。

通过以上步骤即可完成问题复现。

一体机开机自启服务中使用restart命令即可。

单机模式部署不需要新建 myid 文件和 zoo.cfg 配置项中添加

这种模式有如下问题

建议单机模式下不新建 myid 文件并删除配置 server.1

分布式锁框架分析

三大引擎分析

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。

3. 由于业务在运行时对引擎进行切换，服务端会丢失锁的记录信息，而且没有较好的解决方案；同时大多数业务在给出需求时就可以确定最合适的引擎，故除去引擎降级方案，增加另一集群进行切换。

4. 需要建立容灾机制，双中心容灾或异地容灾后期研究。

5. 目前已知tair引擎在并发量大的时候会出现请求超时问题，需要查看集群状态，后期研究改进。

6. 提供鉴权，同时对appkey和secret的校验移至服务端进行。

7. 提供统计功能：统计单个机器调用分布式锁次数，调用成功和失败次数，异常统计。

8. 解决redlock的问题，同时squirrel的redission的方案进行研究。