CN112905352A - 节点死锁处理的方法和装置 - Google Patents

Abstract

本发明公开了一种节点死锁处理的方法和装置。其中，该方法包括：检测是否存在节点发生死锁；在检测结果为是的情况下，重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点；将第一节点的业务迁移至第二节点，由第二节点执行业务。本发明解决了由于kafka中节点死锁导致的实时数据无法正常处理的技术问题。

Description

节点死锁处理的方法和装置

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种节点死锁处理的方法和装置。

背景技术

kafka是一个开源流处理平台，由Scala和Java编写，该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。

但是在实际运行的过程中，kafka在多个版本有多种情况都有可能会导致死锁，例如0.10版本有三个左右官方公布的死锁bug，例如当autoLeaderRebalance遇到zk过期时，控制器可能会死锁或者说异常的消费等等。

死锁的情况下，单纯查看进程是看不出问题的，但是生产者和消费者和该节点leader partation的建立链接,就会出现kafka该节点leader不提供服务的情况，不能提供任何生产和消费者服务。kafka集群虽然是高可用的，但是这种情况一个节点出现死锁问题，就可能导致实时数据无法处理的情况出现。

针对上述由于kafka中节点死锁导致的实时数据无法正常处理的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种节点死锁处理的方法和装置，以至少解决由于kafka中节点死锁导致的实时数据无法正常处理的技术问题。

根据本发明实施例的一个方面，提供了一种节点死锁的处理方法，应用于开源流处理平台，包括：检测是否存在节点发生死锁；在检测结果为是的情况下，重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点；将第一节点的业务迁移至第二节点，由第二节点执行业务。

可选的，在检测是否存在节点发生死锁之前，该方法还包括：通过预设工具对所有节点设置监控检测。

进一步地，可选的，通过预设工具对所有节点设置监控检测包括：获取主机的地址信息；依据地址信息设置检测指令；依据检测指令设置告警条件。

可选的，重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点包括：重启发生死锁的第一节点；依据第一节点所属的分区和副本集，获取与第一节点关联的节点；将与第一节点关联的节点确定为第二节点。

进一步地，可选的将第一节点的业务迁移至第二节点，由第二节点执行业务包括：通过预设机制将第一节点的业务迁移至第二节点，由第二节点执行业务。

可选的，该方法还包括：在第一节点重启完毕后，恢复第一节点的业务；依据第一节点发生死锁生成的死锁日志进行代码排查，修改故障代码或进行版本升级。

根据本发明实施例的另一方面，还提供了一种节点死锁的处理装置，应用于开源流处理平台，包括：检测模块，用于检测是否存在节点发生死锁；重启模块，用于在检测结果为是的情况下，重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点；数据处理模块，用于将第一节点的业务迁移至第二节点，由第二节点执行业务。

可选的，该装置还包括：预配置模块，用于在检测是否存在节点发生死锁之前，通过预设工具对所有节点设置监控检测。

进一步地，可选的，预配置模块包括：获取单元，用于获取主机的地址信息；第一设置单元，用于依据地址信息设置检测指令；第二设置单元，用于依据检测指令设置告警条件。

可选的，重启模块包括：重启单元，用于重启发生死锁的第一节点；节点获取单元，用于依据第一节点所属的分区和副本集，获取与第一节点关联的节点；节点确定单元，用于将与第一节点关联的节点确定为第二节点。

在本发明实施例中，通过检测是否存在节点发生死锁；在检测结果为是的情况下，重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点；将第一节点的业务迁移至第二节点，由第二节点执行业务，达到了kafka进程在发生死锁的情况下仍能够正常进行数据处理的目的，从而实现了短时间内进程重启恢复，避免因Kafka进程死锁导致的数据丢失的技术效果，进而解决了由于kafka中节点死锁导致的实时数据无法正常处理的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的节点死锁的处理方法的流程示意图；

图2a是根据本发明实施例的节点死锁的处理方法中创建新的Items的示意图；

图2b是根据本发明实施例的节点死锁的处理方法中编辑的Items的示意图；

图2c-d是根据本发明实施例的节点死锁的处理方法中配置告警条件Triggers的示意图；

图2e是根据本发明实施例的节点死锁的处理方法中创建action的示意图；

图2f是根据本发明实施例的节点死锁的处理方法中填写action的名称的示意图；

图2g是根据本发明实施例的节点死锁的处理方法中添加报警条件的示意图；

图2h是根据本发明实施例的节点死锁的处理方法中配置处理操作的示意图；

图3是根据本发明实施例的节点死锁的处理装置的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本发明实施例，提供了一种节点死锁的处理方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本发明实施例的节点死锁的处理方法的流程示意图，如图1所示，应用于开源流处理平台，该方法包括如下步骤：

