CN110661673A - Method and device for heartbeat detection - Google Patents

Abstract

The embodiments of the present application relate to the field of communication technologies, and in particular, to a method and apparatus for heartbeat detection. In the embodiment of this application, the first server receives a heartbeat request sent by the client, and the heartbeat request is used to determine the communication status of the second server. The first server is the domain name server DNS that receives the heartbeat domain name sent by the client for the second server. When parsing the request, it is assigned to the client. When the first server determines that a valid heartbeat response for the second server is stored, it sends the valid heartbeat response to the client. The valid heartbeat response is based on the first server and the second server. The communication status between them is determined. In this way, the first server does not need to send each received heartbeat request to the second server and ask the second server to give feedback, but when the stored heartbeat response is valid, the first server makes feedback, which can reduce the number of heartbeat requests Occupation of resources of the second server.

Description

Method and device for heartbeat detection

technical field

The embodiments of the present application relate to the field of communication technologies, and in particular, to a method and apparatus for heartbeat detection.

Background technique

When data transmission is performed based on the Transmission Control Protocol (Transmission Control Protocol, TCP) and the Internet Protocol (Internet Protocol, IP), the reliability of the communication becomes the key to guaranteeing the service quality. In order to ensure the rapidity and stability of communication based on the TCP/IP protocol, a heartbeat detection mechanism is usually used between communication devices. The so-called heartbeat detection mechanism is a data packet generated according to a custom protocol and sent cyclically, which is mainly used to determine whether the communication device is in a connected state. The specific performance is that one end sends communication packets regularly, and if it does not receive a response from the other end within a specified time, it is determined that the connection with the other end has been interrupted.

In the prior art, with the opening of the large data transmission mode between the client and the server, the number of clients served by a server will increase. In order to ensure the stability of communication with the server, the client can The heartbeat detection packets are sent to the server periodically for communication detection, which causes a large number of server resources to be occupied by the client's heartbeat detection packets.

SUMMARY OF THE INVENTION

Embodiments of the present application provide a method and apparatus for heartbeat detection, which are used to reduce the occupation of server resources by a client's heartbeat request.

An embodiment of the present application provides a method for heartbeat detection, which is applicable to a system including multiple clients, a first server, and a second server, where the second server is used to provide business services for the client, and the method includes the first server receiving the client The heartbeat request sent. The heartbeat request is used to determine the communication status of the second server. The first server is assigned by the domain name server DNS to the client when it receives the heartbeat domain name resolution request for the second server sent by the client. When the server determines that a valid heartbeat response for the second server is stored, it sends the valid heartbeat response to the client, where the valid heartbeat response is determined based on the communication state between the first server and the second server.

Optionally, after the first server receives the heartbeat request sent by the client, the method further includes: when the first server determines that no valid heartbeat response for the second server is stored, the first server sends a heartbeat request to the second server, and the first server sends a heartbeat request to the second server. The server receives the response indication sent by the second server, and determines a valid heartbeat response according to the response indication, and the first server sends the valid heartbeat response to the client. In this way, the first server can obtain the response indication from the second server under certain conditions, which lays a foundation for the subsequent reception of the heartbeat request.

Optionally, the first server receives the response indication sent by the second server, and determines a valid heartbeat response according to the response indication, including: the first server receives the response indication sent by the second server, and the first server parses the response indication to obtain the heartbeat response. In response, the first server determines the heartbeat response as a valid heartbeat response and saves it locally.

Optionally, the first server receives the response indication sent by the second server, and determines a valid heartbeat response according to the response indication, including: the first server receives the response indication sent by the second server, and the first server obtains the heartbeat locally according to the response indication. response, and determine the heartbeat response as a valid heartbeat response.

Optionally, the heartbeat request includes the identifier of the client, the number of times the client sends the heartbeat request, and the running state of the client. After the first server receives the heartbeat request sent by the client, it also includes: The number of heartbeat requests and the running state of the client generate a heartbeat record of the client, and the first server sends the heartbeat record of the client within a preset period to the second server. In this way, the second server can monitor whether the client is online through the heartbeat record.

