WO2024183402A1 - Procédé et appareil de routage de liaison terrestre de journal, et support de stockage - Google Patents
Procédé et appareil de routage de liaison terrestre de journal, et support de stockage Download PDFInfo
- Publication number
- WO2024183402A1 WO2024183402A1 PCT/CN2023/139957 CN2023139957W WO2024183402A1 WO 2024183402 A1 WO2024183402 A1 WO 2024183402A1 CN 2023139957 W CN2023139957 W CN 2023139957W WO 2024183402 A1 WO2024183402 A1 WO 2024183402A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- health
- access server
- log
- central cluster
- mark
- 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.)
- Ceased
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
- H04L67/1004—Server selection for load balancing
- H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/069—Management of faults, events, alarms or notifications using logs of notifications; Post-processing of notifications
Definitions
- the embodiments of the present application relate to the technical field of data processing, and in particular to a method, device and storage medium for selecting a path for log transmission.
- Logs are data that records response behaviors and request information when a computer system responds to specific inputs. They can be used in areas such as statistical analysis, locating anomalies, and billing. The generation, collection, and retrieval of logs are traditional requirements in the field of computer systems.
- a dispatch center is used for routing. That is, the dispatch center is used to perform quality inspections on servers and score and select available servers, thereby sending call links to clients to avoid single point failures of servers and network links.
- the embodiments of the present application provide a log return routing method, device, and storage medium, aiming to improve the timeliness of log return.
- an embodiment of the present application provides a method for selecting a path for log transmission, the method comprising:
- the edge node sends a log return request to any access server with a health mark connected to it, wherein the access server with a health mark is in a normal state and is connected to at least one access server of the central cluster with a health mark, and the log return request contains log data;
- the log return request is forwarded to any central cluster with a health mark connected to it;
- the log data in the log return request is parsed to form a log return path.
- the method further includes:
- the log return request When the central cluster that receives the log return request is currently in an abnormal state, the log return request is not parsed, and a status code indicating unhealthy is returned to the access server that forwards the log return request;
- the access server that receives the unhealthy status code marks the central cluster as unhealthy and returns the log return request to the edge node.
- the method further includes:
- the access server that receives the log return request When the access server that receives the log return request is currently in an abnormal state, it returns a status code indicating unhealthy conditions to the edge node;
- an edge node When an edge node receives a status code indicating unhealthy conditions, it marks the access server as unhealthy and uses a polling method to send log return requests to other healthy access servers.
- the method further includes:
- the edge node For any access server with an unhealthy mark, the edge node sends a first health query request to the access server after a first preset interval from the marking time;
- the access server receiving the first health query request determines whether it is in a normal state, and determines the health status of all central clusters to which it is connected;
- the access server receiving the first health query request When the access server receiving the first health query request is in a normal state and is connected to at least one central cluster with a health mark, the access server sends a health status code to the edge node; after the edge node receives the health status code, it adds a health mark to the access server.
- the method further includes:
- the access server sends a second health query request to the central cluster after a second preset interval from the marking time;
- the central cluster receiving the second health query request determines whether it is in a normal state
- the central cluster When the central cluster receiving the second health query request is in a normal state, the central cluster sends a health status code to the access server;
- the access server After receiving the status code indicating health, the access server adds a health mark to the central cluster.
- the access server that receives the first health query request determines whether it is in a normal state, including:
- the access server When the number of log message instances currently processed by the access server that receives the first health query request is greater than 0, the access server itself is in a normal state.
- the central cluster receiving the second health query request determines whether it is in a normal state, including:
- the central cluster When the number of log message instances currently processed by the central cluster that receives the second health query request is greater than 0, and the backlog of log message instances is less than the backlog threshold, the central cluster itself is in a normal state.
- an embodiment of the present application provides a routing device for log return, the device comprising an edge node, an access server, and a central cluster, wherein:
- the edge node is used to send a log return request to any access server with a health mark connected to it, wherein the access server with a health mark is in a normal state and is connected to at least one access server of the central cluster with a health mark, and the log return request contains log data;
- the access server is used to forward the log return request to any central cluster with a health mark connected to it when receiving the log return request and being in a normal state;
- the central cluster is used to parse the log data in the log return request to form a log return path when receiving the log return request and is currently in a normal state.
- the device further includes:
- a first abnormal state module is used for not parsing the log return request when the central cluster receiving the log return request is currently in an abnormal state, and returning a status code indicating unhealthy state to the access server forwarding the log return request;
- the first update module is used to update the central cluster when the access server receives a status code indicating unhealthy Mark it as unhealthy and return the log upload request to the edge node.
- the device further includes:
- a second abnormal state module is used to return a status code indicating unhealthy state to the edge node when the access server receiving the log return request is currently in an abnormal state;
- the second updating module is used to mark the access server as unhealthy when the edge node receives the status code indicating unhealthy state, and send log return requests to other healthy access servers in a polling manner.
- the edge node includes a first health query module, which is used to send a first health query request to any access server with an unhealthy mark after a first preset interval from the marking time;
- the access server includes a first health determination module, which is used to determine whether the access server receiving the first health query request is in a normal state, and determine the health status of all central clusters connected to it; and when the access server receiving the first health query request is in a normal state and is connected to at least one central cluster with a health mark, the access server sends a health status code to the edge node;
- the edge node also includes a first health marking module, which is used to add a health mark to the access server after receiving a status code indicating health.
- the access server includes a second health query module, which is used to send a second health query request to any central cluster with an unhealthy mark after a second preset interval from the marking time;
- the central cluster includes a second health determination module, which is used to determine whether the central cluster itself that receives the second health query request is in a normal state; and when the central cluster itself that receives the second health query request is in a normal state, the central cluster sends a status code representing health to the access server; the access server includes a second health marking module, which is used to add a health mark to the central cluster after receiving the status code representing health.
- the first health determination module includes:
- the first health determination unit is configured to determine that the access server itself is in a normal state when the number of log message instances currently processed by the access server that has received the first health query request is greater than 0.
- the second health determination module includes:
- the second health determination unit is configured to determine that the central cluster itself is in a normal state when the number of log message instances currently processed by the central cluster that receives the second health query request is greater than 0 and the backlog of log message instances is less than the backlog threshold.
- an embodiment of the present application provides a computer-readable storage medium, on which a computer program is stored.
- the computer program is executed by a processor, the routing method for log transmission according to the first aspect of the embodiment is implemented.
- the edge node when log return is required, the edge node itself selects an access server to send a log return request, and the access server selects a central cluster to forward the log return request, and the access server selected by the edge node is an access server with a health mark, and the access server with a health mark is connected to at least one central cluster with a health mark. Therefore, there is at least one path between the edge node, the access server with a health mark and the central cluster, so that the log return request can reach the central cluster. If the central cluster that receives the log return request is still in a normal state, the log data contained in the log return request can be parsed, thereby forming a log return path.
- the edge node has a grasp of the global health status and can avoid faulty access servers or central clusters. There is no single point failure problem, and there will be no situation where multiple centers issue different decisions at the same time, as may occur in multiple dispatching centers.
- the recovery process of the fault location does not affect other normal edge nodes, access servers and central clusters to form other log return paths, which can effectively improve the timeliness of log return.
- FIG1 is a flowchart of a method for selecting a path for log transmission according to an embodiment of the present application
- FIG2 is a flowchart of steps for health query of access server proposed in one embodiment of the present application.
- FIG3 is a flowchart of steps for health query of a central cluster provided by an embodiment of the present application.
- FIG. 4 is a schematic diagram of the structure of a routing device for log return provided in an embodiment of the present application.
- a single dispatch center is prone to single point failure risks.
- multiple dispatch centers are introduced, and multiple dispatch centers determine the only result through a distributed consensus algorithm.
- the mode of multiple dispatch centers if one dispatch center fails, the other multiple dispatch centers need to negotiate during failure recovery, resulting in a long failure recovery time and a higher failure rate, which leads to poor timeliness of log return.
- an embodiment of the present application provides a log return routing method that does not rely on central scheduling and decision-making, implements decentralized routing decisions, and can effectively improve the timeliness of log return.
- the device architecture of the method application includes an edge node, an access server and a central cluster, wherein the edge node is a service node, which is distributed all over the world and needs to transmit the service generated to the center for processing; the access server is distributed in various hub nodes across the country, providing cross-network and cross-operator access services and authentication, and can forward requests sent by the edge node to the central cluster, while the central cluster is responsible for data processing; the method may specifically include the following steps:
- the edge node sends a log return request to any access server with a health mark to which it is connected.
- Any edge node can be connected to multiple access servers, and the connection between the edge node and the access server can be pre-set or continuously updated, that is, the edge node can only connect to a few fixed access servers by parsing a fixed list, and the edge node can also regularly parse a new access server list to connect to the newly added access server.
- the edge node When there is a need to return logs, the edge node will select an access server with a healthy mark to send a log return request.
- the access server with a healthy mark is in a normal state and is connected to at least one server with The access server of the central cluster with a healthy mark, that is, through the access server with a healthy mark, there is at least one path that can successfully send the log return request to a central cluster with a healthy mark.
- each access server can monitor the health status of each central cluster it is connected to, and add an initial health tag for each central cluster.
- the edge node monitors the health status of each access server it is connected to and the health tag of the connected central cluster, and adds an initial health tag for each access server.
- the edge server can also monitor the health status of each access server regularly, because the health status of the access server not only involves whether it is in a normal state, but also involves the health status of all central clusters to which it is connected. Therefore, each access server also needs to monitor the health status of the central cluster regularly.
- the access server that receives the log return request is marked healthy, the access server may suddenly fail when the log return request of the edge node is sent to the access server. Therefore, it is necessary to determine the current status of the access server that receives the log return request.
- the log return request can be processed further. Since the access server with a healthy mark has successfully connected to at least one central cluster with a healthy mark, the log return request can be forwarded to any healthy central cluster it is connected to. When the access server that receives the log return request is currently in an abnormal state, the log return request cannot be forwarded.
- the access server can return a status code representing unhealthy conditions to the edge node.
- the response body of the status code representing unhealthy conditions can also include the specific reason for the return.
- the edge node receives the status code representing unhealthy conditions, it marks the access server as unhealthy and uses polling to send log return requests to other healthy access servers.
- the access server can independently select any central cluster with a health mark to which it is connected to forward the log return request. After receiving the log return request forwarded by the access server, any central cluster with a health mark also needs to determine whether it is currently in a normal state.
- the log return request can be processed normally, and the log data contained in the request body of the log return request can be parsed, thereby completing the return of the log data and forming a complete log return path.
- the central cluster If the central cluster is in an abnormal state after receiving the log return request forwarded by the access server, the central cluster cannot parse the log return request and returns a status code indicating unhealthiness to the access server that forwards the log return request.
- the response body of the status code indicating unhealthiness may include specific reasons.
- the access server that receives the status code indicating unhealthiness returned by the central cluster marks the central cluster as unhealthy and returns the log return request to the edge node.
- the edge node may poll other access servers with health marks to send log return requests.
- the edge node may adopt a method of randomly traversing all other healthy access servers, or a method of traversing all other healthy access servers in a list order, which is not limited in this embodiment.
- the access server and the central cluster involved are in an abnormal state, they will return an unhealthy status code, that is, notify the upper level of their own health status. Therefore, in this embodiment, in order to save data transmission resources when the edge node monitors the health status of all access servers connected to it, and the access server monitors the health status of all central clusters connected to it, the current log return can be obtained separately during the transmission of each log return request.
- the health status of the access servers and central clusters involved in the transmission request does not need to be monitored in real time for the health status of each access server and each central cluster, which can save a lot of data resources.
- the central cluster can return a status code indicating health to the access server in the current log return path, and can even return a status code indicating health to all access servers connected to the central cluster, so that the access server or all access servers in the current log return path know that the central cluster is in a normal state and maintain the health mark of the central cluster.
- the access server in the current log return path After the access server in the current log return path receives the status code indicating health returned by the central cluster, the access server meets the conditions that it is in a normal state and is connected to at least one central cluster with a health mark. Therefore, the access server can also return the status code indicating health to the edge node in the current log return path, or even to all edge nodes connected to it, so that the edge node or all edge nodes in the current log return path maintain the health mark of the access server.
- unhealthy marks are added because they each return a status code indicating unhealthiness to the upper level.
- the access server itself is in an abnormal state and does not meet the conditions for adding a healthy mark. Therefore, when the edge node of the upper level receives a status code indicating unhealthiness, an unhealthy mark is added to the access server; because the central cluster itself is in an abnormal state, when the access server of the upper level receives a status code indicating unhealthiness, an unhealthy mark is added to the central cluster.
- the access server or central cluster can return a status code indicating unhealthy conditions only to the upper level involved in the current log return request transmission process, or it can return a status code indicating unhealthy conditions to all upper levels to which it is connected.
- the edge nodes include A1, A2 and A3, the access servers include B1 and B2, and the central cluster includes B1 and C3.
- the potential log return paths of edge node-access server-central cluster may include: A1-B1-C1, A1-B1-C2, A1-B2-C1, A1-B2-C2, A2-B1-C1, A2-B1-C2, A2-B2-C1, A2-B2-C2, A3-B1-C1, A3-B1-C2, A3-B2-C1 and A3-B2-C2.
- edge node A1 autonomously selects access server B1 to send the log return request, and access server B1 is in an abnormal state, access server B1 can return a status code indicating an unhealthy state only to edge node A1, or it can simultaneously return a status code indicating an unhealthy state to all upper-level edge nodes A1, A2 and A3 connected to it; the same applies to the central cluster.
- a log return path is successfully formed during the transmission of the current log return request, that is, a central cluster successfully parses the log data in the log return request, assuming that the log return path is A2-B2-C2, then the central cluster C2 can only return a health status code to the access server B2, or it can simultaneously return a health status code to all the access servers B1 and B2 connected to it at the previous level; since the access server B2 in the current log return path can successfully forward the log return request, the access server B2 itself is in a normal state and is connected to at least one central cluster C2 with a health mark, so the access server B2 can only return a health status code to the edge node A2 in the current log return path, or it can return a health status code to all the edge nodes A1, A2 and A3 connected to it at the previous level.
- a health enquiry consists of the following steps:
- the edge node For any access server with an unhealthy mark, the edge node sends a first health query request to the access server after a first preset interval from the marking time.
- an edge node When an edge node adds an unhealthy mark to an access server, it records the timestamp of the current unhealthy mark, and after a first preset interval, sends a first health query request to the access server to query whether the access server has recovered.
- A2 The access server that receives the first health query request determines whether it is in a normal state, and determines the health status of all central clusters to which it is connected.
- the health detection rule of the access server itself may be: when the number of log message instances currently processed is greater than 0, the access server itself is in a normal state; the access server may perform health detection by itself or through a third party.
- the access server queries the health status of all central clusters connected to it, obtains the number of central clusters with healthy marks, and can also perform health queries on central clusters with unhealthy marks.
- A3 The access server that receives the first health query request determines the returned status code.
- the access server that receives the first health query request When the access server that receives the first health query request is itself in a normal state and is connected to at least one central cluster with a health mark, the access server sends a status code indicating health to the edge node; when the access server that receives the first health query request is itself in an abnormal state and/or is not connected to at least one central cluster with a health mark, the access server sends a status code indicating unhealthiness to the edge node.
- A4 The edge node updates the health mark of the access server according to the received status code.
- the edge node when the edge node receives a status code indicating health, it adds a health mark to the access server; when the edge node receives a status code indicating unhealthiness, it maintains the unhealthy mark of the access server and updates the timestamp of the current unhealthy mark. After a first preset interval, it sends a first health query request to the access server again to inquire whether the access server has recovered its health.
- the health query of the access server for a central cluster with an unhealthy mark includes the following steps:
- the access server sends a second health query request to the central cluster after a second preset interval from the marking time.
- an access server When an access server adds an unhealthy mark to a central cluster, it records the timestamp of the current unhealthy mark. After a second preset interval, the access server sends a second health query request to the central cluster to check whether the central cluster has returned to normal.
- B2 The central cluster that receives the second health query request determines whether it is in a normal state.
- the health detection rule of the central cluster can be: when the number of log message instances currently being processed is greater than 0 and the backlog of log message instances is less than the backlog threshold, the central cluster itself is in a normal state; the central cluster can perform health detection by itself or through a third party.
- B3 The central cluster receiving the second health query request determines the returned status code.
- the central cluster receiving the second health query request When the central cluster receiving the second health query request is in a normal state, the central cluster sends a health status code to the access server; when the central cluster receiving the second health query request is still in an abnormal state, it sends an unhealthy status code to the access server.
- the access server updates the health mark of the central cluster according to the received status code.
- the access server When the access server receives a status code indicating health, it adds a health mark to the central cluster; when the access server receives a status code indicating unhealthy, it keeps the unhealthy mark of the central cluster and updates the timestamp of the current unhealthy mark. After the second preset interval, it sends the health mark to the central cluster again.
- the second health query request is to query whether the center has recovered.
- the access server or central cluster connection may fail.
- the upper level can add an unhealthy mark to the access server or central cluster.
- the status code representing health in this embodiment can be HTTP status code 200, and the status code representing unhealthiness can be HTTP status code 500, 502, or 503.
- the access server can use the following logic to monitor the health of the central cluster:
- the access server records the health mark and unhealthy mark of each connected central cluster, for example, maintains a Map, in which the key is the central cluster and the value is the health mark of the central cluster. If the central cluster is marked as healthy, the value is 0; when the central cluster returns a status code indicating unhealthy conditions, or no status code is received due to the failure of the underlying TCP connection, the central cluster is considered to be unhealthy, and the value is set to the current Unix timestamp; and the backend thread periodically checks the Map.
- a health query is performed again; if the central cluster returns a status code indicating health, the central cluster is considered to have recovered and available, and the value is set to 0; if a status code indicating unhealthy conditions is returned or no status code is still received, the central cluster is considered to still be abnormal, and the value is updated to the current Unix timestamp.
- any edge node of the previous layer can perform a health query, and then the queried access server can synchronize the status code of this query to all edge nodes of the previous layer; similarly, if a central cluster is marked as unhealthy by multiple access servers of the previous layer at the same time, any access server of the previous layer can perform a health query, and then the queried central cluster can synchronize the status code of this query to all access servers of the previous layer, further saving data transmission resources during the health query process.
- Single-center cluster network access failure Affected by the center cluster campus firewall or public network cutover operation, the single-center cluster network access may be interrupted or packet loss occurs.
- the access server cannot access the center cluster, that is, the center cluster cannot receive the second health query request. If the access server does not receive any status code within the calibration time, it considers that the center cluster is unhealthy, adds an unhealthy mark to it, and does not send a log return request to the center cluster.
- Single access server network failure Affected by the regional operator firewall, a single access server cannot access all central clusters. At this time, the access server fails the health check of all central clusters. That is, there is no connection to at least one central cluster with a health mark, so the access server does not meet the condition of adding a health mark, and the edge node does not send a log return request to the access server.
- the availability of access servers and central clusters can be notified to edge nodes step by step. After the edge nodes have mastered the global health status, they can decide which access server to send the log return request to. The edge nodes will make independent decisions on the route selection. Compared with the routing method of using multiple dispatch centers, faulty access servers or central clusters can be avoided in time, and there is no single point of failure problem. The integrity and arrival rate of data during the log return process are guaranteed, and there will be no situation where multiple centers issue different decisions at the same time as may occur in multiple dispatch centers.
- the device includes an edge node, an access server, and a central cluster, wherein:
- the edge node is used to send a log return request to any access server with a health mark connected to it, wherein the access server with a health mark is in a normal state and is connected to at least one access server of the central cluster with a health mark, and the log return request contains log data;
- the access server is used to forward the log return request to any central cluster with a health mark connected to it when receiving the log return request and being in a normal state;
- the central cluster is used to parse the log data in the log return request to form a log return path when receiving the log return request and is currently in a normal state.
- the device further includes:
- a first abnormal state module is used for not parsing the log return request when the central cluster receiving the log return request is currently in an abnormal state, and returning a status code indicating unhealthy state to the access server forwarding the log return request;
- the first updating module is used to mark the central cluster as unhealthy and return the log return request to the edge node when the access server receives a status code indicating unhealthy.
- the device further includes:
- a second abnormal state module is used to return a status code indicating unhealthy state to the edge node when the access server receiving the log return request is currently in an abnormal state;
- the second update module is used to mark the access server as unhealthy when the edge node receives a status code indicating unhealthy status, and send a log return request to other healthy access servers in a polling manner.
- the edge node includes a first health query module, which is used to send a first health query request to any access server with an unhealthy mark after a first preset interval from the marking time;
- the access server includes a first health determination module, which is used to determine whether the access server receiving the first health query request is in a normal state, and determine the health status of all central clusters connected to it; and when the access server receiving the first health query request is in a normal state and is connected to at least one central cluster with a health mark, the access server sends a health status code to the edge node;
- the edge node also includes a first health marking module, which is used to add a health mark to the access server after receiving a status code indicating health.
- the access server includes a second health query module, which is used to send a second health query request to any central cluster with an unhealthy mark after a second preset interval from the marking time;
- the central cluster includes a second health determination module, which is used to determine whether the central cluster itself that receives the second health query request is in a normal state; and when the central cluster itself that receives the second health query request is in a normal state, the central cluster sends a status code representing health to the access server; the access server includes a second health marking module, which is used to add a health mark to the central cluster after receiving the status code representing health.
- the first health determination module includes:
- the first health determination unit is configured to determine that the access server itself is in a normal state when the number of log message instances currently processed by the access server that has received the first health query request is greater than 0.
- the second health determination module includes:
- the second health determination unit is configured to determine that the central cluster itself is in a normal state when the number of log message instances currently processed by the central cluster that receives the second health query request is greater than 0 and the backlog of log message instances is less than the backlog threshold.
- An embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored.
- the computer program is executed by a processor, the routing method for log transmission as in the embodiment is implemented.
- the embodiments of the present application can be provided as methods, devices, or computer program products. Therefore, the present application can adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application can adopt 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.) containing computer-usable program code.
- a computer-usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
- each process and/or box in the flowchart and/or block diagram, and the combination of the process and/or box in the flowchart and/or block diagram can be realized by computer program instructions.
- These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device produce a device for realizing the function specified in one process or multiple processes in the flowchart and/or one box or multiple boxes in the block diagram.
- These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.
- These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce computer-implemented processing, so that the instructions executed on the computer or other programmable terminal device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Debugging And Monitoring (AREA)
Abstract
La présente demande appartient au domaine technique du traitement de données. L'invention concerne un procédé et un appareil de routage de liaison terrestre de journal, et un support de stockage. Le procédé comprend les étapes suivantes : un nœud périphérique envoie une demande de liaison terrestre de journal à n'importe quel serveur d'accès qui présente une marque de santé et est connecté au nœud périphérique, le serveur d'accès présentant une marque de santé étant un serveur d'accès qui est dans un état normal et étant au moins connecté à une grappe centrale présentant une marque de santé, et la demande de liaison terrestre de journal comprenant des données de journal ; lorsque le serveur d'accès qui reçoit la demande de liaison terrestre de journal est actuellement dans l'état normal, transfère la demande de liaison terrestre de journal à n'importe quelle grappe centrale qui présente une marque de santé et est connectée au serveur d'accès ; et lorsque la grappe centrale qui reçoit la demande de liaison terrestre de journal est actuellement dans l'état normal, analyse les données de journal dans la demande de liaison terrestre de journal, de façon à former un trajet de liaison terrestre de journal. La présente demande vise à améliorer la rapidité de liaison terrestre de journal.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310208655.7A CN116095180B (zh) | 2023-03-07 | 2023-03-07 | 一种日志回传的选路方法、装置和存储介质 |
| CN202310208655.7 | 2023-03-07 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| WO2024183402A1 true WO2024183402A1 (fr) | 2024-09-12 |
Family
ID=86204591
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| PCT/CN2023/139957 Ceased WO2024183402A1 (fr) | 2023-03-07 | 2023-12-19 | Procédé et appareil de routage de liaison terrestre de journal, et support de stockage |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN116095180B (fr) |
| WO (1) | WO2024183402A1 (fr) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116095180B (zh) * | 2023-03-07 | 2023-06-23 | 天翼云科技有限公司 | 一种日志回传的选路方法、装置和存储介质 |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018127012A1 (fr) * | 2017-01-03 | 2018-07-12 | 北京奇虎科技有限公司 | Procédé et dispositif de détection de grappe de nœuds de transmission |
| CN109407980A (zh) * | 2018-09-29 | 2019-03-01 | 武汉极意网络科技有限公司 | 基于Redis集群的数据存储系统 |
| CN111198762A (zh) * | 2019-12-16 | 2020-05-26 | 北京淇瑀信息科技有限公司 | 一种支持高并发的服务器集群系统及控制方法、控制装置 |
| CN114866617A (zh) * | 2022-04-28 | 2022-08-05 | 济南浪潮数据技术有限公司 | 一种微服务请求处理方法、装置、设备及介质 |
| CN115643166A (zh) * | 2022-12-08 | 2023-01-24 | 江苏云工场信息技术有限公司 | 一种高可靠回传cdn日志的方法及装置 |
| CN116095180A (zh) * | 2023-03-07 | 2023-05-09 | 天翼云科技有限公司 | 一种日志回传的选路方法、装置和存储介质 |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7152180B2 (en) * | 2002-12-06 | 2006-12-19 | Ntt Docomo, Inc. | Configurable reliable messaging system |
| US7664991B1 (en) * | 2002-12-17 | 2010-02-16 | Symantec Operating Corporation | System and method for distributed file system I/O recovery |
| CN110401657B (zh) * | 2019-07-24 | 2020-09-25 | 网宿科技股份有限公司 | 一种访问日志的处理方法及装置 |
| CN111722963A (zh) * | 2020-06-18 | 2020-09-29 | 深圳力维智联技术有限公司 | 数据接入方法、系统及计算机可读存储介质 |
| CN114244890B (zh) * | 2021-12-22 | 2022-05-24 | 珠海金智维信息科技有限公司 | Rpa服务器集群控制方法及系统 |
-
2023
- 2023-03-07 CN CN202310208655.7A patent/CN116095180B/zh active Active
- 2023-12-19 WO PCT/CN2023/139957 patent/WO2024183402A1/fr not_active Ceased
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018127012A1 (fr) * | 2017-01-03 | 2018-07-12 | 北京奇虎科技有限公司 | Procédé et dispositif de détection de grappe de nœuds de transmission |
| CN109407980A (zh) * | 2018-09-29 | 2019-03-01 | 武汉极意网络科技有限公司 | 基于Redis集群的数据存储系统 |
| CN111198762A (zh) * | 2019-12-16 | 2020-05-26 | 北京淇瑀信息科技有限公司 | 一种支持高并发的服务器集群系统及控制方法、控制装置 |
| CN114866617A (zh) * | 2022-04-28 | 2022-08-05 | 济南浪潮数据技术有限公司 | 一种微服务请求处理方法、装置、设备及介质 |
| CN115643166A (zh) * | 2022-12-08 | 2023-01-24 | 江苏云工场信息技术有限公司 | 一种高可靠回传cdn日志的方法及装置 |
| CN116095180A (zh) * | 2023-03-07 | 2023-05-09 | 天翼云科技有限公司 | 一种日志回传的选路方法、装置和存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116095180A (zh) | 2023-05-09 |
| CN116095180B (zh) | 2023-06-23 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP4052438B1 (fr) | Détection et correction d'anomalies d'itinéraires | |
| EP2321908B1 (fr) | Procédé et système de traitement de messages | |
| CN102656922B (zh) | 利用用于使用群体智能在大规模分布式系统中进行信息路由的框架的系统和方法 | |
| CN101102250B (zh) | 用于自组织网络的分布式散列机制 | |
| CN101707537A (zh) | 故障链路定位方法、告警根因分析方法及设备、系统 | |
| CN112737800B (zh) | 服务节点故障定位方法、调用链生成方法及服务器 | |
| US8948178B2 (en) | Network clustering | |
| CN102394944B (zh) | 一种Web访问中的IP地址库修正方法和设备 | |
| WO2024183402A1 (fr) | Procédé et appareil de routage de liaison terrestre de journal, et support de stockage | |
| CN103023680A (zh) | 一种终端状态收集系统及方法 | |
| CN111680807A (zh) | 一种电网故障报告服务方法 | |
| CN113422696B (zh) | 监控数据更新方法、系统、设备及可读存储介质 | |
| CN116723154B (zh) | 一种基于负载均衡的路由分发方法及系统 | |
| CN115695202B (zh) | 一种网络探测方法、装置、设备及可读存储介质 | |
| CN107493308B (zh) | 一种发送消息的方法和装置及分布式设备集群系统 | |
| US8077699B2 (en) | Independent message stores and message transport agents | |
| JP2006270781A (ja) | リソース管理装置、システムおよび方法 | |
| US20200341968A1 (en) | Differential Update of Local Cache from Central Database | |
| CN115002205B (zh) | 一种基于表路由代理模式的Kapacitor集群方法 | |
| CN115277351B (zh) | 一种分布式管理系统 | |
| CN120090962B (zh) | 一种基于数联网的网络节点管理方法及系统 | |
| US20070150615A1 (en) | Carrier interoperability for critical services | |
| CN117857309A (zh) | 一种基于去中心化的自适应监控方法及系统 | |
| CN120935264A (zh) | 基于二级前置的请求处理方法及装置、存储介质、系统 | |
| CN121151267A (zh) | 一种路由中断检测方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| 121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 23926096 Country of ref document: EP Kind code of ref document: A1 |
|
| NENP | Non-entry into the national phase |
Ref country code: DE |