步骤S102，检测是否存在节点发生死锁；

其中，本申请实施例提供的节点死锁的处理方法可以适用于kafka进程中，通过预设工具zabbix监控kafka所有节点broker的死锁状态。

可选的，在步骤S102中检测是否存在节点发生死锁之前，本申请实施例提供的节点死锁的处理方法还包括：通过预设工具对所有节点设置监控检测。

进一步地，可选的，通过预设工具对所有节点设置监控检测包括：获取主机的地址信息；依据地址信息设置检测指令；依据检测指令设置告警条件。

具体的，cmdline-jmxclient-0.10.3.jar用于jmx监控调试，可应用于zabbix(即，本申请实施例中的预设工具)下java进程的监控，我们使用此工具进行Kafka死锁进程的检测，具体的语法如下。

例：

/opt/jdk1.8.0_131/bin/java-jar/opt/kafka/cmdline-jmxclient-0.10.3.jar-$(ip addr|grep'state UP'-A2|tail-n1|awk'{print$2}'|cut-f1-d'/'):9999java.lang:type＝Threading findDeadlockedThreads 2>&1|wc–l

其中：ip addr|grep'state UP'-A2|tail-n1|awk'{print$2}'|cut-f1-d'/'是获取当前主机IP。

java.lang:type＝Threading findDeadlockedThreads用于检测核对死锁信息。

本申请实施例中对于zabbix的监控配置如下：

1.编写zabbix监控脚本：

脚本位置在/etc/zabbix/zabbix_agentd.d/下，需要在每台有kafka的agent中部署脚本，脚本部署之后需要重启agent。

#wc-l只输出文件行数

UserParameter＝deadlocked_process,/opt/jdk1.8.0_131/bin/java-jar/opt/kafka/cmdline-jmxclient-0.10.3.jar-$(ip addr|grep'state UP'-A2|tail-n1|awk'{print$2}'|cut-f1-d'/'):9999java.lang:type＝Threading findDeadlockedThreads 2>&1|wc-l

2.配置项目items

在现有的Kafka集群监控中创建新的Items，图2a是根据本发明实施例的节点死锁的处理方法中创建新的Items的示意图，如图2a所示。

编辑所创建的Item信息，图2b是根据本发明实施例的节点死锁的处理方法中编辑的Items的示意图，其中的监控项如图2b所示：键值Key为上一步脚本中的UserParameter参数名，数据Data，类型Type为Decimal，其他信息可以为默认配置。

3.配置告警条件Triggers

创建死锁检测的报警Trigger，并进行配置，图2c-d是根据本发明实施例的节点死锁的处理方法中配置告警条件Triggers的示意图，如图2c-d所示。

Expression：{kafka-06:deadlockedthread_process.last()}＝1；

如果统计信息为1，说明有死锁情况，严重程度Severity报警级别为灾害Disaster。

此外，对发生死锁时的操作进行配置：

1.创建action并配置，填写action的名称，添加对应的报警条件和对应的处理操作。如图2e-h所示，图2e是根据本发明实施例的节点死锁的处理方法中创建action的示意图，图2f是根据本发明实施例的节点死锁的处理方法中填写action的名称的示意图，图2g是根据本发明实施例的节点死锁的处理方法中添加报警条件的示意图，图2h是根据本发明实施例的节点死锁的处理方法中配置处理操作的示意图。

在代码实现上可以如下示例：

步骤S104，在检测结果为是的情况下，重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点；

可选的，步骤S104中重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点包括：重启发生死锁的第一节点；依据第一节点所属的分区和副本集，获取与第一节点关联的节点；将与第一节点关联的节点确定为第二节点。

步骤S106，将第一节点的业务迁移至第二节点，由第二节点执行业务。

进一步地，可选的，步骤S106中将第一节点的业务迁移至第二节点，由第二节点执行业务包括：通过预设机制将第一节点的业务迁移至第二节点，由第二节点执行业务。

具体的，结合步骤S104和步骤S106，在检测结果为是的情况下，重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点，为保障kafka进程的不间断，将第一节点的业务迁移至第二节点，由第二节点执行业务

通过action以及利用kafka集群的高可用特性，自动重启该broker节点，使线上服务不受影响，进行应急处理。重启锁就会释放，重启期间(执行时间约1分多钟)，基于kafka集群本身的HA特性，与第一节点上的锁，分区partition和副本集replica关联的broker会通过ISR机制(in-sync Replica)(即，本申请实施例中的预设机制)，自动选主到其他节点(即，本申请实施例中的第二节点)，使kafka集群能够正常提供服务。