Optionally, before the first server receives the heartbeat request sent by the client, it further includes: the first server sends the heartbeat request rule to the client, the heartbeat request rule is used to make the client generate a heartbeat request according to the heartbeat request rule, and the heartbeat request rule is sent by the second server to the first server, and the second server generates a response indication according to the heartbeat request rule. In this way, the first server, the second server and the client can use the heartbeat request rule to unify the standard, and no error is required in the heartbeat detection process.

The application provides a heartbeat detection device, the device includes a receiving unit, a processing unit and a sending unit: the receiving unit is used to receive a heartbeat request sent by a client, the heartbeat request is used to determine the communication state of the second server, and the device is a domain name When the server DNS receives the heartbeat domain name resolution request for the second server sent by the client, the sending unit is allocated to the client, and the sending unit is used for the processing unit to determine that a valid heartbeat response for the second server is stored. A heartbeat response is sent to the client, and the valid heartbeat response is determined based on the communication status between the device and the second server.

Optionally, the sending unit is further configured to send a heartbeat request to the second server when the processing unit determines that no valid heartbeat response for the second server is stored, and the receiving unit is further configured to receive a response indication sent by the second server, The processing unit determines a valid heartbeat response according to the response indication, and the sending unit is further configured to send the valid heartbeat response to the client.

Optionally, the receiving unit is specifically configured to receive a response indication sent by the second server, and the processing unit is specifically configured to parse the response indication to obtain a heartbeat response, determine the heartbeat response as a valid heartbeat response, and save it locally.

Optionally, the receiving unit is specifically configured to receive a response indication sent by the second server, and the processing unit is specifically configured to acquire a valid heartbeat response locally according to the response indication.

Optionally, the heartbeat request includes the identity of the client, the number of times the client sends the heartbeat request, and the running state of the client, and the processing unit is also used to: generate a client according to the identity of the client, the number of times the client sends the heartbeat request, and the running state of the client. The heartbeat record of the client, the sending unit is further configured to send the heartbeat record of the client within a preset period to the second server.

Optionally, the sending unit is also used to: send the heartbeat request rule to the client, the heartbeat request rule is used to make the client generate a heartbeat request according to the heartbeat request rule, the heartbeat request rule is sent to the device by the second server, and the first heartbeat request rule is sent to the device. The second server generates a response indication according to the heartbeat request rule.

In the embodiment of this application, the first server receives a heartbeat request sent by the client, and the heartbeat request is used to determine the communication status of the second server. The first server is the domain name server DNS that receives the heartbeat domain name sent by the client for the second server. When parsing the request, it is assigned to the client. After determining that a valid heartbeat response for the second server is stored, the first server sends the valid heartbeat response to the client. The valid heartbeat response is based on the relationship between the first server and the first server. The communication status between the two servers is determined. In this way, the second server does not need to directly receive the heartbeat request from each client, but responds to the client's heartbeat request through the first server, thereby saving system resources. When the first server receives a heartbeat request from the client, it can first obtain a valid heartbeat response locally and respond directly to the client without sending each received heartbeat request to the second server and requesting the second server. The server provides feedback, which can further reduce the resource occupation of the second server by the heartbeat request.

Description of drawings

In order to illustrate the technical solutions in the embodiments of the present application more clearly, the following briefly introduces the drawings used in the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can also be obtained from these drawings without any creative effort.

1 is a schematic diagram of a suitable system architecture provided by an embodiment of the present application;

2 is a schematic flowchart of a method for heartbeat detection provided by an embodiment of the present application;

3 is a schematic flowchart of a method for heartbeat detection provided by an embodiment of the present application;

FIG. 4 is a schematic structural diagram of an apparatus for heartbeat detection provided by an embodiment of the present application.

Detailed ways

In order to make the objectives, technical solutions and beneficial effects of the present application clearer, the present application will be described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application, but not to limit the present application.

FIG. 1 exemplarily shows a system architecture diagram to which the embodiments of the present application are applied. As shown in FIG. 1 , the system includes multiple clients 101 , a first server 102 and a second server cluster 103 . The second server cluster 103 may include multiple second servers, the multiple second servers in the same server cluster may be servers that provide the same business service for the client 101, and each second server has its own network Protocol (Internet Protocol, IP) address. Secondly, the number of the first servers may be one as shown in FIG. 1 , or multiple first servers may be set according to business requirements, and each first server has its own IP address.

