CN107172230B - Method for realizing service node communication address discovery based on third-party database - Google Patents

Method for realizing service node communication address discovery based on third-party database Download PDF

Info

Publication number
CN107172230B
CN107172230B CN201710604968.9A CN201710604968A CN107172230B CN 107172230 B CN107172230 B CN 107172230B CN 201710604968 A CN201710604968 A CN 201710604968A CN 107172230 B CN107172230 B CN 107172230B
Authority
CN
China
Prior art keywords
service
service process
zookeeper
business
keep
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.)
Active
Application number
CN201710604968.9A
Other languages
Chinese (zh)
Other versions
CN107172230A (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.)
Beijing Certusnet Information Technology Co ltd
Original Assignee
Beijing Certusnet Information 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 Beijing Certusnet Information Technology Co ltd filed Critical Beijing Certusnet Information Technology Co ltd
Priority to CN201710604968.9A priority Critical patent/CN107172230B/en
Publication of CN107172230A publication Critical patent/CN107172230A/en
Application granted granted Critical
Publication of CN107172230B publication Critical patent/CN107172230B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00Network arrangements, protocols or services for addressing or naming
    • H04L61/50Address allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/16Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Computer And Data Communications (AREA)

Abstract

The invention relates to a method for realizing service node communication address discovery based on a third-party database, which comprises a link establishment processing operation and a keep-alive state maintenance processing operation, wherein the link establishment processing operation comprises the following steps: (1) establishing a service process, linking all the service processes with a zookeeper dynamic library, and starting a zookeeper server; (2) starting all business processes; (3) all business processes create zookeeper database nodes in different tree forms to a zookeeper client according to a preset communication model; (4) the business process observes the database node of the opposite terminal; (5) after an opposite terminal is on line and a communication address of the opposite terminal is obtained, establishing a tcp link with the opposite terminal and sending service data; the keep-alive state maintaining processing operation is specifically as follows: and carrying out periodic keep-alive detection between the zookeeper server side, the zookeeper client side and all the service processes. By adopting the method, the communication address of the opposite terminal can be obtained, and the method has double keep-alive mechanisms, greatly improves the judgment accuracy of the offline event between the service processes, avoids the phenomenon that the offline event of the opposite terminal is judged by mistake, and has wide application range.

Description

