CN107423155A - 数据节点故障探测方法及装置 - Google Patents

数据节点故障探测方法及装置 Download PDF

Info

Publication number
CN107423155A
CN107423155A CN201710624388.6A CN201710624388A CN107423155A CN 107423155 A CN107423155 A CN 107423155A CN 201710624388 A CN201710624388 A CN 201710624388A CN 107423155 A CN107423155 A CN 107423155A
Authority
CN
China
Prior art keywords
back end
access
request
client
detection method
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
CN201710624388.6A
Other languages
English (en)
Inventor
林涛
刘又
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Green Bay Network Technology Co Ltd
Original Assignee
Hangzhou Green Bay Network Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou Green Bay Network Technology Co Ltd filed Critical Hangzhou Green Bay Network Technology Co Ltd
Priority to CN201710624388.6A priority Critical patent/CN107423155A/zh
Publication of CN107423155A publication Critical patent/CN107423155A/zh
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/875—Monitoring of systems including the internet

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明提出一种数据节点故障探测方法及装置，其中，方法包括：在当前探测周期内，当接收到客户端发送的访问请求时，从访问请求提取试图访问的数据节点；对数据节点的访问次数进行更新；在更新后的访问次数到达预设的次数时，向数据节点发送探活请求，以探测数据节点是否处于故障状态；在数据节点处于故障状态时，向客户端返回的节点信息中不包括处于故障状态的数据节点的节点信息。该方法能够有效提升主节点发现故障的数据节点的效率，提升客户端获取数据的及时性，且只有当数据节点的访问次数在设置的周期达到预设次数时，才会触发主节点向数据节点发送探活请求，减少了主节点发送探活请求的数据节点的数量，降低主节点的负担。

Description