Based on the above system architecture diagram, the communication link between the first server and any second server in the second server cluster may be established before the client sends an access request to the second server, or the communication link between the first server and any second server in the second server cluster may be established before the client sends an access request to the second server. It is established in real time when a server receives a heartbeat request sent by the first client to the second server.

When the client sends a heartbeat request to the second server in the second server cluster, the domain name server (Domain Name Server, DNS) on the client side needs to first parse the target access domain name in the heartbeat request to obtain a specific access address , including the target IP address and the target port, in the embodiment provided by the present invention, when the domain name server recognizes the heartbeat domain name resolution request from the client, it directly allocates the first server to the client, and assigns the access address of the first server to the client. Sent to the client as the parsing result. In this way, the client sends the heartbeat request to the first server based on the domain name resolution result.

When receiving the heartbeat request from the client for the second server, the first server may directly send the locally stored valid heartbeat response to the second server to the client according to the first server.

FIG. 2 exemplarily shows a schematic flowchart of a method for heartbeat detection applicable to an embodiment of the present application, as shown in FIG. 2 , including:

Step 201, the first server receives the heartbeat request sent by the client, and the heartbeat request is used to determine the communication state of the second server; the first server is a domain name server DNS that receives the heartbeat domain name resolution request for the second server sent by the client , allocated for the client;

Step 202, when the first server determines that a valid heartbeat response for the second server is stored, the valid heartbeat response is sent to the client, wherein the valid heartbeat response is based on the communication between the first server and the second server. status confirmed.

In the embodiment of the present application, since the first server receives the heartbeat request sent by the client, the heartbeat request is used to determine the communication status of the second server, and the first server is the domain name server DNS after receiving the heartbeat sent by the client for the second server When a domain name resolution request is made, it is allocated to the client. The first server sends a valid heartbeat response to the client after determining that a valid heartbeat response for the second server is stored. The valid heartbeat response is based on the first server. The communication status with the second server is determined.

In this way, the second server does not need to directly receive the heartbeat request from each client, but responds to the client's heartbeat request through the first server, thereby saving system resources. When the first server receives a heartbeat request from the client, it can first obtain a valid heartbeat response locally and respond directly to the client without sending each received heartbeat request to the second server and requesting the second server. The server provides feedback, which can further reduce the resource occupation of the second server by the heartbeat request.

In this embodiment of the present application, the second server may provide business services for the client, for example, provide video, audio, text, pictures, etc. Therefore, the second server may be referred to as a business server.

In this embodiment of the present application, the first server may be a server that loads Squid software, which may be referred to as a Squid server. Squid is a web-based caching proxy that supports Hyper Text Transfer Protocol (HTTP), Hyper Text Transfer Protocol over Secure Socket Layer (HTTPS) and File Transfer Protocol (File Transfer Protocol). Transfer Protocol, FTP). Squid can reduce bandwidth and improve response time. At the same time, Squid has a flexible access control function, that is, the Squid server can determine which requests are acceptable and which requests are not acceptable. Based on the above functions, Squid is a very Excellent server accelerator.

In addition, Squid can optimize the data between the server and the client to improve performance, and route content requests to the server in various ways, building a cache server structure that can optimize network throughput.

Before step 201, that is, before the first server receives the heartbeat request sent by the client, in an optional implementation manner, a communication link has been established between the first server and the second server cluster, and after the communication link is established, The second server or the second server cluster may send the heartbeat request rule to the first server, and the heartbeat request rule may be sent by the first server to the client after the client and the first server establish a communication link. , so that the client can generate a heartbeat request according to the heartbeat request rule.

Optionally, the heartbeat request rule may include a very small resource class file configured for the client by the second server, such as a TXT file. After receiving the heartbeat request rule, the client parses and obtains the very small resource. class file, and generate a link that can be accessed directly according to the heartbeat request rule. When the client wants to send a heartbeat request, it can access the link to obtain the extremely small resource class file, encapsulate the extremely small resource class file, and send it to the first server as a heartbeat request. The above TXT file can be an empty file. file, the very small resource class file can also be a field or a string. The advantage of the extremely small resource class file is that it occupies less capacity. In this way, when the client sends the heartbeat request to the first server, bandwidth can be saved.