区别于步骤S104，在检测kafka进程中所有节点正常的情况下，执行实时数据的处理。

可选的，本申请实施例提供的节点死锁的处理方法还包括：在第一节点重启完毕后，恢复第一节点的业务；依据第一节点发生死锁生成的死锁日志进行代码排查，修改故障代码或进行版本升级。

具体的，在步骤S106之后，重启完成后，该第一节点会正常加入，提供服务。后续应当继续查看研究死锁日志，排查代码以及升级kafka等方案永久解决问题。

需要说明的是，在本申请实施例中开源流处理平台以kafka为例进行说明，以实现本申请实施例提供的节点死锁的处理方法为准，具体不做限定。

在本发明实施例中，通过检测是否存在节点发生死锁；在检测结果为是的情况下，重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点；将第一节点的业务迁移至第二节点，由第二节点执行业务，达到了kafka进程在发生死锁的情况下仍能够正常进行数据处理的目的，从而实现了短时间内进程重启恢复，避免因Kafka进程死锁导致的数据丢失的技术效果，进而解决了由于kafka中节点死锁导致的实时数据无法正常处理的技术问题。

实施例2

根据本发明实施例的另一方面，还提供了一种节点死锁的处理装置，应用于开源流处理平台，图3是根据本发明实施例的节点死锁的处理装置的示意图，如图3所示，包括：检测模块32，用于检测是否存在节点发生死锁；重启模块34，用于在检测结果为是的情况下，重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点；数据处理模块36，用于将第一节点的业务迁移至第二节点，由第二节点执行业务。

可选的，本申请实施例提供的节点死锁的处理装置还包括：预配置模块，用于在检测是否存在节点发生死锁之前，通过预设工具对所有节点设置监控检测。

进一步地，可选的，预配置模块包括：获取单元，用于获取主机的地址信息；第一设置单元，用于依据地址信息设置检测指令；第二设置单元，用于依据检测指令设置告警条件。

可选的，重启模块34包括：重启单元，用于重启发生死锁的第一节点；节点获取单元，用于依据第一节点所属的分区和副本集，获取与第一节点关联的节点；节点确定单元，用于将与第一节点关联的节点确定为第二节点。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (10)

1.一种节点死锁的处理方法，其特征在于，应用于开源流处理平台，包括：

检测是否存在节点发生死锁；

在检测结果为是的情况下，重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点；

将所述第一节点的业务迁移至所述第二节点，由所述第二节点执行所述业务。

2.根据权利要求1所述的方法，其特征在于，在所述检测是否存在节点发生死锁之前，所述方法还包括：

通过预设工具对所有节点设置监控检测。

3.根据权利要求2所述的方法，其特征在于，所述通过预设工具对所有节点设置监控检测包括：

获取主机的地址信息；

依据所述地址信息设置检测指令；

依据检测指令设置告警条件。

4.根据权利要求1所述的方法，其特征在于，所述重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点包括：

重启发生死锁的所述第一节点；

依据所述第一节点所属的分区和副本集，获取与所述第一节点关联的节点；

将与所述第一节点关联的节点确定为所述第二节点。

5.根据权利要求4所述的方法，其特征在于，所述将所述第一节点的业务迁移至所述第二节点，由所述第二节点执行所述业务包括：

通过预设机制将所述第一节点的业务迁移至所述第二节点，由所述第二节点执行所述业务。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

在所述第一节点重启完毕后，恢复所述第一节点的业务；

依据所述第一节点发生死锁生成的死锁日志进行代码排查，修改故障代码或进行版本升级。

7.一种节点死锁的处理装置，其特征在于，应用于开源流处理平台，包括：

检测模块，用于检测是否存在节点发生死锁；

重启模块，用于在检测结果为是的情况下，重启发生死锁的第一节点，并获取与发生死锁的第一节点关联的第二节点；

数据处理模块，用于将所述第一节点的业务迁移至所述第二节点，由所述第二节点执行所述业务。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

预配置模块，用于在所述检测是否存在节点发生死锁之前，通过预设工具对所有节点设置监控检测。

9.根据权利要求8所述的装置，其特征在于，所述预配置模块包括：

获取单元，用于获取主机的地址信息；

第一设置单元，用于依据所述地址信息设置检测指令；

第二设置单元，用于依据检测指令设置告警条件。

10.根据权利要求7所述的装置，其特征在于，所述重启模块包括：

重启单元，用于重启发生死锁的所述第一节点；

节点获取单元，用于依据所述第一节点所属的分区和副本集，获取与所述第一节点关联的节点；

节点确定单元，用于将与所述第一节点关联的节点确定为所述第二节点。

Images