Method for realizing service node communication address discovery based on third-party database
Technical Field
The invention relates to the technical field of communication, in particular to the technical field of a communication address discovery mechanism, and specifically relates to a method for realizing service node communication address discovery based on a third-party database.
Background
In a traditional brass (Broadband Remote Access Server) device, a control plane and a forwarding plane are both proprietary customized single boards, and data exchange is performed between the single boards through a backplane of a rack. The whole rack environment is fixed, stable and integral, so that when data interaction is carried out between single boards or service processes in the single boards, fixed logical addresses can be adopted, for example, when tipc is adopted as a bottom layer communication mechanism, the fixed and unchangeable logical addresses can be compiled according to information such as rack numbers, slot numbers, cpu numbers, service numbers and the like. Therefore, after each business process is started, data can be directly sent to other business processes.
However, in the vbars device, the control plane and the forwarding plane are both common servers, and even virtual machines or docker (an open source application container engine) instances. Servers, virtual machines, may be cross-operating system, even servers deployed at different address locations. Then, when the service process between the control plane and the forwarding plane needs to perform data communication, the fixed logical address cannot be used, and a physical address needs to be used for communication.
Disclosure of Invention
The invention aims to overcome the defects of the prior art and provides a method for realizing service node communication address discovery based on a third-party database.
In order to achieve the above object, the present invention has the following configurations:
the method for realizing the service node communication address discovery based on the third-party database comprises a link establishment processing operation and a keep-alive state maintaining processing operation, wherein the link establishment processing operation comprises the following steps:
(1) creating a first service process, a second service process and a third service process, linking the first service process, the second service process and the third service process to a zookeeper dynamic library, and starting a zookeeper server;
(2) starting the first service process, the second service process and the third service process, wherein the first service process, the second service process and the third service process respectively create corresponding zookeeper clients, and each zookeeper client registers with the zookeeper server;
(3) the first service process, the second service process and the third service process create zookeeper database nodes in different tree shapes for the zookeeper client according to a preset communication model;
(4) the first service process, the second service process and the third service process respectively observe database nodes of opposite-end service processes corresponding to the first service process, the second service process and the third service process;
(5) after the first service process, the second service process and the third service process are online in the corresponding opposite-end service process and obtain the communication address of the corresponding opposite-end service process, establishing a tcp (Transmission Control Protocol) link with the corresponding opposite-end service process, and sending service data;
the keep-alive state maintaining processing operation is specifically as follows:
and carrying out periodic keep-alive detection between the zookeeper server and the zookeeper client as well as the first business process, the second business process and the third business process. Preferably, the step (3) specifically includes the following steps:
(3-1) the first business process creates a database node/business name 1/server to the zookeeper client, and writes a communication address of the first business process into the server node;
(3-2) the second service process and the third service process respectively create database nodes "/service name 1/clients/service name 2" and "/service name 1/clients/service name 3" for the zookeeper client, and correspondingly write the communication addresses of the second service process and the third service process into the "service name 2" node and the "service name 3" node.
In a better embodiment, in the step (3-2), when the communication address is issued to the opposite service process, two types of addresses are issued simultaneously: unix addresses and inet addresses, wherein, a) unix addresses (convenient for host internal node connection); b) let address (facilitate node connection on different host).
In a preferred embodiment, the first service process is a data server, the second service process and the third service process are data clients, and the step (4) specifically includes the following steps:
(4-1) after the database node is created by the first business process, the first business process observes a parent node "/business name 1/clients" of the database node created by the associated data client, judges whether a plurality of clients are online, and if yes, continues to the step (4-2);
(4-2) the first service process reads the communication addresses of the second service process and the third service process from database nodes of "/service name 1/clients/service name 2" and "/service name 1/clients/service name 3";
(4-3) after the second service process and the third service process complete the creation of the database node, judging whether the database node "/service name 1/server" exists, if so, reading the communication address of the first service process.
In a preferred embodiment, the keep-alive state maintaining processing operation specifically includes a third-party database processing sub-process for maintaining the keep-alive state and a business process self-processing sub-process for maintaining the keep-alive state.
In a preferred embodiment, the third party database process for maintaining keep-alive status comprises the following steps:
(5-1-1) the zookeeper server judges whether the zookeeper client keep-alive timeout exists or not, if so, deletes the database node once created by the zookeeper client, and informs the zookeeper client of observing the deleted node;
(5-1-2) closing a tcp link when the zookeeper client notifies the deletion events of the observation nodes of the first business process, the second business process and the third business process respectively;
(5-1-3) when the zookeeper client notifies the addition events of the observation nodes of the first service process, the second service process and the third service process, the first service process checks the current state of the corresponding opposite-end service process, the second service process checks the current state of the corresponding opposite-end service process, and the third service process checks the current state of the corresponding opposite-end service process;
in a preferred embodiment, the business process self-processing subprocess for maintaining keep-alive state comprises the following steps:
(5-2-1) establishing two links among the first service process, the second service process and the third service process;
and (5-2-2) creating new threads in the first business process, the second business process and the third business process.
In a preferred embodiment, in the step (5-1-3), the step of respectively checking the current states of the corresponding opposite-end service processes by the first service process, the second service process, and the third service process specifically includes the following steps:
(5-1-3-1) if the current states of the opposite end service processes corresponding to the first service process, the second service process and the third service process are off-line states, continuing the step (5-1-3-2), otherwise, continuing the step (5-1-3-3);
(5-1-3-2) starting an online process;
(5-1-3-3) the first service process, the second service process and the third service process obtain the communication address of the corresponding opposite terminal service process in the observation node, judge whether the change occurs, if the change occurs, continue the step (5-1-3-3-1), otherwise, continue the step (5-1-3-3-2);
(5-1-3-3-1) closing the tcp link before the first service process, the second service process and the third service process, establishing a new tcp link according to the new address, simultaneously judging whether the service processes of the two parties are in the same host, and if the service processes of the two parties are in the same host, simultaneously establishing two links by using unix addresses; if the business processes of the two parties are in different host, using an inet address to establish two links simultaneously;
(5-1-3-3-2) the first service process, the second service process and the third service process filter the corresponding opposite-end service online events of the first service process, the second service process and the third service process.
In a preferred embodiment, in the step (5-2-2) of creating a new thread, the process of maintaining the keep-alive state by the new thread includes:
(5-2-2-1) periodically sending the keep-alive messages;
(5-2-2-2) receiving keep-alive messages among the opposite-end service processes corresponding to the first service process, the second service process and the third service process, wherein the first service process, the second service process and the third service process are Epoll.
In a preferred embodiment, it is characterized in that in the step (5-1-3-3-1), in establishing a new tcp link, the MD5 option needs to be set.
In a preferred embodiment, the two links perform keep-alive detection and load sharing of traffic data transmission.
In a preferred embodiment, the keep-alive detection specifically includes the following steps: (9-1) the two links respectively detect whether the opposite end service processes corresponding to the first service process, the second service process and the third service process are offline, if so, continuing the step (9-1-1), otherwise, continuing the step (9-1-2);
(9-1-1) confirming that the corresponding opposite end business process is really offline;
(9-1-2) confirming that the corresponding opposite end business process is not offline.
By adopting the method for realizing the service node communication address discovery based on the third-party database, the service process can dynamically discover the online and offline events of the communication opposite end in the vBras environment; meanwhile, the method can also acquire the communication address of the opposite terminal, has dual keep-alive mechanisms, and greatly improves the judgment accuracy of the offline event between the service processes. The method avoids unnecessary repetitive mass data sent among business processes due to the fact that the offline event of the opposite end is judged by mistake, so that the stability of the whole business process in the vBras environment is improved, and the method has a wide application range.
Drawings
Fig. 1 is a schematic diagram of a method for implementing service node communication address discovery based on a third-party database according to the present invention.
Detailed Description
In order to more clearly describe the technical contents of the present invention, the following further description is given in conjunction with specific embodiments.
The method for realizing the service node communication address discovery based on the third-party database comprises a link establishment processing operation and a keep-alive state maintaining processing operation, wherein the link establishment processing operation comprises the following steps:
(1) creating a first service process, a second service process and a third service process, linking all the service processes to a zookeeper dynamic library, and starting a zookeeper server;
(2) starting all business processes, registering to the zookeeper, and creating a zookeeper client;
(3) all business processes create zookeeper database nodes in different tree forms to the zookeeper client according to a preset communication model;
(4) observing a database node of an opposite-end service process;
(5) after an opposite terminal is on line and a communication address of the opposite terminal is obtained, establishing a tcp link with the opposite terminal and sending service data;
the keep-alive state maintaining processing operation is specifically as follows:
and carrying out periodic keep-alive detection between the zookeeper server and the zookeeper client.
In a preferred embodiment, the step (3) specifically includes the following steps:
(3-1) the first business process creates a database node/business name 1/server to the zookeeper client, and writes a communication address of the first business process into the server node;
(3-2) the second service process and the third service process respectively create database nodes "/service name 1/clients/service name 2" and "/service name 1/clients/service name 3" for the zookeeper client, and correspondingly write the communication addresses of the second service process and the third service process into the "service name 2" node and the "service name 3" node.
In a better embodiment, in the step (3-2), when the communication address is issued to the opposite service process, two types of addresses are issued simultaneously: unix addresses and inet addresses, wherein, a) unix addresses (convenient for host internal node connection); b) let address (facilitate node connection on different host).
In a preferred embodiment, the first service process is a data server, the second service process and the third service process are data clients, and the step (4) specifically includes the following steps:
(4-1) after the database node is created by the first business process, the first business process observes a parent node "/business name 1/clients" of the database node created by the associated data client, judges whether a plurality of clients are online, and if yes, continues to the step (4-2);
(4-2) the first service process reads the communication addresses of the second service process and the third service process from database nodes of "/service name 1/clients/service name 2" and "/service name 1/clients/service name 3";
(4-3) after the second service process and the third service process complete the creation of the database node, judging whether the database node "/service name 1/server" exists, if so, reading the communication address of the first service process.
In a preferred embodiment, the keep-alive state maintaining processing operation specifically includes a third-party database processing sub-process for maintaining the keep-alive state and a business process self-processing sub-process for maintaining the keep-alive state.
In a preferred embodiment, the third party database process for maintaining keep-alive status comprises the following steps:
(5-1-1) the zookeeper server judges whether the zookeeper client keep-alive timeout exists or not, if so, deletes the database node once created by the zookeeper client, and informs the zookeeper client of observing the deleted node;
(5-1-2) closing a tcp link when the zookeeper client notifies the deletion events of the observation nodes of the first business process, the second business process and the third business process respectively;
(5-1-3) when the zookeeper client notifies the addition events of the observation nodes of the first service process, the second service process and the third service process, the first service process checks the current state of the corresponding opposite-end service process, the second service process checks the current state of the corresponding opposite-end service process, and the third service process checks the current state of the corresponding opposite-end service process;
in a preferred embodiment, the business process self-processing subprocess for maintaining keep-alive state comprises the following steps:
(5-2-1) establishing two links among the first service process, the second service process and the third service process;
and (5-2-2) creating new threads in the first business process, the second business process and the third business process.
In a preferred embodiment, in the step (5-1-3), the step of respectively checking the current states of the corresponding opposite-end service processes by the first service process, the second service process, and the third service process specifically includes the following steps:
(5-1-3-1) if the current states of the opposite end service processes corresponding to the first service process, the second service process and the third service process are off-line states, continuing the step (5-1-3-2), otherwise, continuing the step (5-1-3-3);
(5-1-3-2) starting an online process;
(5-1-3-3) the first service process, the second service process and the third service process obtain the communication address of the corresponding opposite terminal service process in the observation node, judge whether the change occurs, if the change occurs, continue the step (5-1-3-3-1), otherwise, continue the step (5-1-3-3-2);
(5-1-3-3-1) closing the tcp link before the first service process, the second service process and the third service process, establishing a new tcp link according to the new address, simultaneously judging whether the service processes of the two parties are in the same host, and if the service processes of the two parties are in the same host, simultaneously establishing two links by using unix addresses; if the business processes of the two parties are in different host, using an inet address to establish two links simultaneously;
(5-1-3-3-2) the first service process, the second service process and the third service process filter the corresponding opposite-end service online events of the first service process, the second service process and the third service process.
In a preferred embodiment, in the step (5-2-2) of creating a new thread, the process of maintaining the keep-alive state by the new thread includes:
(5-2-2-1) periodically sending the keep-alive messages;
(5-2-2-2) receiving keep-alive messages among opposite-end service processes corresponding to the first service process, the second service process and the third service process, wherein Epoll is the most basic message daemon process of the linux process and comprises a set of function calls.
In a preferred embodiment, it is characterized in that in the step (5-1-3-3-1), in establishing a new tcp link, the MD5 option needs to be set.
In a preferred embodiment, the two links perform keep-alive detection and load sharing of traffic data transmission.
In a preferred embodiment, the keep-alive detection specifically includes the following steps:
(9-1) the two links respectively detect whether the opposite end service processes corresponding to the first service process, the second service process and the third service process are offline, if so, continuing the step (9-1-1), otherwise, continuing the step (9-1-2);
(9-1-1) confirming that the corresponding opposite end business process is really offline;
(9-1-2) confirming that the corresponding opposite end business process is not offline.
In one embodiment, the steps are as follows:
1. each business process needs to link a zookeeper dynamic library;
2. starting a zookeeper server preferentially;
3. after the business processes 1, 2 and 3 are started, registering the zookeeper and creating a zookeeper client;
4. and the business processes 1, 2 and 3 create different tree-shaped zookeeper database nodes for the zookeeper client according to the designed communication model. For example, the service process 1 is a data server, and the service processes 2 and 3 are data clients, and receiving the service data sent by the service process 1 specifically includes:
the business process 1 creates a database node to a zookeeper client: "/service name 1/server", and simultaneously writing own communication address, such as server ip address, monitoring port number into the "server" node;
the service processes 2 and 3 respectively create database nodes of a service name 1/clients/service name 2 and a service name 1/clients/service name 3 to the zookeeper client, and simultaneously, the service processes 2 and 3 respectively write corresponding communication addresses into the service name 2 and service name 3 nodes, such as ip addresses of servers where the services are located, specified port numbers and first-class addresses: unix addresses (facilitating the establishment of links by business processes within the host); address of the second type: the inet address (which facilitates the establishment of links for business processes on different hosts) and two per-type addresses are written, which facilitates the establishment of two links between a first business process and a second business process, and between a first business process and a third business process.
When passing through a third-party database, determining service points up/down by directly using a method provided by a client and a server of the database, directly adding a keep-alive mechanism between service nodes to judge the up/down of the service nodes, and once the service nodes are successfully linked, even if the service nodes are down of the database, the link between the service nodes is not influenced, so that the reliability between the service nodes is greatly improved, wherein the up means the online of an opposite-end service process, and the down means the offline of an opposite-end service;
5. after creating the database node of the business process 1, the business process needs to observe the database node of the client. For example, observe database node parent "/service name 1/clients". If multiple clients are online, the zookeeper database node will exist: "/service name 1/clients/service name 2" and "/service name 1/clients/service name 3". The business process 1 reads the communication addresses of the business processes 2, 3 from the two database nodes. Thus, the business process 1 dynamically discovers the business processes 2 and 3 and simultaneously acquires the communication addresses of the business processes;
6. after the business processes 2 and 3 create their own database nodes, they need to observe the database nodes of the server. For example, observe database node "/service name 1/server". If the database node exists, the communication address of the business process 1 is read. Thus, the service process 2 or 3 dynamically discovers the service process 1 and obtains a communication address of the server;
7. after dynamically discovering the online of the opposite terminal and acquiring the communication address of the opposite terminal, a tcp link can be established with the opposite terminal and service data is sent;
8. periodic keep-alive detection is carried out between the Zookeeper server and the client. And when discovering that a certain client keeps alive overtime, the Zookeeper server deletes the database node once created by the client. And notify the zookeeper client that observed the deleted node. When the zookeeper client notifies the service processes 1, 2 and 3 that the client observes the deletion event of the node, the service process dynamically finds that the service process of the opposite terminal is offline, and at this time, the tcp link needs to be closed, so that the service data is not sent to the opposite terminal any more.
Since zookeeper server and client are alive through tcp link, and they may be in different physical locations. Then they are susceptible to keep-alive shock from network congestion. However, the network between the business processes that communicate data may not be congested and tcp delinking may not occur. At this time, if the opposite end is immediately judged to be offline according to the database node deletion event notified by the zookeeper client, misjudgment will inevitably occur. Because the communication data volume between the business processes may be very large, for example, 100 mbps of routes, and after discovering that the data client is on-line again, the data server needs to send all the data to the opposite end again. Such misjudgment inevitably causes the system among the business processes to busy seize resources such as cpu, and the like, thereby affecting the normal operation of other business processes in the system.
The specific improvement implementation steps are as follows:
9.1, after dynamically discovering that the opposite terminal is on line and establishing tcp link, the service process not only sends normal service data, but also periodically sends keep-alive messages. And starting a keep-alive detection timer;
9.2 after the service process receives the normal service data of the opposite terminal or the keep-alive message, resetting the keep-alive detection timer;
9.3, when the zookeeper client notifies the service process of the deletion event of the observation node, the service process checks whether the keep-alive detection timer of the opposite terminal is overtime, if not, the opposite terminal is considered not to be offline, and data transmission is continued;
9.4, when the service process finds that the keep-alive detection timer of the opposite end is overtime, the opposite end is considered to be offline no matter whether the zookeeper client notifies the deletion event of the observation node, and the tcp link is closed at the moment;
9.5, when the zookeeper client notifies the service process of the creation event of the observation node, the service process checks the current state of the observation node with the current state of the opposite terminal:
if the current opposite end is in an offline state, a normal online process is carried out according to the process;
if the current opposite terminal is in an online state, acquiring an opposite terminal communication address in the observation node, and if the current opposite terminal is not changed, filtering the notification event at the moment; if so, closing the previous tcp link and then reestablishing the tcp link according to the new address;
when the service node writes the communication address of the node into a third-party database, some link security measures, such as MD5, a public key and the like, are added, so that the link security between the service nodes can be ensured, and the attack is avoided;
the MD5 option needs to be set when a new tcp link is established. When receiving the TCP message, the receiving party must calculate the MD5 digest according to the message information and its own secret key, and compare the message digest with the MD5 digest in the message. If the comparison fails, the message is discarded. This can greatly improve the security of the link.
By adopting the method for realizing the service node communication address discovery based on the third-party database, the service process can dynamically discover the online and offline events of the communication opposite end in the vBras environment; meanwhile, the method can also acquire the communication address of the opposite terminal, has dual keep-alive mechanisms, and greatly improves the judgment accuracy of the offline event between the service processes. The method avoids unnecessary repetitive mass data sent among business processes due to the fact that the offline event of the opposite end is judged by mistake, so that the stability of the whole business process in the vBras environment is improved, and the method has a wide application range.
In this specification, the invention has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