Before step 202, the first server receives the heartbeat request sent by the client, and the first server may determine whether a valid heartbeat response for the second server is stored. In an optional implementation manner, if the first server only stores a valid heartbeat response, the heartbeat response may be directly sent to the client. The heartbeat response is used to determine the communication status between the first server and the second server, that is, if the first server stores a valid heartbeat response, normal communication can be performed between the first server and the second server, that is, the second server can perform normal communication. The server may provide normal business services to the client through the first server.

In another optional implementation manner, the first server receives the heartbeat request and determines that no valid heartbeat response for the second server is stored in the first server, and the first server can send the heartbeat request to the second server, and receiving the response indication sent by the second server, determining a valid heartbeat response according to the response indication, and sending the heartbeat response to the client by the first server.

The following describes how the first server determines a valid heartbeat response according to the received response indication sent by the second server.

After the second server receives the heartbeat request sent by the first server, in the first optional implementation manner, a response indication may be generated according to the heartbeat request. For example, the content of the heartbeat request is "please reply 1", After acquiring the heartbeat request, the second server can parse the heartbeat request, generate "1" according to the content in the heartbeat request, and encapsulate the "1" into a heartbeat response, which is sent to the first server as part of the response indication. Correspondingly, the first server receives the response indication sent by the second server, the first server can obtain a heartbeat response by parsing the response indication, and the first server saves the heartbeat response as a valid heartbeat response locally. The above-mentioned response indication is used to instruct the first server to obtain a heartbeat response from the response indication, and save the heartbeat response as a valid heartbeat response to the local cache of the first server.

In a second optional embodiment, when the first server receives the heartbeat request and determines that the first server does not store a valid heartbeat response for the second server, it can request the heartbeat request according to the heartbeat request rule. A preset mark is marked on the header of the packet, and the marked heartbeat request is sent to the second server. After receiving the marked heartbeat request, the second server obtains the mark, but does not need to parse the specific content of the heartbeat request, and directly sends a heartbeat instruction with a heartbeat response to the first server according to the mark.

Correspondingly, the first server receives the response indication sent by the second server, the first server can obtain a heartbeat response by parsing the response indication, and the first server saves the heartbeat response as a valid heartbeat response locally. The above-mentioned response indication is used to instruct the first server to obtain a heartbeat response from the response indication, and save the heartbeat response as a valid heartbeat response to the local cache of the first server. The processing process that the second server directly returns the response indication with the heartbeat response after obtaining the heartbeat request with the mark is determined according to the heartbeat request rule. That is, the second server may generate a response indication according to the heartbeat request rule.

In the above-mentioned second embodiment, the content in the heartbeat request may be a TXT file, a string or empty, because the second server does not generate a heartbeat response according to the content in the heartbeat request, but based on the heartbeat request rule according to the predetermined Set the flag to generate a heartbeat response. Therefore, the heartbeat response is also determined according to the heartbeat request rule. Therefore, in this manner, when the first server sends the heartbeat request rule to the client, the client can determine that the second server is providing business services for the client according to the received heartbeat response based on the heartbeat request rule.

For example, the client sends a heartbeat request with an empty content according to the received heartbeat request rule. After the first server receives the heartbeat request, it determines that there is no valid heartbeat response stored, and directly marks the packet header after the heartbeat request. a preset mark, and send the heartbeat request with the mark to the second server. After receiving the marked heartbeat request, the second server obtains the mark, and generates a heartbeat response based on the heartbeat request rule and carries it in the response indication, the second server sends the response indication to the first server, and the first server parses the Response indication, get the heartbeat response. The heartbeat response is saved to the local cache of the first server, and the heartbeat response is sent to the client. After the client receives the heartbeat response, it parses the heartbeat response and obtains a special string. According to the information in the heartbeat request rule, the special string may indicate that the second server is providing business services for the client, that is, the second server is currently available.

In the above two manners, when it is determined that no valid heartbeat response for the second server is stored in the first server, a valid heartbeat response is obtained through the response instruction of the second server. Optionally, each heartbeat response can be time-limited. For example, the heartbeat response is valid within five minutes from the second server sending it. During these five minutes, the first server receives any client sending After the heartbeat request is made, the heartbeat request can be directly fed back to the client without requesting a response to the heartbeat request from the second server. Five minutes later, if the first server obtains and receives the heartbeat request, the above process is repeated. In this way, the resource occupancy of the second server by the heartbeat detection data packet (ie, the heartbeat request) of the client can be reduced.