数据节点故障探测方法及装置
技术领域
本发明涉及互联网技术领域，尤其涉及一种数据节点故障探测方法及装置。
背景技术
在Hadoop分布式文件系统(Distributed File System，DFS)(简称HDFS)中，每个数据节点(Data Node,简称DN)周期性地向主节点发送心跳消息，主节点(Name Node，简称NN)可以通过心跳消息的缺失来判断数据节点是否发生网络故障。具体地，主节点在超过一定的时间还未收到数据节点的心跳信息时，判断数据节点故障。
现有技术中，客户端如果想要访问HDFS中的数据，首先发送访问请求至主节点，主节点在接收到客户端发送的访问请求时，向客户端返回所访问的目标数据所在的数据节点，客户端再访问对应的数据节点获取数据。当数据节点处于故障状态，且主节点尚未发现时，客户端则无法从该数据节点中获取数据，而后，客户端就会再次向主节点发送访问请求，由于主节点还未判断该数据节点故障，根据Hadoop机架感知的原则，主节点依然会向客户端返回该故障的数据节点的节点信息。
这种方式下，主节点发现故障的数据节点的效率较低，客户端从发送访问请求到获取到数据可能会存在较长的时延。
发明内容
本发明旨在至少在一定程度上解决相关技术中的技术问题之一。
为此，本发明的第一个目的在于提出一种数据节点故障探测方法，以实现只有当数据节点的访问次数在设置的周期达到预设次数时，才会触发主节点向数据节点发送探活请求，这样就不会存在超时时间的问题，能够有效提升主节点发现故障的数据节点的效率，提升客户端获取数据的及时性，进一步地，由于只有当数据节点的访问次数在设置的周期达到预设次数时，才会触发主节点向数据节点发送探活请求，相应地，减少了主节点发送探活请求的数据节点的数量，能够降低主节点的负担，用于解决现有主节点发现故障的数据节点的效率较低，客户端从发送访问请求到获取到数据可能会存在较长的时延的问题。
本发明的第二个目的在于提出一种数据节点故障探测装置。
本发明的第三个目的在于提出另一种数据节点故障探测装置。
本发明的第四个目的在于提出一种计算机可读存储介质。
本发明的第五个目的在于提出一种计算机程序产品。
为达上述目的，本发明第一方面实施例提出了一种数据节点故障探测方法，包括：在当前探测周期内，当接收到客户端发送的访问请求时，从所述访问请求提取试图访问的数据节点；对所述数据节点的访问次数进行更新；判断更新后的所述访问次数是否到达预设的次数；如果到达所述预设的次数，则向所述数据节点发送探活请求，以探测所述数据节点是否处于故障状态；如果所述数据节点处于故障状态，则向所述客户端返回的节点信息中不包括处于故障状态的所述数据节点的节点信息。
本发明实施例的数据节点故障探测方法，通过在当前探测周期内，当接收到客户端发送的访问请求时，从访问请求提取试图访问的数据节点，对数据节点的访问次数进行更新，在更新后的访问次数到达预设的次数时，向数据节点发送探活请求，在数据节点处于故障状态时，向客户端返回的节点信息中不包括处于故障状态的数据节点的节点信息。本实施例中，只有当数据节点的访问次数在设置的周期达到预设次数时，就会触发主节点向数据节点发送探活请求，这样就不会存在超时时间的问题，能够有效提升主节点发现故障的数据节点的效率，提升客户端获取数据的及时性。进一步地，由于只有当数据节点的访问次数在设置的周期达到预设次数时，才会触发主节点向数据节点发送探活请求，相应地，减少了主节点发送探活请求的数据节点的数量，能够降低主节点的负担。
为达上述目的，本发明第二方面实施例提出了一种数据节点故障探测装置，包括：提取模块，用于在当前探测周期内，当接收到客户端发送的访问请求时，从所述访问请求提取试图访问的数据节点；更新模块，用于对所述数据节点的访问次数进行更新；判断模块，用于判断更新后的所述访问次数是否到达预设的次数；发送模块，用于在到达所述预设的次数时，向所述数据节点发送探活请求，以探测所述数据节点是否处于故障状态；处理模块，用于在所述数据节点处于故障状态时，向所述客户端返回的节点信息中不包括处于故障状态的所述数据节点的节点信息。
本发明实施例的数据节点故障探测装置，通过在当前探测周期内，当接收到客户端发送的访问请求时，从访问请求提取试图访问的数据节点，对数据节点的访问次数进行更新，在更新后的访问次数到达预设的次数时，向数据节点发送探活请求，在数据节点处于故障状态时，向客户端返回的节点信息中不包括处于故障状态的数据节点的节点信息。本实施例中，只有当数据节点的访问次数在设置的周期达到预设次数时，就会触发主节点向数据节点发送探活请求，这样就不会存在超时时间的问题，能够有效提升主节点发现故障的数据节点的效率，提升客户端获取数据的及时性。进一步地，由于只有当数据节点的访问次数在设置的周期达到预设次数时，才会触发主节点向数据节点发送探活请求，相应地，减少了主节点发送探活请求的数据节点的数量，能够降低主节点的负担。
为达上述目的，本发明第三方面实施例提出了另一种数据节点故障探测装置，包括：处理器和存储器；其中，所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于实现上述第一方面实施例提出的数据节点故障探测方法。
为了实现上述目的，本发明第四方面实施例提出了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时，实现上述第一方面实施例提出的数据节点故障探测方法。
为了实现上述目的，本发明第五方面实施例提出了一种计算机程序产品，当所述计算机程序产品中的指令处理器执行时，执行本发明上述第一方面实施例提出的数据节点故障探测方法。
本发明附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1为本发明实施例提供的一种数据节点故障探测方法的流程示意图；
图2为本发明实施例提供的另一种数据节点故障探测方法的流程示意图；
图3为本发明实施例提供的另一种数据节点故障探测方法的流程示意图；
图4为本发明实施例提供的另一种数据节点故障探测方法的流程示意图；
图5为本发明实施例提供的一种数据节点故障探测装置的结构示意图；
图6为本发明实施例提供的另一种数据节点故障探测装置的结构示意图。
具体实施方式
下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。
下面参考附图描述本发明实施例的数据节点故障探测方法及装置。
现有技术中，在HDFS中，每个数据节点周期性地向主节点发送心跳消息，主节点可以通过心跳消息的缺失来判断数据节点是否发生网络故障。具体地，主节点在超过超时时间，还未收到数据节点的心跳信息时，判断数据节点故障。其中，超时时间可以通过以下公式计算得到：
timeout＝2*heartbeat.recheck.interval+10*dfs.heartbeat.interval；
其中，heartbeat.recheck.interval表示心跳检查间隔，dfs.heartbeat.interval表示DFS心跳间隔。
根据HDFS默认的参数值，可以得到timeout为390秒，由于数据节点发生网络故障后，主节点在390秒后才能知晓，将极大地影响客户端用户的上网体验。
虽然可以通过调整上述的两个参数值来缩短timeout值，但是主节点判断数据节点发生故障的效率还是较低，例如，将heartbeat.recheck.interval和dfs.heartbeat.interval均设置为1秒，主节点还需要12秒才能判定数据节点发生故障。
这种方式下，主节点发现故障的数据节点的效率较低，客户端从发送访问请求到获取到数据可能会存在较长的时延。
针对现有技术中的问题，本发明实施例通过在当前探测周期内，客户端访问数据节点的次数达到预设次数时，向数据节点发送探活请求，在数据节点处于故障状态时，向客户端返回的节点信息中不包括处于故障状态的数据节点的节点信息。只有当数据节点的访问次数在设置的周期达到预设次数时，就会触发主节点向数据节点发送探活请求，这样就不会存在超时时间的问题，能够有效提升主节点发现故障的数据节点的效率，提升客户端获取数据的及时性。进一步地，由于只有当数据节点的访问次数在设置的周期达到预设次数时，才会触发主节点向数据节点发送探活请求，相应地，减少了主节点发送探活请求的数据节点的数量，能够降低主节点的负担。
图1为本发明实施例提供的一种数据节点故障探测方法的流程示意图。
本实施例的执行主体可以为HDFS中的主节点。
如图1所示，该数据节点故障探测方法包括：
S101，在当前探测周期内，当接收到客户端发送的访问请求时，从访问请求提取试图访问的数据节点。
在本发明的实施例中，探测周期为预先设置的，由于数据节点故障时，会影响客户端的正常使用，因此，探测周期可以设置的较短，例如为5秒。
可选地，客户端若要访问HDFS中的数据，可以发送访问请求至主节点，其中，主节点中存储HDFS的元信息，例如数据与数据节点的对应关系，主节点在接收到访问请求时，可以根据访问请求中的数据，提取出该数据对应的数据节点。
S102，对数据节点的访问次数进行更新。
可选地，主节点可以记录客户端在当前探测周期内，对数据节点的访问次数。具体地，在当前探测周期内，客户端每向主节点发送一次访问数据节点的请求，就将该数据节点的访问次数加1。
作为一种可选地的实现方式，可以在主节点上设置一个计数器，当客户端每向主节点发送一次访问数据节点的请求，就将该计数器的计数值加1，计数器的当前计数值就可以用来表示数据节点的访问次数。
S103，判断更新后的访问次数是否到达预设的次数。
在本发明的实施例中，预设的次数为预先设置的，由于探测周期较短，因此访问次数不宜设置的过大，例如可以为10次。
可选地，判断更新后的访问次数是否到达预设的次数，在更新后的访问次数未到达预设的次数时，表明在短时间内，客户端对数据节点的访问次数不多，此时，可以不向数据节点发送探活请求；在更新后的访问次数到达预设的次数时，触发后续步骤。
S104，如果到达预设的次数，则向数据节点发送探活请求，以探测数据节点是否处于故障状态。
可选地，在更新后的访问次数到达预设的次数时，表明在短时间内，客户端对数据节点的访问次数较多，此时，为了避免在数据节点发生故障时，主节点仍向客户端返回该故障的数据节点的节点信息，主节点可以向数据节点发送探活请求，以探测数据节点是否处于故障状态。
可选地，主节点可以通过心跳消息的缺失来判断数据节点是否处于故障状态，具体地，若主节点向数据节点发送探活请求后，收到数据节点的心跳消息，表明数据节点未处于故障状态；若主节点向数据节点发送探活请求后，未收到数据节点的心跳消息，表明数据节点处于故障状态。
S105，如果数据节点处于故障状态，则向客户端返回的节点信息中不包括处于故障状态的数据节点的节点信息。
可选地，在数据节点处于故障状态时，该数据节点不能再向客户端提供正常的服务，为了避免客户端再次向该处于故障状态的数据节点发送访问请求，在主节点向客户端返回的节点信息时，返回的节点信息中可以不包括处于故障状态的数据节点的节点信息，这样客户端就不能再接收到处于故障状态的数据节点的节点信息，相应地，客户端也就不会再向该数据节点发送访问请求，为了能够获取到数据，客户端可以从其他的数据节点中请求数据，从而能够保证客户端获取数据的及时性。
本实施例的数据节点故障探测方法，通过在当前探测周期内，当接收到客户端发送的访问请求时，从访问请求提取试图访问的数据节点，对数据节点的访问次数进行更新，在更新后的访问次数到达预设的次数时，向数据节点发送探活请求，在数据节点处于故障状态时，向客户端返回的节点信息中不包括处于故障状态的数据节点的节点信息。本实施例中，只有当数据节点的访问次数在设置的周期达到预设次数时，就会触发主节点向数据节点发送探活请求，这样就不会存在超时时间的问题，能够有效提升主节点发现故障的数据节点的效率，提升客户端获取数据的及时性。进一步地，由于只有当数据节点的访问次数在设置的周期达到预设次数时，才会触发主节点向数据节点发送探活请求，相应地，减少了主节点发送探活请求的数据节点的数量，能够降低主节点的负担。
为了清楚说明上一实施例，本实施例提供了另一种数据节点故障探测方法，图2为本发明实施例所提供的另一种数据节点故障探测方法的流程示意图。
S201，在当前探测周期内，当接收到客户端发送的访问请求时，从访问请求提取试图访问的数据节点。
S202，对数据节点的访问次数进行更新。
S203，判断更新后的访问次数是否到达预设的次数，若是，执行S204，否则，执行S208。
S204，向数据节点发送探活请求。
可选地，在更新后的访问次数到达预设的次数时，向数据节点发送探活请求，以探测数据节点是否处于故障状态。
S205，探测数据节点是否处于故障状态，若是，执行S206，否则，执行S207。
S206，向客户端返回的节点信息中不包括处于故障状态的数据节点的节点信息。
可选地，在数据节点处于故障状态时，向客户端返回的节点信息中不包括处于故障状态的数据节点的节点信息。
关于步骤S201～206的介绍可参见上述实施例中相关内容的记载，此处不再赘述。
S207，控制在当前周期内不再向数据节点发送探活请求。
可选地，在数据节点处于正常状态时，即主节点向数据节点发送探活请求后，能够收到数据节点的心跳消息，此时，客户端依然能够访问该数据节点，因此，可以控制在当前周期内不再向数据节点发送探活请求，有效提升主节点的处理效率。
需要说明的是，当数据节点处于正常状态时，可以对该数据节点的访问次数进行清零处理，或者，还可以对该数据节点的访问次数继续进行计数处理，对此不作限制，本步骤的主要目的为在当前周期内不再向该数据节点发送探活请求，以提升主节点的处理效率。
S208，判断是否到达当前周期，若是，执行S209，否则，执行S210。
可选地，在更新后的数据节点的访问次数未到达预设的次数时，可以继续判断是否到达当前周期，在未到达当前周期时，由于客户端对该数据节点的访问次数不多，主节点可以不作任何处理；在到达当前周期时，触发后续步骤。
S209，对更新后的访问次数进行清零。
可选地，在更新后的访问次数未到达预设的次数，且到达当前周期时，对更新后的访问次数进行清零，以进行下一周期的数据节点故障探测。
S210，结束。
本发明实施例，实际应用中可能存在当前周期的某一个时间点到达预设的次数，但是发送了探活请求后未探测到数据节点处于故障状态。但是，在该时间点之后数据节点却出现了故障，由于当前周期内已经发送过探活请求，探活的结果为数据节点仍然为正常状态，主节点在该周期内并不再对数据节点进行探活，这就导致该数据节点的故障状态无法在当前周期内得知，只能等待下一个周期才能探测到数据节点处于故障状态，所以本发明实施例中，最长经过两个探测周期，即可发现故障的数据节点，能够有效提升主节点的检测效率。
本实施例的数据节点故障探测方法，通过在当前探测周期内，客户端访问数据节点的次数达到预设次数时，向数据节点发送探活请求，在数据节点处于故障状态时，向客户端返回的节点信息中不包括处于故障状态的数据节点的节点信息，实现只有当数据节点的访问次数在设置的周期达到预设次数时，才会触发主节点向数据节点发送探活请求，这样就不会存在超时时间的问题，能够有效提升主节点发现故障的数据节点的效率，提升客户端获取数据的及时性。进一步地，由于只有当数据节点的访问次数在设置的周期达到预设次数时，才会触发主节点向数据节点发送探活请求，相应地，减少了主节点发送探活请求的数据节点的数量，能够降低主节点的负担。通过在数据节点处于正常状态时，控制在当前周期内不再向数据节点发送探活请求，能够有效提升主节点的处理效率。通过在到达当前周期时，对更新后的访问次数进行清零，在未到达当前周期时，不作任何处理，能够有效提升主节点的检测效率。
为了清楚说明上述实施例，参见图3，在如图1所示实施例的基础上，该数据节点故障探测方法还可以包括以下步骤：
S301，利用每次从访问请求中提取出的数据节点形成数据节点列表。
可选地，数据节点列表中存储的为访问时间最近的数据节点，可以将客户端最新访问的数据节点排在数据列表的最上面，即将访问时间最晚的数据节点排在数据列表的最下面，而后，按照访问时间从晚到早的顺序从下到上依次排开，则排在数据列表最下面的为访问时间最早的数据节点，排在数据列表最上面的为访问时间最早的数据节点。
S302，针对数据节点列表中每个数据节点，当接收到数据节点对应的访问请求时，对数据节点的访问次数进行更新。
可选地，当接收到某个数据节点对应的访问请求时，对该数据节点的访问次数进行更新，即将该数据节点调整到数据节点列表的最上方，并且将该数据节点对应的访问次数加1。
作为一种示例，数据节点列表中原有的数据节点以及对应的访问次数如表1所示，若此时从访问请求中提取出的数据节点为数据节点列表原有的节点，比如节点2，则更新后的数据节点列表如表2所示，即将节点2放在数据节点列表的最上边，将剩余的节点依次往后排列。
表1
表2
作为另一种示例，数据节点列表中原有的数据节点以及对应的访问次数如表1所示，若此时从访问请求中提取出的数据节点为新的节点，比如节点11，则更新后的数据节点列表如表3所示。
表3
另一种示例，在数据节点列表中存储的节点数量固定的情况下，将节点11排进数据节点列表之后，则数据节点列表中的最后一个数据节点即节点10从列表中移除，如表4所示。
表4
S303，对列表中的数据节点的访问次数进行更新。
可选地，对列表中的数据节点的访问次数进行更新，即对客户端所有访问过的数据节点进行记录，行成数据节点列表，能够实现对数据列表的动态维护，使得数据列表中存储的为最新访问的数据节点，保证数据列表中数据节点的实时性。
本实施例的数据节点故障探测方法，通过利用每次从访问请求中提取出的数据节点形成数据节点列表，针对数据节点列表中每个数据节点，当接收到数据节点对应的访问请求时，对数据节点的访问次数进行更新，对列表中的数据节点的访问次数进行更新，能够实现对数据列表的动态维护，使得数据列表中存储的为最新访问的数据节点，保证数据列表中数据节点的实时性。
为了清楚说明上述实施例，参见图4，在如图3所示实施例的基础上，步骤S301具体包括以下步骤：
S401，基于LRU算法利用客户端最新访问的数据节点更新LRU队列中存储的数据节点的顺序；其中，LRU队列中各数据节点按照访问时间从晚到早的顺序进行排列。
在本发明的实施例中，LRU(Least Recently Used，最近最少使用)队列中存储的是最近一段时间内访问的数据节点，可以将最近访问的数据节点按照访问时间在LRU队列中进行存储。具体地，可以将数据节点按照访问时间从晚到早的顺序从下到上依次排开，则排在LRU队列的最上边的即为访问时间最早的数据节点。
需要说明的是，基于LRU算法得到的LRU队列中存储的数据节点的个数可以是固定的，也可以是不固定的。可以根据最新的访问请求中的数据节点动态调整原有的LRU队列中的数据节点。
例如，LRU队列中存储的数据节点的顺序为：节点1、节点2、…、节点10，此时，如果最新的访问请求中的数据节点为LRU队列中已有的节点，比如节点3，则将节点3调整到LRU队列的最上面，LRU队列中存储的数据节点的顺序为：节点3、节点1、节点2、节点4、节点5、…、节点10。
又例如，LRU队列中存储的数据节点的顺序为：节点1、节点2、…、节点10，此时，如果最新的访问请求中的数据节点为新的节点，比如节点11，这时，节点11将调整到LRU队列的最上面。若LRU队列中存储的数据节点的个数是不固定的，则LRU队列中存储的数据节点的顺序为：节点11、节点1、节点2、…、节点9、节点10；若LRU队列中存储的数据节点的个数是固定的，且为10个时，则调整后的LRU队列中存储的数据节点的顺序为：节点11、节点1、节点2、…、节点9。
S402，利用LRU队列中所有数据节点形成数据节点列表。
可选地，数据节点列表中的数据节点的顺序和LRU队列中存储的数据节点的顺序一致，例如，LRU队列中存储的数据节点的顺序为：节点1、节点2、…、节点10，则数据节点列表从上到下的数据节点依次为：节点1、节点2、…、节点10。
本实施例的数据节点故障探测方法，通过基于LRU算法利用客户端最新访问的数据节点更新LRU队列中存储的数据节点的顺序，利用LRU队列中所有数据节点形成数据节点列表，能够动态维护数据节点列表，保证数据列表中的数据节点的实时性。
现有技术中，数据节点将会给主节点带来频繁的心跳包，若集群规模庞大时，例如有1000个数据节点时，所有的数据节点所发送的心跳信号的每秒查询率(Query PerSecond，QPS)将达到1000，给主节点带来较大的负担。
而本发明图1～图4实施例中的数据节点，所发送的心跳信号的每秒查询率维持不变，由于在主节点进行次数的统计，基于次数触发向数据节点发送探活请求，可以不用在缩短心跳信号发送频率，就可以解决现有技术探测时存在的超时时间较长的问题，从而不会影响心跳信号的QPS，能够保持所发送的心跳信号QPS不变。而且并且减少了主节点发送探活请求的数据节点的数量，能够降低主节点的负担。
为了实现上述实施例，本发明还提出一种数据节点故障探测装置。
图5为本发明实施例提供的一种数据节点故障探测装置的结构示意图。
如图5所示，该数据节点故障探测装置500包括：提取模块510、第一更新模块520、判断模块530、第一处理模块540，以及第二处理模块550。其中，
提取模块510，用于在当前探测周期内，当接收到客户端发送的访问请求时，从访问请求提取试图访问的数据节点。
第一更新模块520，用于对数据节点的访问次数进行更新。
判断模块530，用于判断更新后的访问次数是否到达预设的次数。
第一处理模块540，用于在到达预设的次数时，向数据节点发送探活请求，以探测数据节点是否处于故障状态。
可选地，第一处理模块540，还用于在更新后的访问次数未到达预设的次数时，当到达当前周期时对更新后的访问次数进行清零。
第二处理模块550，用于在数据节点处于故障状态时，向客户端返回的节点信息中不包括处于故障状态的数据节点的节点信息。
可选地，第二处理模块550，还用于在数据节点处于正常状态，则控制在当前周期内不再向数据节点发送探活请求。
进一步地，在本发明实施例的一种可能的实现方式中，在图5的基础上，参见图6，该数据节点故障探测装置500还进一步包括：
形成模块560，用于利用每次从访问请求中提取出的数据节点形成数据节点列表。
第二更新模块570，用于针对数据节点列表中每个数据节点，当接收到数据节点对应的访问请求时，对数据节点的访问次数进行更新。
第三更新模块580，用于对列表中的数据节点的访问次数进行更新。
具体实现时，形成模块560，具体用于：基于LRU算法利用客户端最新访问的数据节点更新LRU队列中存储的数据节点的顺序；其中，LRU队列中各数据节点按照访问时间从晚到早的顺序进行排列；利用LRU队列中所有数据节点形成数据节点列表。
需要说明的是，上述数据节点所发送的心跳信号的每秒查询率维持不变。
需要说明的是，前述图1-图4实施例对数据节点故障探测方法实施例的解释说明也适用于该实施例的数据节点故障探测装置800，此处不再赘述。
本实施例的数据节点故障探测装置，通过在当前探测周期内，当接收到客户端发送的访问请求时，从访问请求提取试图访问的数据节点，对数据节点的访问次数进行更新，在更新后的访问次数到达预设的次数时，向数据节点发送探活请求，在数据节点处于故障状态时，向客户端返回的节点信息中不包括处于故障状态的数据节点的节点信息。本实施例中，只有当数据节点的访问次数在设置的周期达到预设次数时，就会触发主节点向数据节点发送探活请求，这样就不会存在超时时间的问题，能够有效提升主节点发现故障的数据节点的效率，提升客户端获取数据的及时性。进一步地，由于只有当数据节点的访问次数在设置的周期达到预设次数时，才会触发主节点向数据节点发送探活请求，相应地，减少了主节点发送探活请求的数据节点的数量，能够降低主节点的负担。
为了实现上述实施例，本发明还提出一种数据节点故障探测装置，包括：处理器和存储器；其中，所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于实现如前述实施例所述的数据节点故障探测方法。
为了实现上述实施例，本发明还提出一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时，执行本发明上述实施例提出的数据节点故障探测方法。
为了实现上述实施例，本发明还提出一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如前述实施例所述的数据节点故障探测方法。
在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。
此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本发明的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。
流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现定制逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。
在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。
应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。如，如果用硬件来实现和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。
本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。
此外，在本发明各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。
上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (10)