Claims (9)

1. A method for realizing service node communication address discovery based on a third-party database is characterized in that the method comprises a link establishment processing operation and a keep-alive state maintaining processing operation, and the link establishment processing operation comprises the following steps:
(1) creating a first service process, a second service process and a third service process, linking the first service process, the second service process and the third service process to a zookeeper dynamic library, and starting a zookeeper server;
(2) starting the first service process, the second service process and the third service process, wherein the first service process, the second service process and the third service process respectively create corresponding zookeeper clients, and each zookeeper client registers with the zookeeper server;
(3) the first service process, the second service process and the third service process create zookeeper database nodes in different tree shapes for the zookeeper client according to a preset communication model;
(4) the first service process, the second service process and the third service process respectively observe database nodes of opposite-end service processes corresponding to the first service process, the second service process and the third service process;
(5) after the first service process, the second service process and the third service process are online on the corresponding opposite terminal service process and obtain the communication address of the corresponding opposite terminal service process, establishing tcp link with the corresponding opposite terminal service process and sending service data;
the keep-alive state maintaining processing operation is specifically as follows:
carrying out periodic keep-alive detection among the zookeeper server, the zookeeper client, the first business process, the second business process and the third business process;
the keep-alive state maintaining and processing operation comprises a third-party database processing subprocess for maintaining the keep-alive state and a business process self processing subprocess for maintaining the keep-alive state, wherein the third-party database processing subprocess for maintaining the keep-alive state comprises the following steps:
(5-1-1) the zookeeper server judges whether the zookeeper client keep-alive timeout exists or not, if so, deletes the database node once created by the zookeeper client, and informs the zookeeper client of observing the deleted node;
(5-1-2) closing a tcp link when the zookeeper client notifies the deletion events of the observation nodes of the first business process, the second business process and the third business process respectively;
(5-1-3) when the zookeeper client notifies the addition events of the observation nodes of the first service process, the second service process and the third service process, the first service process checks the current state of the corresponding opposite-end service process, the second service process checks the current state of the corresponding opposite-end service process, and the third service process checks the current state of the corresponding opposite-end service process;
the business process self-processing subprocess for maintaining the keep-alive state comprises the following steps:
(5-2-1) establishing two links among the first service process, the second service process and the third service process;
and (5-2-2) creating new threads in the first business process, the second business process and the third business process.
2. The method for discovering the communication address of the service node based on the third-party database according to claim 1, wherein the step (3) specifically comprises the following steps:
(3-1) the first business process creates a database node/business name 1/server to the zookeeper client, and writes a communication address of the first business process into the server node;
(3-2) the second service process and the third service process respectively create database nodes "/service name 1/clients/service name 2" and "/service name 1/clients/service name 3" for the zookeeper client, and correspondingly write the communication addresses of the second service process and the third service process into the "service name 2" node and the "service name 3" node.
3. The method for discovering the communication address of the service node based on the third-party database according to claim 2, wherein in the step (3-2), the first service process, the second service process, and the third service process issue two types of addresses simultaneously when writing the communication address into the corresponding peer service process: unix address and inet address.
4. The method for discovering the communication address of the service node based on the third-party database according to claim 1, wherein the first service process is a data server, the second service process and the third service process are data clients, and the step (4) specifically includes the following steps:
(4-1) after the database node is created by the first business process, the first business process observes a parent node "/business name 1/clients" of the database node created by the associated data client, judges whether a plurality of clients are online, and if yes, continues to the step (4-2);
(4-2) the first service process reads the communication addresses of the second service process and the third service process from database nodes of "/service name 1/clients/service name 2" and "/service name 1/clients/service name 3";
(4-3) after the second service process and the third service process complete the creation of the database node, judging whether the database node "/service name 1/server" exists, if so, reading the communication address of the first service process.
5. The method for discovering the communication address of the service node based on the third-party database according to claim 1, wherein in the step (5-1-3), the step of checking the current state of the corresponding peer service process by the first service process, the second service process, and the third service process respectively comprises the following steps:
(5-1-3-1) if the current states of the opposite end service processes corresponding to the first service process, the second service process and the third service process are off-line states, continuing the step (5-1-3-2), otherwise, continuing the step (5-1-3-3);
(5-1-3-2) starting an online process;
(5-1-3-3) the first service process, the second service process and the third service process obtain the communication address of the corresponding opposite terminal service process in the observation node, judge whether the change occurs, if the change occurs, continue the step (5-1-3-3-1), otherwise, continue the step (5-1-3-3-2);
(5-1-3-3-1) closing the tcp link before the first service process, the second service process and the third service process, establishing a new tcp link according to the new address, simultaneously judging whether the service processes of the two parties are in the same host, and if the service processes of the two parties are in the same host, simultaneously establishing two links by using unix addresses; if the business processes of the two parties are in different host, using an inet address to establish two links simultaneously;
(5-1-3-3-2) the first service process, the second service process and the third service process filter the corresponding opposite-end service online events of the first service process, the second service process and the third service process.
6. The method for discovering address of service node based on third party database according to claim 1, wherein in the step (5-2-2) of creating a new thread, the new thread handles a keep-alive state maintaining process, and specifically comprises:
(5-2-2-1) periodically sending the keep-alive messages;
(5-2-2-2) receiving keep-alive messages among the opposite-end service processes corresponding to the first service process, the second service process and the third service process, wherein the first service process, the second service process and the third service process are Epoll.
7. The method for enabling discovery of communication address of service node based on third party database as claimed in claim 5, wherein in said step (5-1-3-3-1) establishing new tcp link, MD5 option is required to be set.
8. The method for discovering the communication address of the service node based on the third party database according to claim 1, wherein the two links perform keep-alive detection and load sharing of service data transmission.
9. The method for discovering the communication address of the service node based on the third-party database according to claim 8, wherein the keep-alive detection specifically includes the following steps:
(9-1) the two links respectively detect whether the opposite end service processes corresponding to the first service process, the second service process and the third service process are offline, if so, continuing the step (9-1-1), otherwise, continuing the step (9-1-2);
(9-1-1) confirming that the corresponding opposite end business process is really offline;
(9-1-2) confirming that the corresponding opposite end business process is not offline.
CN201710604968.9A 2017-07-24 2017-07-24 Method for realizing service node communication address discovery based on third-party database Active CN107172230B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710604968.9A CN107172230B (en) 2017-07-24 2017-07-24 Method for realizing service node communication address discovery based on third-party database

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710604968.9A CN107172230B (en) 2017-07-24 2017-07-24 Method for realizing service node communication address discovery based on third-party database