In a third optional implementation manner, the first server receives a response indication sent by the second server, the first server obtains a heartbeat response locally according to the response indication, and takes the heartbeat response as a valid heartbeat response.

In the third method above, since the first server can be a Squid server, optionally, a mandatory cache of the heartbeat response corresponding to the heartbeat request can be configured through the refresh_pattern attribute, that is, the heartbeat response is a local cache that is always stored in the first server. , but it is invalid when the instruction from the second server is not received.

The specific process is described below. The first server sends the heartbeat request to the second server. After receiving the heartbeat request, the second server can generate a response instruction according to the heartbeat request rule. Get the preset stored heartbeat response from the server and feed it back to the client. After receiving the response indication, the first server obtains the heartbeat response from the local cache and sends it to the client.

Optionally, the above-mentioned response indication is time-limited, for example, within five minutes of receiving the response indication, the first server can obtain the heartbeat response in the local cache, that is, within these five minutes, the heartbeat response is Effectively, after five minutes, if the first server obtains and receives the heartbeat request, the above process is repeated. In this way, the resource occupancy of the second server by the heartbeat detection data packet (ie, the heartbeat request) of the client can be reduced. It can be understood that the specific setting of the effective time limit in this specification can be determined based on the actual situation, and is not limited to the embodiments provided in this specification.

In the embodiment of the present application, the Squid server can write a permanently cached resource, and the heartbeat request is equal to requesting a very small resource. As long as the heartbeat request can hit the resource, a heart response can be fed back to the client. In this way, The validity of the heartbeat is guaranteed. Since the Squid server utilizes the native features of Squid, it can support a large number of concurrent heartbeat requests, and due to the fact that Squid itself is rather easy to expand, if the current first server has reached the bottleneck of receiving heartbeat requests, you can add hardware on this basis. , and then deploy Squid to expand the heartbeat service. In addition, the Squid server can write scripts at one time, and it has been installed, deployed and maintained.

In an optional embodiment, the heartbeat request includes the identity of the client, the number of times the client sends the heartbeat request, and the operating state of the client. After the first server receives the heartbeat request sent by the client, the first server The number of heartbeat requests sent by the client and the running state of the client generate a heartbeat record of the client, and the first server sends the heartbeat record of the client within a preset period to the second server.

Specifically, three parameter values, index, status and cliented, are added to the heartbeat request. Index is mainly used to indicate that the current heartbeat request of the client is the number of heartbeat requests, and status is used to indicate the status of the current client (whether there is a problem with payment, etc.) ), cliented is used to represent the identity of the client.

E.g:

http://heartbeat_domian.com:port/heartbeat? inde=11&status=1& client=111111

The domain name or IP address of the first server of the above heartbeat_domian, port is the port that the first server listens on, index is 11 to indicate that this client has sent a heartbeat request for the 11th time, and status of 1 indicates that the current client access is normal and the client has no Any other questions, cliented means that the heartbeat request was sent by the client identified as 111111.

Optionally, if the client 111111 disconnects after sending several heartbeat requests to the first server, after re-establishing a connection with the first server, the number of times of sending heartbeat requests can be reset to 0.

The first server may use the identifier of the client as a reference, classify the number of heartbeat requests of the client and the running state of the client carried in each heartbeat request, and generate a heartbeat record of the client. Optionally, the first server may send the heartbeat record of each client to the second server within a preset time period.

Optionally, the first server may send the heartbeat record of the client whose running state is abnormal to the second server. Optionally, the first server may send the heartbeat records of the several times when the running state of the client whose running state is abnormal is abnormal. The record is sent to the second server. In this way, the second server can count the online status and network status implemented by all clients, so as to facilitate operation monitoring of a large number of clients.

Optionally, an ACL rule may be added to forcibly transfer the heartbeat request to a very small resource class file of the second server, that is, the content of the heartbeat request may be saved on the second server in a particularly small file format.