1.一种数据节点故障探测方法，其特征在于，包括：
在当前探测周期内，当接收到客户端发送的访问请求时，从所述访问请求提取试图访问的数据节点；
对所述数据节点的访问次数进行更新；
判断更新后的所述访问次数是否到达预设的次数；
如果到达所述预设的次数，则向所述数据节点发送探活请求，以探测所述数据节点是否处于故障状态；
如果所述数据节点处于故障状态，则向所述客户端返回的节点信息中不包括处于故障状态的所述数据节点的节点信息。
2.根据权利要求1所述的数据节点故障探测方法，其特征在于，还包括：
如果所述数据节点处于正常状态，则控制在当前周期内不再向所述数据节点发送所述探活请求。
3.根据权利要求1所述的数据节点故障探测方法，其特征在于，还包括：
如果更新后的所述访问次数未到达所述预设的次数，则当到达当前周期时对更新后的所述访问次数进行清零。
4.根据权利要求1所述的数据节点故障探测方法，其特征在于，还包括：
利用每次从所述访问请求中提取出的数据节点形成数据节点列表；
针对所述数据节点列表中每个数据节点，当接收到所述数据节点对应的所述访问请求时，对所述数据节点的所述访问次数进行更新。
对所述列表中的数据节点的访问次数进行更新。
5.根据权利要求4所述的数据节点故障探测方法，其特征在于，所述利用每次从所述访问请求中提取出的数据节点形成数据节点列表，包括：
基于LRU算法利用所述客户端最新访问的所述数据节点更新LRU队列中存储的数据节点的顺序；其中，所述LRU队列中各数据节点按照访问时间从晚到早的顺序进行排列；
利用所述LRU队列中所有数据节点形成所述数据节点列表。
6.根据权利要求1-5任一项所述的数据节点故障探测方法，其特征在于，还包括：
所述数据节点所发送的心跳信号的每秒查询率维持不变。
7.一种数据节点故障探测装置，其特征在于，包括：
提取模块，用于在当前探测周期内，当接收到客户端发送的访问请求时，从所述访问请求提取试图访问的数据节点；
第一更新模块，用于对所述数据节点的访问次数进行更新；
判断模块，用于判断更新后的所述访问次数是否到达预设的次数；
第一处理模块，用于在到达所述预设的次数时，向所述数据节点发送探活请求，以探测所述数据节点是否处于故障状态；
第二处理模块，用于在所述数据节点处于故障状态时，向所述客户端返回的节点信息中不包括处于故障状态的所述数据节点的节点信息。
8.一种数据节点故障探测装置，其特征在于，包括处理器和存储器；
其中，所述处理器通过读取所述存储器中存储的可执行程序代码来运行与所述可执行程序代码对应的程序，以用于实现如权利要求1-6中任一所述的数据节点故障探测方法。
9.一种计算机程序产品，当所述计算机程序产品中的指令由处理器执行时，执行如权利要求1-6中任一项所述的数据节点故障探测方法。
10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如权利要求1-6中任一项所述的数据节点故障探测方法。
CN201710624388.6A 2017-07-27 2017-07-27 数据节点故障探测方法及装置 Withdrawn CN107423155A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710624388.6A CN107423155A (zh) 2017-07-27 2017-07-27 数据节点故障探测方法及装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710624388.6A CN107423155A (zh) 2017-07-27 2017-07-27 数据节点故障探测方法及装置