Publications (2)

Publication Number Publication Date
CN107172230A CN107172230A (en) 2017-09-15
CN107172230B true CN107172230B (en) 2020-05-22

Family

ID=59818123

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710604968.9A Active CN107172230B (en) 2017-07-24 2017-07-24 Method for realizing service node communication address discovery based on third-party database

Country Status (1)

Country Link
CN (1) CN107172230B (en)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108363619B (en) * 2018-03-07 2021-11-30 深圳市酷开网络科技股份有限公司 Service flow control method, server, and computer-readable storage medium
CN110008036A (en) * 2019-02-19 2019-07-12 西安万像电子科技有限公司 Data transmission method and device
CN111552672B (en) * 2020-02-19 2023-09-15 中国船舶工业系统工程研究院 Distributed service state consistency maintenance method and device based on ZooKeeper
CN111722883A (en) * 2020-06-12 2020-09-29 浪潮电子信息产业股份有限公司 Method and device for updating interface address and computer readable storage medium

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103595781A (en) * 2013-11-11 2014-02-19 华为技术有限公司 Service providing method, first server and system based on zookeeper
CN106027623A (en) * 2016-03-14 2016-10-12 中国科学院计算技术研究所 Distributed cluster state management method and system thereof

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103595781A (en) * 2013-11-11 2014-02-19 华为技术有限公司 Service providing method, first server and system based on zookeeper
CN106027623A (en) * 2016-03-14 2016-10-12 中国科学院计算技术研究所 Distributed cluster state management method and system thereof