FIG. 3 exemplarily shows a schematic flowchart of a method for heartbeat detection applicable to an embodiment of the present application, as shown in FIG. 3 , including:

Step 301, after the first server and the second server cluster have established a communication link, the second server can send the heartbeat request rule to the first server;

Step 302, when the client accesses the second server cluster, it obtains the address of the first server through DNS. After the client and the first server establish a communication link, the first server sends the heartbeat request rule to the client;

Step 303, the client generates a heartbeat request according to the heartbeat request rule, and the heartbeat request includes the identity of the client, the number of times the client sends the heartbeat request and the running state of the client;

Step 304, the client sends the heartbeat request to the first server;

Step 305, after the first server receives the heartbeat request, generates the heartbeat record of the client according to the identity of the client, the number of times the client sends the heartbeat request and the operating state of the client;

Step 306, the first server judges whether there is a valid heartbeat response for the second server stored, if so, go to step 307, if not, go to step 309;

Step 307, the first server obtains an effective heartbeat response from the local cache;

Step 308, the first server sends the heartbeat response to the client.

Step 309, the first server may send a heartbeat request to the second server;

Step 310, the second server generates a response indication according to the heartbeat request;

Step 311, the second server sends the response indication to the first server;

Step 312, the first service determines an effective heartbeat response according to the response indication, and stores the heartbeat response in the local cache;

Step 313, the first server sends the heartbeat response to the client.

Step 314, the first server sends the heartbeat record of the client to the second server.

In an optional implementation manner, the Squid software can be directly installed on the second server, that is, the second server and the Squid software are combined. In this way, the investment of intermediate equipment can be saved within a certain period of time, and the cost can be saved.

Based on the above embodiments and the same concept, the figure shows a schematic structural diagram of an apparatus provided by an embodiment of the present application. As shown in FIG.

The application provides a heartbeat detection device, the device includes a receiving unit, a processing unit and a sending unit: the receiving unit is used to receive a heartbeat request sent by a client, the heartbeat request is used to determine the communication state of the second server, and the device is a domain name When the server DNS receives the heartbeat domain name resolution request for the second server sent by the client, the sending unit is allocated to the client, and the sending unit is used for the processing unit to determine that a valid heartbeat response for the second server is stored. A heartbeat response is sent to the client, and a valid heartbeat response is determined based on the communication status between the device and the second server.

In the embodiment of the present application, since the heartbeat request sent by the client is received, the heartbeat response is sent to the client after it is determined that a valid heartbeat response for the second server is stored, and the heartbeat response is based on the first server and the second server. The communication status between them is determined. In this way, the second server does not need to directly receive the heartbeat request from each client, but responds to the client's heartbeat request through the device, thereby saving system resources. When the device receives a heartbeat request from a client, it can first obtain a valid heartbeat response locally, and directly respond to the client, without sending each received heartbeat request to the second server and requesting the second server By making feedback, the resource occupation of the second server by the heartbeat request can be further reduced.

In an optional embodiment, the sending unit is further configured to send a heartbeat request to the second server when the processing unit determines that no valid heartbeat response for the second server is stored, and the receiving unit is further configured to receive the second server. The sent response indication is determined by the processing unit as a valid heartbeat response according to the response indication, and the sending unit is further configured to send the heartbeat response to the client.

In an optional embodiment, the receiving unit is specifically used to receive the response indication sent by the second server, and the processing unit is specifically used to parse and obtain the heartbeat response from the response indication, determine the heartbeat response as a valid heartbeat response and save it. to local.

In an optional implementation manner, the receiving unit is specifically configured to receive a response indication sent by the second server, and the processing unit is specifically configured to acquire a heartbeat response locally according to the response indication, and determine the heartbeat response as a valid heartbeat response.

In an optional embodiment, the heartbeat request includes the identity of the client, the number of times the client sends the heartbeat request and the operating state of the client, and the processing unit is also used for: according to the client's identity, the number of times the client sends the heartbeat request, and the client. The running state of the terminal generates a heartbeat record of the client, and the sending unit is further configured to send the heartbeat record of the client within a preset period to the second server.