Publications (1)

Publication Number Publication Date
CN107423155A true CN107423155A (zh) 2017-12-01

Family

ID=60430452

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710624388.6A Withdrawn CN107423155A (zh) 2017-07-27 2017-07-27 数据节点故障探测方法及装置

Country Status (1)

Country Link
CN (1) CN107423155A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109189829A (zh) * 2018-08-20 2019-01-11 广州知弘科技有限公司 基于大数据的信息安全系统和方法
CN112165517A (zh) * 2020-09-22 2021-01-01 成都知道创宇信息技术有限公司 一种回源探测方法、装置、存储介质及电子设备
CN113342405A (zh) * 2021-06-25 2021-09-03 支付宝(杭州)信息技术有限公司 一种服务恢复的方法、装置以及设备
CN116797323A (zh) * 2023-08-21 2023-09-22 北京嗨飞科技有限公司 一种数据处理方法、装置及设备

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1852252A (zh) * 2006-04-14 2006-10-25 清华大学 基于对等网络的视频直播应用中节点选择与检测方法
CN102137006A (zh) * 2010-12-31 2011-07-27 华为技术有限公司 Cdn网络中的数据传输方法及设备
CN103744859A (zh) * 2013-12-13 2014-04-23 北京奇虎科技有限公司 一种故障数据的下线方法及设备
CN106254161A (zh) * 2016-09-28 2016-12-21 上海爱数信息技术股份有限公司 基于hdfs的节点失效的快速检测与恢复方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1852252A (zh) * 2006-04-14 2006-10-25 清华大学 基于对等网络的视频直播应用中节点选择与检测方法
CN102137006A (zh) * 2010-12-31 2011-07-27 华为技术有限公司 Cdn网络中的数据传输方法及设备
CN103744859A (zh) * 2013-12-13 2014-04-23 北京奇虎科技有限公司 一种故障数据的下线方法及设备
CN106254161A (zh) * 2016-09-28 2016-12-21 上海爱数信息技术股份有限公司 基于hdfs的节点失效的快速检测与恢复方法及系统

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109189829A (zh) * 2018-08-20 2019-01-11 广州知弘科技有限公司 基于大数据的信息安全系统和方法
CN109189829B (zh) * 2018-08-20 2019-07-26 太平洋电信股份有限公司 基于大数据的信息安全系统和方法
CN112165517A (zh) * 2020-09-22 2021-01-01 成都知道创宇信息技术有限公司 一种回源探测方法、装置、存储介质及电子设备
CN113342405A (zh) * 2021-06-25 2021-09-03 支付宝(杭州)信息技术有限公司 一种服务恢复的方法、装置以及设备
CN113342405B (zh) * 2021-06-25 2022-04-29 支付宝(杭州)信息技术有限公司 一种服务恢复的方法、装置以及设备
CN116797323A (zh) * 2023-08-21 2023-09-22 北京嗨飞科技有限公司 一种数据处理方法、装置及设备
CN116797323B (zh) * 2023-08-21 2023-11-14 北京嗨飞科技有限公司 一种数据处理方法、装置及设备