Also Published As

Publication number Publication date
CN107172230A (en) 2017-09-15

Similar Documents

Publication Publication Date Title
US10917322B2 (en) Network traffic tracking using encapsulation protocol
US9729655B2 (en) Managing transfer of data in a data network
CN107172230B (en) Method for realizing service node communication address discovery based on third-party database
US9900293B2 (en) System and method for supporting automatic disabling of degraded links in an infiniband (IB) network
CN106790758B (en) Method and device for accessing network object in NAT network
TW201543243A (en) Capability monitoring in a service oriented architecture
US8898265B2 (en) Determining data flows in a network
US10033602B1 (en) Network health management using metrics from encapsulation protocol endpoints
JP2011087302A (en) Device and method for bgp route monitoring, and program
JP2003258903A (en) Communication line monitor system
JP2010541441A (en) Computer-implemented method, data processing system, and computer program (router detection) for detecting unauthorized routers in a distributed network
US7453865B2 (en) Communication channels in a storage network
CN114301676B (en) Nondestructive asset detection method and device for power monitoring system and storage medium
CN107612772B (en) Node state detection method and device of payment system
US8489727B2 (en) Active storage area network discovery system and method
BR102014032808A2 (en) METHOD AND SYSTEM FOR NOTIFYING SUBSCRIBER DEVICES IN ISP NETWORKS.
US10009253B2 (en) Providing shared resources to virtual devices
CN107634971B (en) Method and device for detecting flood attack
WO2017054734A1 (en) Locking file management method and device
CN110505176B (en) Method and device for determining and sending message priority, and routing system
CN115604160A (en) Network detection processing method and device, electronic equipment and storage medium
CN104954187B (en) A kind of method and apparatus of determining user side equipment state
CN108833282A (en) Data forwarding method, system, device and SDN switch
CA2550323A1 (en) Method and system for improved management of a communication network by extending the simple network management protocol
JP3978099B2 (en) Communication network system management method and network relay device

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
GR01 Patent grant
GR01 Patent grant