In an optional embodiment, the sending unit is also used to: send the heartbeat request rule to the client, the heartbeat request rule is used to make the client generate a heartbeat request according to the heartbeat request rule, and the heartbeat request rule is sent by the second server to the client. device, and the second server generates a response indication according to the heartbeat request rule.

For a specific description of the heartbeat detection device provided by the embodiment of the present application, reference may be made to the heartbeat detection method provided by the above embodiment, and details are not repeated here.

It should be noted that the division of units in the embodiments of the present application is illustrative, and is only a logical function division, and other division methods may be used in actual implementation. Each functional unit in the embodiments of the present application may be integrated into one processing unit, or each unit may exist physically alone, or two or more units may be integrated into one unit. The above-mentioned integrated units may be implemented in the form of hardware, or may be implemented in the form of software functional units.

In a computer apparatus provided by an embodiment of the present application, the computer device may include a memory, a transceiver, and a processor.

The memory can be used to store instructions and data. The memory can mainly include a storage instruction area and a storage data area, and the storage data area can store association relationships; the storage instruction area can store the operating system, instructions required for at least one function, etc.; Execute the following method, and the specific method includes: the first server receives a heartbeat request sent by the client, the heartbeat request is used to determine the communication state of the second server, and the first server is the domain name server DNS after receiving the message sent by the client for the second server. When the heartbeat domain name resolution request is made, it is allocated to the client. When the first server determines that a valid heartbeat response for the second server is stored, it sends the valid heartbeat response to the client. The valid heartbeat response is based on the first server and the second server. The communication status between the second servers is determined.

The processor is the control center of the computer equipment. It uses various interfaces and lines to connect various parts of the entire mobile phone, and executes various functions and processing of the computer equipment by running or executing the instructions stored in the memory and calling the data stored in the memory. data. Optionally, the processor may include one or more processing units; optionally, the processor may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, etc. The modem processor mainly handles wireless communication. In some embodiments, the processor and memory may be implemented on a single chip, or in some embodiments, they may be implemented separately on separate chips.