Similar Documents

Publication Publication Date Title
CN107423155A (zh) 数据节点故障探测方法及装置
CN105468450B (zh) 任务调度方法及系统
TWI568213B (zh) 交談式遠端管理系統及其負載平衡控制方法
CN106663364A (zh) 无线传感器网络
JP2020501402A5 (zh)
CN110121876A (zh) 用于通过使用行为分析检测恶意设备的系统和方法
CN104584621B (zh) 用于减少计算设备的无线重新连接时间的混合场外/现场预测计算
CN108985553A (zh) 一种异常用户的识别方法及设备
JP6168576B2 (ja) 仮想マシンマイグレーション管理の方法、装置およびシステム
KR20190073409A (ko) Iot 보안 서비스
CN107360034A (zh) 网关恢复方法、装置及其设备
CN107567696A (zh) 计算集群内的资源实例群组的自动扩展
CN109597567A (zh) 一种数据处理方法和装置
US11223602B2 (en) IP address access based on security level and access history
CN101355504A (zh) 一种用户行为的确定方法和装置
CN109085995B (zh) 数据动态分片的存储方法、装置和系统
CN110417901A (zh) 数据处理方法、装置及网关服务器
JP2003178040A (ja) ウェブサイトの構成決定支援方法
CN106202280A (zh) 一种信息处理方法及服务器
CN108121716A (zh) 处理问题单的方法和问题单处理系统
CN106294206A (zh) 一种缓存数据处理方法以及装置
CN111049756A (zh) 请求响应方法、装置、电子设备及计算机可读存储介质
CN104468818B (zh) 一种物联网业务处理系统及其方法
CN108763517A (zh) 一种删除元数据的方法以及相关设备
CN106993147A (zh) 一种录像覆盖方法、装置及网络硬盘录像机

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
CB02 Change of applicant information
CB02 Change of applicant information

Address after: Room 1901, building 1, No. 1782 Jiangling Road, Xixing street, Binjiang District, Hangzhou City, Zhejiang Province

Applicant after: HANGZHOU LVWAN NETWORK TECHNOLOGY Co.,Ltd.

Address before: 2, No. 2630, building 2, superior Science Park, No. 310026 South Ring Road, Hangzhou, Binjiang District, Zhejiang, China

Applicant before: HANGZHOU LVWAN NETWORK TECHNOLOGY Co.,Ltd.

WW01 Invention patent application withdrawn after publication
WW01 Invention patent application withdrawn after publication

Application publication date: 20171201