The above embodiments may be implemented in whole or in part by software, hardware, firmware or any combination thereof, and when implemented using software programs, may be implemented in whole or in part in the form of computer program products. The computer program product includes one or more instructions. When the computer program instructions are loaded and executed on a computer, the procedures or functions according to the embodiments of the present application are generated in whole or in part. The computer may be a general purpose computer, a special purpose computer, a computer network, or other programmable device. Instructions may be stored in or transmitted from one computer storage medium to another computer storage medium, for example, instructions may be transmitted from a website site, computer, server, or data center via wireline (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (eg, infrared, wireless, microwave, etc.) to another website site, computer, server, or data center. A computer storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, or the like that contains an integration of one or more available media. Useful media may be magnetic media (eg, floppy disk, hard disk, magnetic tape, magneto-optical disk (MO), etc.), optical media (eg, CD, DVD, BD, HVD, etc.), or semiconductor media (eg, ROM, EPROM, EEPROM, Non-volatile memory (NAND FLASH), solid state disk (Solid State Disk, SSD), etc.

Those skilled in the art should understand that the embodiments of the present application may be provided as a method, a system, or a computer program product. Accordingly, the embodiments of the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

The embodiments of the present application are described with reference to flowcharts and/or block diagrams of methods, apparatuses, and computer program products according to the embodiments of the present application. It will be understood that each flow and/or block in the flowcharts and/or block diagrams, and combinations of flows and/or blocks in the flowcharts and/or block diagrams, can be implemented by instructions. These instructions may be provided to the processor of a general purpose computer, special purpose computer, embedded processor or other programmable data processing device to produce a machine such that execution of the instructions by the processor of the computer or other programmable data processing device produces a A means for the functions specified in a flow or flows of a flowchart and/or a block or blocks of a block diagram.

The instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory result in an article of manufacture comprising instruction means that implements A function specified in a flow or flow of a flowchart and/or a block or blocks of a block diagram.

The instructions may also be loaded on a computer or other programmable data processing device such that a series of operational steps are performed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide Steps for implementing the function specified in one or more of the flowcharts and/or one or more blocks of the block diagrams.

Obviously, those skilled in the art can make various changes and modifications to the embodiments of the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the embodiments of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims (12)

1. A method for heartbeat detection, characterized in that it is applicable to a system comprising a plurality of clients, a first server and a second server, and the second server is used to provide business services for the client; the method include: The first server receives the heartbeat request sent by the client, and the heartbeat request is used to determine the communication state of the second server; the first server is the domain name server DNS after receiving the target sent by the client. When the heartbeat domain name resolution request of the second server is requested, it is allocated for the client; When the first server determines that a valid heartbeat response for the second server is stored, the valid heartbeat response is sent to the client, and the valid heartbeat response is based on the relationship between the first server and the client. The communication status between the second servers is determined. 2. The method according to claim 1, wherein after the first server receives the heartbeat request sent by the client, the method further comprises: When the first server determines that no valid heartbeat response for the second server is stored, the first server sends the heartbeat request to the second server; The first server receives the response indication sent by the second server, and determines a valid heartbeat response according to the response indication; The first server sends the valid heartbeat response to the client. 3. The method of claim 2, wherein the first server receives a response indication sent by the second server, and determines a valid heartbeat response according to the response indication, comprising: receiving, by the first server, the response indication sent by the second server; The first server obtains a heartbeat response by parsing the response indication; The first server determines the heartbeat response as the valid heartbeat response and saves it locally. 4. The method of claim 2, wherein the first server receives a response indication sent by the second server, and determines a valid heartbeat response according to the response indication, comprising: receiving, by the first server, the response indication sent by the second server; The first server obtains a heartbeat response locally according to the response indication, and determines the heartbeat response as a valid heartbeat response. 5. The method of claim 1, wherein the heartbeat request comprises the identity of the client, the number of times the client sends the heartbeat request and the running state of the client; After the first server receives the heartbeat request sent by the client, the method further includes: The first server generates a heartbeat record of the client according to the identifier of the client, the number of times the client sends a heartbeat request, and the running state of the client; The first server sends the heartbeat record of the client within a preset period to the second server. 6. The method according to any one of claims 1 to 5, wherein before the first server receives the heartbeat request sent by the client, the method further comprises: The first server sends a heartbeat request rule to the client; the heartbeat request rule is used to make the client generate the heartbeat request according to the heartbeat request rule; The heartbeat request rule is sent by the second server to the first server, and the second server generates a response indication according to the heartbeat request rule. 7. A device for heartbeat detection, wherein the device comprises a receiving unit, a processing unit and a sending unit: The receiving unit is configured to receive a heartbeat request sent by the client, where the heartbeat request is used to determine the communication state of the second server; When the second server's heartbeat domain name resolves a request, it is allocated for the client; The sending unit is configured to send the valid heartbeat response to the client when the processing unit determines that a valid heartbeat response for the second server is stored, and the valid heartbeat response is based on the valid heartbeat response. The communication state between the device and the second server is determined. 8. The apparatus of claim 7, wherein The sending unit is further configured to send the heartbeat request to the second server when the processing unit determines that no valid heartbeat response for the second server is stored; The receiving unit is further configured to receive a response indication sent by the second server, and determine a valid heartbeat response according to the response indication by the processing unit; The sending unit is further configured to send the valid heartbeat response to the client. 9. The apparatus of claim 8, wherein The receiving unit is specifically configured to receive the response indication sent by the second server; The processing unit is specifically configured to parse and obtain a heartbeat response from the response indication; determine the heartbeat response as the valid heartbeat response and save it locally. 10. The apparatus of claim 8, wherein The receiving unit is specifically configured to receive the response indication sent by the second server; The processing unit is specifically configured to obtain the valid heartbeat response locally according to the response indication. 11. The apparatus according to claim 7, wherein the heartbeat request comprises the identity of the client, the number of times the client sends the heartbeat request and the running state of the client; The processing unit is also used for: Generate a heartbeat record of the client according to the identifier of the client, the number of times the client sends a heartbeat request, and the running state of the client; The sending unit is further configured to send the heartbeat record of the client within a preset period to the second server. 12. The apparatus according to any one of claims 7 to 11, wherein the sending unit is further configured to: sending the heartbeat request rule to the client; the heartbeat request rule is used to make the client generate the heartbeat request according to the heartbeat request rule; The heartbeat request rule is sent by the second server to the device, and the second server generates a response indication according to the heartbeat request rule.

Images