A data interaction method, device, equipment, medium and product during online upgrade

Abstract

The present invention relates to the field of distributed cluster technology, and in particular to a method, apparatus, device, medium and product for data interaction during online upgrades, the method comprising: during the distributed cluster upgrade process, obtaining a data interaction request from a first party, and adding a version field and a type field to the data header of the data interaction request; if the first version is consistent with the second version of the second party, processing the pending data in the data interaction request according to the consistent version; if the first version is greater than the second version, processing the pending data in the data interaction request according to the data update operation corresponding to the type field of the first party and the second version. This method enables the first party and the second party of different versions to communicate normally during the online upgrade of the distributed cluster, achieving smooth online upgrades between high and low versions, greatly reducing the risk of upgrade failure, and ensuring the smooth reliability of business operations during large-scale cluster upgrades, essentially achieving zero-perception system version switching.

Description

Technical Field

[0001] The present invention relates to the field of distributed cluster technology, and in particular to a data interaction method, device, equipment, medium and product during online upgrading. Background Art

[0002] With the rapid development of cloud computing, big data, and AI technologies, distributed cluster systems have become core infrastructure supporting large-scale business scenarios. Distributed cluster systems typically consist of multiple nodes and are often used to support high-concurrency, low-latency, and continuously online services. However, with the continuous iteration and update of functions and technologies, distributed cluster systems require frequent upgrades. To ensure business continuity and reliability, distributed cluster system upgrades must ensure that business operations are updated online.

[0003] During an online upgrade of a distributed cluster system, not all nodes in the system can simultaneously update their Red Hat Package Manager (RPM) packages or restart their services. This can lead to version inconsistencies within the distributed cluster. One scenario involves a node's RPM package being updated but its storage service not yet restarted. In this case, communication between the client service and the server service on that node is considered inter-version data communication. Another scenario involves some nodes in the distributed cluster system being upgraded to the new version, while others are still running the old version. In this case, communication between these nodes is considered inter-version data communication. Therefore, if the data structures communicated between the old and new versions are the same, data communication can continue normally even during an online upgrade. However, feature optimizations and bug fixes often involve changes to data structures, meaning that the new version may add or delete certain data structures compared to the old version. If the data structures used for communication between the new and old versions change, communication failures between client and server services on the same node, or between different nodes, may occur during the upgrade process. This can cause communication failures, hindering system operations. A common approach to addressing this issue is to retain the old version's data structures in the new version of the code. However, when a distributed cluster system requires an online upgrade, all nodes within the system, regardless of whether they have been upgraded, continue communicating using the old version's data structures. Once the entire distributed cluster system is fully upgraded, all nodes are then switched to the new version's data structures. This approach avoids communication between different versions of data, but it has a drawback for online upgrades of large-scale distributed clusters. Large-scale distributed clusters may involve hundreds, thousands, or even tens of thousands of nodes, and online upgrades are not quick. Equipment at some sites may have completed the upgrade while equipment at others has not. Consequently, even upgraded nodes may not be able to immediately provide new features. Furthermore, if a node experiences a fault during the upgrade, requiring time to locate and repair the fault, this can affect the ability of upgraded nodes to provide the latest features.

[0004] It can be seen that how to efficiently perform data interaction during the distributed cluster upgrade process is a problem that those skilled in the art need to solve. Summary of the Invention

[0005] The purpose of this application is to provide a data interaction method, device, equipment, medium and product during online upgrade, which can efficiently perform data interaction during the distributed cluster upgrade process.

[0006] In a first aspect, a method for data interaction during online upgrading is provided, comprising: obtaining a data interaction request from a first party during a distributed cluster upgrade process, adding a version field and a type field to a data header of the data interaction request, and if the first version of the first party is an upgraded version, the version field is an upgraded version field, and the type field is a data update operation of the upgraded version; parsing the data interaction request to obtain the first version of the first party and the type field of the first party; if the first version of the first party is consistent with the second version of the second party, processing the pending data in the data interaction request according to the consistent version; if the first version of the first party is greater than the second version of the second party, processing the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version.

[0007] In a preferred example, the present application can be further configured to: process the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version, including: processing the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party, obtaining the first target data, and processing the first target data according to the second version.

[0008] In a preferred example, the present application can be further configured as follows: according to the data update operation corresponding to the type field of the first party, the data to be processed of the data interaction request is processed to obtain the first target data, including: if the type field of the first party is an increase type, then the increase field of the data to be processed of the data interaction request is removed to obtain the first target data, and the increase field is the increase field corresponding to the increase type; if the type field of the first party is a deletion type, then the deletion field of the data to be processed of the data interaction request is filled with zeros to obtain the first target data, and the deletion field is the deletion field corresponding to the deletion type; if the type field of the first party is a deletion-addition type, then the increase field of the data to be processed of the data interaction request is removed, and then the deletion field of the data to be processed of the data interaction request is filled with zeros to obtain the first target data.

[0009] In a preferred example, the present application may be further configured as follows: if the first version of the first party is smaller than the second version of the second party, the version field and type field of the data header of the data interaction request are empty or zero.

[0010] In a preferred example, the present application can be further configured as follows: the first party is a client service within the node, and the second party is a server service within the node; the first version of the first party is the version of the software data package within the node, and the second version of the second party is the version of the node in the version list in the memory of the node, and the version list stores the version of each node in the distributed cluster.

[0011] In a preferred example, the present application can be further configured as follows: the first party is a node in the distributed cluster, and the second party is the current node; the data interaction method during online upgrade also includes: if the first version of the first party is smaller than the second version of the second party, then according to the data update operation corresponding to the type field in the data structure of the second version of the second party and the second version, the pending data of the data interaction request is processed.

[0012] In a preferred example, the present application can be further configured to: process the pending data of the data interaction request according to the data update operation corresponding to the type field in the second version of the data structure of the second party and the second version, including: processing the pending data in the data interaction request according to the data update operation corresponding to the type field in the second version of the data structure of the second party, obtaining second target data, and processing the second target data according to the second version.

[0013] In a preferred example, the present application can be further configured as follows: after parsing the data interaction request and obtaining the first version of the first party and the type field of the first party, it also includes: reading the version of this node from the version list in the memory of this node as the second version.

[0014] In a preferred example, the present application can be further configured to: process the pending data in the data interaction request according to the consistent version, including: if the consistent version is an upgraded version, processing the pending data in the data interaction request based on the upgraded version; if the processing fails, controlling this node to automatically roll back to the version before the upgrade, and processing the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version.

[0015] In a preferred example, the present application can be further configured as follows: it also includes: when the upgrade of the node is completed and restarted, parsing the version of the software data package, and using the version of the software data package as the upgraded version of the node, and writing the upgraded version of the node into the version list in the memory of the node; adding the node to the distributed cluster, and sending the upgraded version of the node to each node in the distributed cluster, so that each node updates the version list in its own memory.

[0016] In a preferred example, the present application can be further configured as follows: after processing the data to be processed in the data interaction request, it also includes: encapsulating the processed data according to the second version of the second party and the type field corresponding to the second version to obtain reply information; and returning the reply information to the first party.

[0017] In a preferred example, the present application can be further configured to: also include: receiving a static data read request for a database; during a distributed cluster upgrade process, the database includes old version data and new version data, and the new version data is constructed based on the old version data using the data structure of the upgraded version; if the current node is a pre-upgrade node, data is read from the old version data; if the current node is an upgraded node, data is read from the new version data.

[0018] In a preferred example, the present application can be further configured to include: receiving a static data write request for the database; and writing corresponding data into both the old version data and the new version data according to the static data write request and the upgrade version field.

[0019] In a preferred example, the present application may be further configured to include: after the distributed cluster upgrade is completed, deleting the data corresponding to the new version data in the old version data to obtain an updated database.

[0020] In a preferred example, the present application can be further configured as follows: if the first version of the first party is greater than the second version of the second party, then processing the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version, including: if the first version of the first party is greater than the second version of the second party, then processing the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version; if the processing fails, writing the pending data into the waiting queue, and when the current node is successfully upgraded, reading the pending data from the waiting queue, and processing the pending data according to the upgraded version.

[0021] In a preferred example, the present application can be further configured as follows: it also includes: if the current node is not the first batch of test upgrade nodes in the distributed cluster, then the test success information of the first batch of test nodes is received; wherein, the first batch of test upgrade nodes are used to verify that data processing can be performed when the first version of the first party and the second version of the second party are inconsistent.

[0022] On the second aspect, a data interaction device during online upgrade is provided, including: an acquisition module, used to obtain a data interaction request from a first party during a distributed cluster upgrade process, wherein a version field and a type field are added to the data header of the data interaction request, and if the first version of the first party is an upgraded version, the version field is an upgraded version field, and the type field is a data update operation of the upgraded version; a parsing module, used to parse the data interaction request to obtain the first version of the first party and the type field of the first party; a first processing module, used to process the pending data in the data interaction request according to the consistent version if the first version of the first party is consistent with the second version of the second party; a second processing module, used to process the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version if the first version of the first party is greater than the second version of the second party.

[0023] According to a third aspect, an electronic device is provided, comprising a memory and a processor, wherein a computer program is stored in the memory, and the processor executes the online upgrade data interaction method according to any one of the first aspects when running the computer program.

[0024] In a fourth aspect, a computer-readable storage medium is provided, wherein at least one program code is stored in the computer-readable storage medium, and the program code is loaded and executed by a processor to implement the data interaction method during online upgrade as described in any one of the first aspects.

[0025] In a fifth aspect, a computer program product is provided, comprising a computer program or instructions, which, when executed by a processor, implements the data interaction method during online upgrade as described in any one of the first aspects.

[0026] In summary, the data interaction method during online upgrade provided by the present application includes the following beneficial technical effects: during the distributed cluster upgrade process, the data interaction request of the first party is obtained, and the data header of the data interaction request is increased with a version field and a type field. If the first version of the first party is an upgraded version, the version field is the upgraded version field, and the type field is the data update operation of the upgraded version; the data interaction request is parsed to obtain the first version of the first party and the type field of the first party; if the first version of the first party is consistent with the second version of the second party, the pending data in the data interaction request is processed according to the consistent version; if the first version of the first party is greater than the second version of the second party, the pending data of the data interaction request is processed according to the data update operation corresponding to the type field of the first party and the second version. This method can enable the first party and the second party of different versions to communicate normally during the online upgrade of the distributed cluster, realize smooth online upgrades between high and low versions, greatly reduce the risk of upgrade failure, and ensure the smooth reliability of business operation during large-scale cluster upgrades, basically realizing zero-perception system version switching.

[0027] In addition, the present application also provides a data interaction device, equipment, medium and product for online upgrading, all of which have the above-mentioned beneficial technical effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the embodiments of the present invention, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0029] Figure 1 This is a flow chart of a data interaction method during online upgrade provided in an embodiment of the present application.

[0030] Figure 2 This is a schematic diagram of a basic format of communication data provided by an embodiment of the present application.

[0031] Figure 3 This is a schematic diagram of the version update process of the client service and the server service during the node upgrade process provided by an embodiment of the present application.

[0032] Figure 4 This is a schematic diagram of the interaction process between a first party and a second party provided in an embodiment of the present application.

[0033] Figure 5 This is a flowchart of updating the node memory version number during a cluster online upgrade provided by an embodiment of the present application.

[0034] Figure 6This is a flowchart of a compatible processing of static database data between different versions provided in an embodiment of the present application.

[0035] Figure 7 This is a schematic diagram of the structure of a data interaction device for online upgrades provided in an embodiment of the present application.

[0036] Figure 8 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0037] The following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of them. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making any creative efforts shall fall within the scope of protection of the present invention.

[0038] The terms "including" and "having," as used in the present description and accompanying drawings, and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements and may include steps or elements that are not listed.

[0039] In order to enable those skilled in the art to better understand the present invention, the present invention will be further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0040] Distributed storage systems often handle important customer services. When version upgrades are needed, they typically require online upgrades. When distributed storage systems are upgraded online, each node in the cluster is typically upgraded using a rolling upgrade process, meaning each node is upgraded serially. Therefore, during the upgrade process, nodes with the old and new versions of the system may coexist within the cluster. When a new product version adds numerous new features and functions, the underlying data structure undergoes significant changes, which creates the risk of data communication failure between the old and new versions. This requires specialized methods to ensure the reliability and stability of the distributed storage system during the online upgrade process.

[0041] Since the underlying layer is a distributed storage system, it is responsible for providing business IO to the outside world. In order to achieve business continuity during the upgrade process, the present invention proposes a method for processing data interaction during the online upgrade of a distributed cluster in combination with the needs of product iteration output. Figure 1As shown, the method provided in the embodiments of the present application can be executed by an electronic device, which is a node in a distributed cluster. The node can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The node can also be a terminal device, which can be a smartphone, tablet computer, laptop computer, desktop computer, etc., but is not limited to this. The terminal device and the electronic device can be directly or indirectly connected via wired or wireless communication, which is not limited in the embodiments of the present application. The method includes:

[0042] S101. During the distributed cluster upgrade process, obtain the data interaction request of the first party, and add a version field and a type field to the data header of the data interaction request. If the first version of the first party is an upgraded version, the version field is the upgraded version field, and the type field is the data update operation of the upgraded version.

[0043] Among them, the distributed cluster includes multiple independent nodes, and each independent node can communicate. The distributed cluster upgrade process refers to the process of the distributed cluster performing version updates. The first party refers to the initiator of the data interaction request, and the second party involved in the corresponding S103 step is the recipient of the data interaction request. In one possible scenario, if the first party is a client service within the node, the second party is a server service within the node; if the first party is a node in the distributed cluster, the second party is the node itself.

[0044] In an embodiment of the present application, a data interaction request is a request message sent by the first party that requires interaction. The data header refers to the part of the data interaction request used to carry metadata. This part has newly added a version field and a type field, wherein the version field is used to indicate the version of the first party; the type field is used to indicate the data update operation of the upgraded version if the first party is an upgraded version; the upgraded version refers to the new version after the distributed cluster is upgraded; the data update operation of the upgraded version indicates operations such as adding and deleting data under the upgraded version.

[0045] Understandably, all data involved in communication within a distributed cluster is restructured by adding a version field (version field) and a type field (modify field) to the data header. During communication, the version field is filled with the sender's version information. The modify field is filled when a higher-version communication partner sends data during an online cluster upgrade, indicating that the higher-version version has deleted or added to the structure. This data structure serves as the basis for subsequent communication between different versions.

[0046] In one achievable manner, each node in a distributed cluster knows each other's versions. The first party knows its own first version and the second party's second version. Only when its own first version is greater than the second version will the first party fill in the field corresponding to the upgraded version in the version field and the type corresponding to the type field. Otherwise, both fields are empty or zero. In another achievable manner, each node knows each other's versions and knows whether its own version is an upgraded version. The first party will fill in the field of the first version in the version field and fill in the type field only when the first version is an upgraded version. Of course, other situations may exist, and the embodiments of the present application will not limit them.

[0047] It can be seen that the present invention proposes a definition of the basic format of communication data, see Figure 2 , Figure 2 This is a schematic diagram of a basic format of communication data provided by an embodiment of the present application, in which a version field (V1 indicates the version before the upgrade, and V2 indicates the upgraded version) and a type field are added to the data involved in the communication, such as Figure 2 As shown, the version field is used to record the software version number of the data sender, and the type field is only used and valid during the cluster online upgrade process. It is mainly used in the upgraded code logic to identify what type of changes have occurred in the data when sending communication data: type field = 1 means that certain fields have been deleted. The present invention stipulates that the original deleted data range is filled with 0 after the field is deleted. Type field = 2 means that certain fields have been added. The present invention stipulates that the added fields are appended to the end of the original data structure; type field = 3 means that some fields have been deleted and some fields have been added at the same time; the present invention does not support modifying existing fields, but in the actual use of the present invention, it can replace the direct modification of a field by deleting a field and adding a field at the same time. Since the change to the specific communication data structure is caused by human modification, the modify type for the higher version of the specific communication data structure is also fixed, and the modify default value of the new version data is the processing done by the new version.

[0048] S102: Parse the data interaction request to obtain the first version of the first party and the type field of the first party.

[0049] S103: If the first version of the first party is consistent with the second version of the second party, process the to-be-processed data in the data interaction request according to the consistent versions.

[0050] When the data structures of the first party and the second party are the same, it means that the data structure has changed. In this case, the data can be processed according to the same version.

[0051] S104: If the first version of the first party is greater than the second version of the second party, process the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version.

[0052] When the first version of the first party is greater than the second version of the second party, it means that the first party has used a newer version and the data structure has changed. Then, a pre-defined operation mapping table is queried based on the type field. The mapping table records the data update operations corresponding to different type fields. Then, based on the data update operation, the second version is used to process the data to be processed.

[0053] Specifically, in one possible implementation, the data to be processed in the data interaction request can be first processed based on the data update operation so that the data can adapt to the second version, and then the data processing can be performed based on the second version. In another possible implementation, during the data processing using the second version, targeted processing can be performed based on the fields involved in the data update operation.

[0054] Furthermore, when the node upgrade fails, the version can be rolled back automatically, so that the old version can still take over seamlessly, thereby greatly reducing the risk of upgrading.

[0055] It can be seen that in the embodiment of the present application, during the distributed cluster upgrade process, the data interaction request of the first party is obtained, and the data header of the data interaction request is increased with a version field and a type field. If the first version of the first party is an upgraded version, the version field is the upgraded version field, and the type field is the data update operation of the upgraded version; the data interaction request is parsed to obtain the first version of the first party and the type field of the first party; if the first version of the first party is consistent with the second version of the second party, the pending data in the data interaction request is processed according to the consistent version; if the first version of the first party is greater than the second version of the second party, the pending data of the data interaction request is processed according to the data update operation corresponding to the type field of the first party and the second version. This method can enable the first party and the second party of different versions to communicate normally during the online upgrade of the distributed cluster, realize smooth online upgrades between high and low versions, greatly reduce the risk of upgrade failure, and ensure the smooth reliability of business operation during large-scale cluster upgrades, basically realizing zero-perception system version switching.

[0056] It can avoid data processing errors or business interruptions caused by version incompatibility, improve the compatibility and stability of the system, enable clients and servers of different versions to work together to a certain extent, ensure business continuity and data accuracy, and provide more flexible support for system upgrades and version management.

[0057] A possible implementation method of an embodiment of the present application is to process the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version, including: processing the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party, obtaining the first target data, and processing the first target data according to the second version.

[0058] The first target data is the result data obtained after processing the data to be processed according to the data update operation corresponding to the type field of the first party. Figure 2 For example, if the data update operation deletes the last preset field, the first target data consists of the data and the preset fields padded with zeros, a data format that is compatible with the second version. If the first version is larger than the second version, the second party queries a predefined operation mapping table based on the type field. This mapping table records the data update operations corresponding to different type fields. The second party processes the target data according to the rules in the mapping table to obtain the first target data. The second party then performs business operations on the first target data based on the second version.

[0059] It can be seen that in an embodiment of the present application, when the first version of the first party is greater than the second version of the second party, the first target data is obtained by first processing the data to be processed according to the version and type field of the first party, ensuring that the data interaction request can be processed correctly and the data finally obtained can be used normally in the environment of the second party; then the first target data is processed according to the second version, thereby improving the compatibility and stability of the system.

[0060] Based on the above embodiments, a possible implementation method of the embodiments of the present application is to process the data to be processed of the data interaction request according to the data update operation corresponding to the type field of the first party to obtain the first target data, including: if the type field of the first party is an increase type, then the increase field of the data to be processed of the data interaction request is removed to obtain the first target data, and the increase field is the increase field corresponding to the increase type; if the type field of the first party is a deletion type, then the deletion field of the data to be processed of the data interaction request is filled with zeros to obtain the first target data, and the deletion field is the deletion field corresponding to the deletion type; if the type field of the first party is a deletion-addition type, then the increase field of the data to be processed of the data interaction request is removed, and then the deletion field of the data to be processed of the data interaction request is filled with zeros to obtain the first target data.

[0061] It can be seen that in the embodiment of the present application, by setting different processing methods for different type fields, it is possible to adapt to various data format changes.

[0062] In one possible implementation of this embodiment of the present application, if the first version of the first party is smaller than the second version of the second party, the version field and type field in the data header of the data exchange request are empty or zero. This shows that in this embodiment of the present application, the version field and type field are only valid when the first version of the first party is larger than the second version of the second party, enabling rapid identification of two versions and greatly improving version determination efficiency.

[0063] A possible implementation method of an embodiment of the present application, after processing the data to be processed in the data interaction request, also includes: encapsulating the processed data according to the second version of the second party and the type field corresponding to the second version to obtain reply information; and returning the reply information to the first party.

[0064] Notably, this invention primarily proposes a method for handling data interaction during online upgrades of distributed clusters. This method ensures communication compatibility between different versions of client and server services within the same node within the cluster. Furthermore, it also ensures data compatibility between nodes within the cluster running different versions. This effectively ensures the reliability of production services during online cluster upgrades while significantly reducing the risk of distributed cluster online upgrade failures.

[0065] Specifically, when a distributed cluster needs to be upgraded online, the data structures involved in the communication between client services and server services within the node, as well as the communication between nodes, will be transformed. The version number information, namely the version field, and the data update related information, namely the type field, will be reserved in the data. In addition, the version information of all nodes is recorded in the memory of each node in the cluster. When a node is upgraded and restarted, the version number of the node in the memory of each node is updated in time. This version number provides the basis for the interaction of different versions of data during the upgrade process. When the structure of a certain communication data changes in the new version and data needs to be sent to the other end, the version number of the node and the changes in the data structure are identified in the data so that the other end node can make a judgment based on the version number. If the version numbers are the same, it will be parsed directly. If the version numbers are different, the received communication data will be parsed accordingly based on the type field carried in the data to obtain the data content required by itself, thereby achieving good compatibility of data communication between different versions. Each node maintains a copy of the version information for each cluster node in its process memory. During an upgrade, when a node completes its upgrade and restarts services, it retrieves its own version information based on the RPM package (software data package) version. Upon restarting and joining the cluster, it notifies other nodes in the cluster, and each node updates its own version information. Recording the version information of each node within the cluster facilitates data encapsulation when communicating with other nodes. Furthermore, each node's in-memory recording and maintenance of the version information for each cluster node improves communication efficiency, avoiding performance issues associated with retrieving information from a database or other means for each communication.

[0066] In a possible implementation of an embodiment of the present application, the first party is a client service within the node, and the second party is a server service within the node; the first version of the first party is the version of the software data package within the node, and the second version of the second party is the version of the node in the version list in the memory of the node, and the version list stores the version of each node in the distributed cluster.

[0067] In a distributed cluster system, some information can be obtained or set through the command line of a single node to interact with the node process memory information. During an online upgrade, when the node's RPM package is updated, the command line is a separate process. Therefore, when the command line is used, the logic executed by the client service is the logic of the latest installed RPM package. However, at this time, the cluster service has not been restarted, and the server service is still running with the old version of the logic. See Figure 3 , Figure 3 This is a schematic diagram of the version update process of the client service and the server service during the node upgrade process provided by an embodiment of the present application.

[0068] During the node upgrade process, there may be inconsistencies in the communication data between the client service and the server service, but in this case, only the client service version will be newer than the server service version. Therefore, during the online upgrade process, when the command line client service of the node encapsulates the request, it encapsulates the version number into the request data, and records whether the request data has been added or deleted, and then encapsulates the normal request data. After the server service receives the data, if its own version number is inconsistent with the request information, it will parse and process the request data according to the changes, and finally fill its own version number and processing results into the reply information. The client service can then parse the information it needs according to the changes in the new version; this can effectively realize the information communication between the client service and the server service in the same node.

[0069] See also Figure 4 , Figure 4 This is a schematic diagram of the interaction process between the first and second parties provided in an embodiment of the present application. Taking the interaction of communication information between the client (client service) and the server (server service) of the same node as an example, the node accessing the node's own memory information through the command line is actually also an interaction process between the client and the server. During the node online upgrade process, if the node has not yet updated the RPM package or the node has updated the RPM package and the service has been restarted, the node's client and server communication version information is actually the same. If the node's RPM has been updated but the service has not been restarted, the code used in the command line is version V2, while the logic running the business process is still version V1.

[0070] like Figure 4 Information interaction process between the client (as the first party) and the server (as the second party) When interacting with data, the client first obtains the RPM package version number Vi of this node.

[0071] When the cluster is not in the upgrade state, the type field in the encapsulation request information is invalid and can be set to 0. The version field can be set normally.

[0072] When the cluster is in the upgrade state, if the RPM package is the old version V1, only the version field = V1 is filled in the request data, and the type field remains at the initial value 0. The requested req data, i.e. the request data, is sent to the server. After receiving the data, the server determines whether the version number carried by the req is equal to its own version number. If they are equal, the req information is directly processed according to its own version logic, and the processing result is encapsulated into the rsp information, i.e. the reply information, and returned to the client. The rsp information also encapsulates the version number. After the client obtains the rsp information and detects that the version number in the rsp is consistent with its own, it can directly process it according to its own logic.

[0073] If the client detects version V2 when sending a request, in addition to encapsulating version V2 in the request data, it also encapsulates the modify information, including the default modify of the structure. Upon receiving the request, the server first checks whether the version number in the request matches the node version number stored in its memory. If so, it proceeds as described above and will not be repeated. If they are not equal (for intra-node communication, this only occurs when the client service version is higher than the server service version), the server first checks the modify information. If modify = 2, it indicates that a field has been added to the information structure carried in the request. The server then processes the data within its required length normally (ignoring the added field). If modify = 1, it indicates that a field has been deleted from the information structure carried in the request. When processing the required field, the server treats the deleted field as 0 and ignores further processing of the field without reporting an error. If modify = 3, the server continues to process the data within its required length. If the data in a field is 0, it ignores further processing of the field. After waiting for the processing to be completed, the rsp information is encapsulated. The version field of rsp carries the version information in the node memory, and modify=0 is sufficient and returned to the client. After the client receives the reply information rsp of the request req, it compares the version in rsp with the version information of the RPM of this node. If they are not equal, the client processes the rsp data in combination with the modify status in the higher version data structure, fills the newly added fields with the initialization value and performs subsequent processing. For deleted fields, the content of the field in the rsp data is no longer concerned.

[0074] It can be seen that in the embodiment of the present application, the client service and the server service in the node can interact with each other in the case of inconsistent versions through changes in the data structure.

[0075] In a possible implementation of an embodiment of the present application, the first party is a node in a distributed cluster, and the second party is the current node; the data interaction method during online upgrading also includes: if the first version of the first party is smaller than the second version of the second party, then according to the data update operation corresponding to the type field in the data structure of the second version of the second party and the second version, processing the pending data of the data interaction request.

[0076] Furthermore, according to the data update operation corresponding to the type field in the second version of the data structure of the second party and the second version, the pending data of the data interaction request is processed, including: according to the data update operation corresponding to the type field in the second version of the data structure of the second party, the pending data in the data interaction request is processed to obtain the second target data, and the second target data is processed according to the second version.

[0077] During an online upgrade of a distributed cluster, data exchange between nodes is still required. However, data compatibility must be ensured between the old and new versions. Unlike the client and server service interactions within a single node, node interactions within a cluster can involve situations where the first party has a newer version than the second party, and vice versa. Therefore, the version field can be filled in when sending and receiving data, and the type field must also be filled in when the node itself is a higher version. Each time the second party obtains information from the first party, it first parses the version number and processes the received data based on whether it carries the type field. After processing, it replies to the first party. When encapsulating the reply information, it should also determine whether the type field needs to be carried based on the version number. This allows for efficient communication between nodes of different versions.

[0078] Regarding the exchange of communication information between cluster nodes, inter-node communication can also be considered as communication between client nodes and server nodes. In intra-cluster inter-node communication, a node that has not yet started upgrading is the client, while another node that has completed upgrading is the server. In this case, the client version number is lower than the server version number. When the client sends a request message, it obtains the version of the node from its in-memory version list. If the version is older, it enters the version field in the request message, and data carrying the older version can be submitted to the server node. After receiving the request message, the server node parses the version information carried.

[0079] If the value is less than the node's version, the node applies the default modify information in its own data structure. If modify = 2, the request data is processed normally, and the default initialization logic is used for newly added fields. If modify = 1, the server only parses and processes the non-deleted fields in the request data structure, and does not process deleted fields. If modify = 3, the server first parses and processes the non-deleted fields in the request, and uses the initialization logic for newly added fields. After the server completes processing, it encapsulates the results in the latest version data structure, populates the server's version information with the version information, and populates the modify information with the modify information in the new version data structure. After this is complete, the data is sent to the client. After receiving the reply message from the server node, the client node checks the version carried in the rsp and its own version. If its own version is smaller than the rsp version, the client node does not yet have the ability to process the newly added fields. Therefore, the client node only needs to parse and process the field of its own data structure length. If modify=2 or modify=3, it means that a field has been deleted from the data structure on the server side. In this case, when the data of a field is 0, further processing of this stage can be abandoned.

[0080] It can be seen that in the embodiment of the present application, it is possible for nodes in a distributed cluster to interact during the upgrade process.

[0081] A possible implementation method of an embodiment of the present application, after parsing the data interaction request and obtaining the first version of the first party and the type field of the first party, also includes: reading the version of this node from the version list in the memory of this node as the second version.

[0082] A possible implementation method of an embodiment of the present application is to process the pending data in the data interaction request according to the consistent version, including: if the consistent version is an upgraded version, processing the pending data in the data interaction request based on the upgraded version; if the processing fails, controlling the current node to automatically roll back to the version before the upgrade, and processing the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version.

[0083] In an embodiment of the present application, if a failure occurs in the process of processing the data to be processed based on the upgraded version, the failure may be caused by a logical error in the node itself. If the processing cannot be completed after repeated processing for a preset number of times, the node is controlled to automatically roll back to the version before the upgrade; after the rollback is completed, the data to be processed of the data interaction request is reprocessed according to the data update operation corresponding to the type field of the first party and the second version, to ensure that the data interaction request can be processed correctly, thereby improving the stability and reliability of the system.

[0084] It can be seen that in the embodiment of the present application, by first trying to process data based on the upgraded version, if it fails, it automatically falls back to the version before the upgrade to process the data, thereby improving the stability and reliability of the system.

[0085] A possible implementation method of an embodiment of the present application also includes: when the upgrade of the current node is completed and restarted, parsing the version of the software data package, and using the version of the software data package as the upgraded version of the current node, and writing the upgraded version of the current node into the version list in the memory of the current node; adding the current node to the distributed cluster, and sending the upgraded version of the current node to each node in the distributed cluster, so that each node updates the version list in its own memory.

[0086] See also Figure 5 , Figure 5 This is a flow chart of updating the node memory version number during an online cluster upgrade process provided by an embodiment of the present application. A version list is maintained in the process memory of each node, which records the version information of the services currently running on each node in the distributed cluster. The version lists maintained in the memory of each node are consistent. Before the upgrade, the version in the memory of each node = V1. After waiting for node A to update the RPM package of version V2, when node A restarts the service, it first parses the version number of the RPM and records it in its own memory. When waiting for node A to join the cluster, A notifies node B and node C of its own version number. Node B and node C update the version number of node A recorded in their own memory. At the same time, node B and node C synchronize the version number to A, and finally achieve consistency in the list information maintained in the memory of each node.

[0087] It can be seen that in the embodiment of the present application, when the upgrade of this node is completed and restarted, the upgraded version of this node is written into the version list in the memory of this node; this node is added to the distributed cluster, and the upgraded version of this node is sent to each node in the distributed cluster, so that each node updates the version list in its own memory, so that each node maintains the latest node version information.

[0088] Furthermore, when all nodes are upgraded and switched to the new version of communication, the reading of certain static data still requires structural transformation, which will also affect the operation of the business to a certain extent for a short period of time. If the data structure in the database needs to be modified during the version upgrade, the present invention proposes to add a new mapped storage data in the database, which is constructed with the data structure in the new version, and designs the data conversion rules between the old and new versions. Specifically, a possible implementation method of the embodiment of the present application also includes: receiving a static data read request for the database; during the distributed cluster upgrade process, the database includes old version data and new version data, and the new version data is constructed based on the old version data using the data structure of the upgraded version; if the current node is the node before the upgrade, the data is read from the old version data; if the current node is the upgraded node, the data is read from the new version data.

[0089] Furthermore, a static data write request for the database is received; and corresponding data is written to both the old version data and the new version data based on the static data write request and the upgrade version field. Furthermore, when the distributed cluster upgrade is complete, the data corresponding to the new version data in the old version data is deleted, resulting in an updated database.

[0090] During an online cluster upgrade, the new version reads and writes new data, while the old version reads and writes old data. When a write operation occurs, the new and old versions synchronize their data according to the established conversion rules, ensuring data consistency between the new and old versions. When the upgrade is complete, the old version's data is cleared, leaving only the new version's data.

[0091] See also Figure 6 , Figure 6 It is a flowchart of the compatible processing of static database data between different versions provided by an embodiment of the present application. In the present invention, the distributed cluster system can use the key-value method of the etcd database to store static configuration data. When the cluster starts to upgrade, the data involved in the structural changes in this upgrade is first mapped to create a new structure data key-value pair new_key-new_value. During the upgrade process, each time the database is read and written, the current version is first determined. If it is in the old version, key-value is read and written. If it is in the new version, new_key-new_value is read and written. The put (write) operation of key or new_key will be monitored through etcd_watcher. If it is detected to be written, the unique compatibility logic will be called to synchronize the values ​​of value and new_value, thus ensuring the consistency of the reading and writing of static data by nodes in the cluster. When the cluster upgrade is completed, the key-value will be deleted, and then the new_key will be modified to key to achieve a smooth upgrade of static data.

[0092] For example, if the key-value corresponding to the structural data is node-ip, the new_key-new_value after the update is node-(ip+port number). If the amount of structural data is 100, and the amount of structural data involved in the cluster upgrade is 50, then 50 new_key-new_value pairs are mapped out, and the data supply is 150. After the upgrade is completed, the 50 unchanged data in the key-value and the 50 new_key-new_value pairs are retained, totaling 100, to achieve the update of static data.

[0093] It can be seen that in the embodiment of the present application, for the data in the static database, the present invention adopts a new and old data mapping method. During the upgrade process, the new version reads and writes data with a new structure, and the old version reads and writes data with an old data structure. After the upgrade is completed, it switches to the new data structure data uniformly to achieve smooth online upgrade of the cluster, greatly reducing the probability of upgrade failure and improving the stability of the online upgrade business operation of the distributed cluster.

[0094] A possible implementation method of an embodiment of the present application is that if the first version of the first party is greater than the second version of the second party, the pending data of the data interaction request is processed according to the data update operation corresponding to the type field of the first party and the second version, including: if the first version of the first party is greater than the second version of the second party, the pending data of the data interaction request is processed according to the data update operation corresponding to the type field of the first party and the second version; if the processing fails, the pending data is written into the waiting queue, and when the current node is successfully upgraded, the pending data is read from the waiting queue, and the pending data is processed according to the upgraded version.

[0095] The waiting queue is a data structure used to temporarily store data that cannot be processed. In this step, it is used to store data to be processed that has failed.

[0096] Optionally, if processing fails, the second party encapsulates the pending data into a specific data structure and writes it to a waiting queue in memory. Simultaneously, a scheduled task is set to regularly check the upgrade status of this node. Upon detecting a successful upgrade, the scheduled task reads the pending data from the waiting queue, processes it based on the upgraded version, and returns the results to the first party.

[0097] Optionally, a message-based middleware can be introduced as a waiting queue. If processing fails, the second party sends the pending data to the message-based middleware in the form of a message. The message contains detailed information about the pending data and the first party's identifier. During the upgrade process, the node records the upgrade progress and status. When the upgrade is successful, the node subscribes to messages related to itself from the message-based middleware and processes the upgrade based on the pending data and the first party's identifier in the message.

[0098] Optionally, a waiting queue table is created in the database. If processing fails, the second party inserts relevant information about the pending data, such as the data content, type field, and first-party identifier, into the waiting queue table. When the current node is upgraded, a corresponding upgrade script will record the upgrade operation. After the upgrade is successful, the current node queries the waiting queue table, obtains the pending data, and processes it.

[0099] It can be seen that in the embodiment of the present application, by first writing the unprocessed data into the waiting queue and then reprocessing it after the current node is successfully upgraded, data processing interruptions caused by version issues are avoided, business continuity is guaranteed, and the system can transition more smoothly during the version upgrade process, ensuring the integrity and accuracy of data interaction.

[0100] A possible implementation method of an embodiment of the present application also includes: if the current node is not the first batch of test upgrade nodes in the distributed cluster, then receiving the test success information of the first batch of test nodes; wherein, the first batch of test upgrade nodes are used to verify that data processing can be performed when the first version of the first party and the second version of the second party are inconsistent.

[0101] In the embodiment of the present application, when a version upgrade is required, it is not a random upgrade, but a plurality of upgrade nodes are first determined as the first batch of test upgrade nodes, and some nodes are upgraded first to verify that the functions are normal and that they can interact in accordance with the communication method of adding fields provided in the present application. If the test is successful, the nodes in the cluster are randomly upgraded and the full upgrade promotion is carried out. In the embodiment of the present application, some nodes are first upgraded in a small range, and the interaction between the upgraded nodes and the non-upgraded nodes is observed. If no serious problems occur, the upgrade range is gradually expanded until all nodes are upgraded, effectively reducing the upgrade risk, ensuring the stability and reliability of the system, and improving communication efficiency.

[0102] Furthermore, during the test process, you can simulate the interaction situations in various business scenarios and determine the interaction success rate in each business scenario. For target business scenarios with low interaction success rates, when the versions are inconsistent, you can write the request into the pause queue and process the request when the versions are consistent.

[0103] A possible implementation method of the embodiment of the present application also includes: if the current node has not been upgraded and receives data interaction requests from upgraded nodes exceeding a preset number within a preset time period, it is determined that the current node has more business, and therefore, a priority upgrade request is sent to the master node; in response to the upgrade command of the master node, the current node executes the upgrade process.

[0104] If the data interaction method isn't suitable for this node, meaning data processing accuracy is low, a virtual interaction environment can be created. This virtual environment can be a virtual machine, container, or virtual network. A middleware can be deployed within this virtual environment to serve as a bridge for interaction between this node and other nodes. The middleware can simulate the operating environment and functionality of the node's version. Other nodes will send requests to the middleware, which converts the request and then forwards it to the node. This method achieves version isolation between nodes and avoids compatibility issues that can arise from direct interaction.

[0105] Based on any of the above embodiments, the present application includes the following steps, including defining communication data rules, maintaining version number information during the upgrade process, communicating and parsing data of different versions, and handling compatibility of static database data: Step 1. Adding version number information and data change type information to communication-related data. During an online cluster upgrade, this information is encapsulated in the communication data for the receiving party to parse and process accordingly. Step 2. Each node in the cluster maintains a copy of the version information for all nodes and updates this information when the node completes the upgrade and restarts. This facilitates the node's ability to quickly identify its own version information when encapsulating or receiving information, comparing it with the version information in the communication data and selecting the appropriate processing method. Step 3. During communication between the client and server within a node, or between different nodes, different processing methods are applied based on the version number and data structure change type in the communication data. Only data that is compatible between higher and lower versions is processed, while incompatible data is ignored, thereby achieving efficient information communication. Step 4. During an online upgrade, if both higher and lower version data exist in static data, the two copies of data are mapped and synchronized in real time after each write, ultimately switching to the new version.

[0106] In this application, first, version number information and data change type information are added to the communication data structure involved in the cluster online upgrade process. In addition, a node version list is maintained in the memory information of each node, which is used to record the version information of the program currently running on each node in real time. When data communication is carried out within a node or between different nodes, the version number of the information and the change type information of the new version of the data are carried. The different versions of the process in the cluster parse and process the communication data accordingly according to the version number information and data change type carried by the communication data and the agreed rules, and finally achieve smooth compatibility of communication data between different versions in the cluster during the online upgrade process. At the same time, in order to achieve the compatibility of different versions of data in the static database, the present invention proposes that the old and new versions of the data exist at the same time during the upgrade process, and they are mapped and associated. The processes of different versions read and write the data of their respective versions, and the two copies of the data are synchronized in real time, and then uniformly switch to the new version of the data after the upgrade is completed.

[0107] The following is an introduction to a device provided in an embodiment of the present application. The device described below and the method described above can be referenced to each other. The device of this embodiment is set in an electronic device. Figure 7 , Figure 7 It is a structural block diagram of an apparatus of one embodiment of the present application, comprising: an acquisition module 210, for acquiring a data interaction request from the first party during a distributed cluster upgrade process, wherein a version field and a type field are added to the data header of the data interaction request; if the first version of the first party is an upgraded version, the version field is an upgraded version field, and the type field is a data update operation of the upgraded version; a parsing module 220, for parsing the data interaction request to obtain the first version of the first party and the type field of the first party; a first processing module 230, for processing the pending data in the data interaction request according to the consistent version if the first version of the first party and the second version of the second party are consistent; a second processing module 240, for processing the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version if the first version of the first party is greater than the second version of the second party.

[0108] The first processing module 230 and the second processing module 240 may be the same module or different modules, which is not limited in the embodiment of the present application.

[0109] In a preferred example, the present application can be further configured as: a second processing module 240 is used to process the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party, obtain the first target data, and process the first target data according to the second version.

[0110] In a preferred example, the present application can be further configured as: a second processing module 240, which is used to remove the added field of the data to be processed in the data interaction request if the type field of the first party is an add type, and obtain the first target data, and the added field is the added field corresponding to the add type; if the type field of the first party is a delete type, then fill the deleted field of the data to be processed in the data interaction request with zeros, and obtain the first target data, and the deleted field is the deleted field corresponding to the delete type; if the type field of the first party is a delete-add type, then remove the added field of the data to be processed in the data interaction request, and then fill the deleted field of the data to be processed in the data interaction request with zeros, and obtain the first target data.

[0111] In a preferred example, the present application may be further configured as follows: if the first version of the first party is smaller than the second version of the second party, the version field and type field of the data header of the data interaction request are empty or zero.

[0112] In a preferred example, the present application can be further configured as follows: the first party is the client service within the node, and the second party is the server service within the node; the first version of the first party is the version of the software data package within the node, and the second version of the second party is the version of the node in the version list in the memory of the node, and the version list stores the version of each node in the distributed cluster.

[0113] In a preferred example, the present application can be further configured as follows: the first party is a node in a distributed cluster, and the second party is the current node; the data interaction device during online upgrading also includes: a third processing module, which is used to process the pending data of the data interaction request according to the data update operation corresponding to the type field in the data structure of the second version of the second party and the second version if the first version of the first party is smaller than the second version of the second party.

[0114] In a preferred example, the present application can be further configured as: a third processing module, used to: process the data to be processed in the data interaction request according to the data update operation corresponding to the type field in the second version of the data structure of the second party, obtain the second target data, and process the second target data according to the second version.

[0115] In a preferred example, the present application may be further configured to include: a reading module configured to read the version of the node from the version list in the memory of the node as the second version.

[0116] In a preferred example, the present application can be further configured as: a first processing module 230, used to: if the consistent version is an upgraded version, process the pending data in the data interaction request based on the upgraded version; if the processing fails, control this node to automatically roll back to the version before the upgrade, and process the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version.

[0117] In a preferred example, the present application can be further configured as follows: it also includes: a synchronization module, which is used to parse the version of the software data package after the upgrade of the node is completed and restarted, and use the version of the software data package as the upgraded version of the node, and write the upgraded version of the node into the version list in the memory of the node; add the node to the distributed cluster, and send the upgraded version of the node to each node in the distributed cluster, so that each node updates the version list in its own memory.

[0118] In a preferred example, the present application can be further configured as follows: it also includes: a reply module, which is used to encapsulate the processed data according to the second version of the second party and the type field corresponding to the second version to obtain reply information; and return the reply information to the first party.

[0119] In a preferred example, the present application can be further configured as follows: it also includes: a static data reading module for receiving static data reading requests for the database; during the distributed cluster upgrade process, the database includes old version data and new version data, and the new version data is constructed based on the old version data using the data structure of the upgraded version; if the current node is a pre-upgrade node, data is read from the old version data; if the current node is an upgraded node, data is read from the new version data.

[0120] In a preferred example, the present application can be further configured to include: a static data writing module for receiving a static data writing request for a database; and writing corresponding data in both the old version data and the new version data according to the static data writing request and the upgrade version field.

[0121] In a preferred example, the present application can be further configured to include: a database update module for deleting the data corresponding to the new version data in the old version data after the distributed cluster upgrade is completed, to obtain an updated database.

[0122] In a preferred example, the present application can be further configured as: a second processing module 240, which is used to: if the first version of the first party is greater than the second version of the second party, process the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version; if the processing fails, write the pending data into the waiting queue, and when the current node is successfully upgraded, read the pending data from the waiting queue and process the pending data according to the upgraded version.

[0123] In a preferred example, the present application can be further configured as follows: it also includes: a receiving module, which is used to receive the test success information of the first batch of test nodes if the current node is not the first batch of test upgrade nodes in the distributed cluster; wherein, the first batch of test upgrade nodes are used to verify that data processing can be performed when the first version of the first party and the second version of the second party are inconsistent.

[0124] Figure 8 A structural diagram of an electronic device provided by an embodiment of the present invention, such as Figure 8 As shown, the electronic device includes: a memory 60 for storing computer programs; a processor 61 for implementing the steps of the data interaction method during online upgrade in the above embodiment when executing the computer program.

[0125] The processor 61 may include one or more processing cores, such as a quad-core processor or an octa-core processor. The processor 61 may be implemented using at least one of the following hardware forms: a digital signal processing (DSP), a field-programmable gate array (FPGA), or a programmable logic array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 61 may be integrated with a graphics processing unit (GPU), which is responsible for rendering and drawing content required to be displayed on the display screen. In some embodiments, the processor 61 may also include an artificial intelligence (AI) processor for handling computational operations related to machine learning.

[0126] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 60 is at least used to store the following computer program 601, wherein, after the computer program is loaded and executed by the processor 61, it can implement the relevant steps of the method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 602 may include Windows, Unix, Linux, etc.

[0127] In some embodiments, the electronic device may further include a display screen 62 , an input / output interface 63 , a communication interface 64 , a power supply 65 , and a communication bus 66 .

[0128] Those skilled in the art will understand that Figure 8 The structure shown in the figure does not constitute a limitation of the electronic device, and may include more or fewer components than shown in the figure.

[0129] It is understood that if the data interaction method during online upgrades in the above-mentioned embodiment is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the current technology, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and executes all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), an electrically erasable programmable ROM, a register, a hard disk, a removable disk, a CD-ROM, a magnetic disk, or an optical disk, and other media that can store program code.

[0130] Based on this, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the above-mentioned online upgrade data interaction method are implemented.

[0131] Based on this, an embodiment of the present invention further provides a computer program product, including a computer program / instruction, which implements the steps of the above-mentioned online upgrade data interaction method when executed by a processor.

[0132] The above describes in detail the data interaction method, apparatus, device, medium, and product for online upgrades provided by the embodiments of the present invention. The various embodiments are described in a progressive manner throughout this specification, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between the various embodiments can be referenced to each other. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; for relevant details, refer to the method description.

[0133] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present invention.

[0134] The above is a detailed introduction to the data interaction method, device, equipment, medium and product for online upgrading provided by the present invention. Specific examples are used herein to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present invention, the present invention can also be improved and modified in a number of ways, and these improvements and modifications also fall within the scope of protection of the present invention.

Claims

1. A data interaction method for online upgrading, characterized in that: include: During a distributed cluster upgrade, a data interaction request from a first party is obtained. A version field and a type field are added to a data header of the data interaction request. If the first version of the first party is an upgraded version, the version field is an upgraded version field, and the type field is a data update operation of the upgraded version. Parsing the data interaction request to obtain a first version of the first party and a type field of the first party; If the first version of the first party is consistent with the second version of the second party, processing the to-be-processed data in the data interaction request according to the consistent versions; If the first version of the first party is greater than the second version of the second party, processing the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version; Processing the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version, including: If the type field of the first party is an add type, removing the add field of the to-be-processed data of the data interaction request to obtain the first target data, where the add field is an added field corresponding to the add type; If the type field of the first party is a deletion type, the deletion field of the to-be-processed data of the data exchange request is padded with zeros to obtain the first target data, where the deletion field is a deleted field corresponding to the deletion type; If the type field of the first party is a delete-add type, removing the add field of the to-be-processed data of the data exchange request, and then filling the delete field of the to-be-processed data of the data exchange request with zeros to obtain the first target data; The first target data is processed according to the second version.

2. The data interaction method during online upgrade according to claim 1, characterized in that: If the first version of the first party is smaller than the second version of the second party, the version field and the type field of the data header of the data interaction request are empty or zero.

3. The data interaction method during online upgrade according to claim 1, characterized in that: The first party is a client service within the node, and the second party is a server service within the node; The first version of the first party is the version of the software package inside the node, and the second version of the second party is the version of the local node in the version list in the memory of the local node, and the version list stores the version of each node in the distributed cluster.

4. The data interaction method during online upgrade according to claim 1, characterized in that: The first party is a node in the distributed cluster, and the second party is the current node; The data interaction method during online upgrade further includes: If the first version of the first party is smaller than the second version of the second party, the pending data of the data interaction request is processed according to the data update operation corresponding to the type field in the data structure of the second version of the second party and the second version.

5. The data interaction method during online upgrade according to claim 4, characterized in that: Processing the to-be-processed data of the data interaction request according to the data update operation corresponding to the type field in the second version of the data structure of the second party and the second version, including: According to the data update operation corresponding to the type field in the second version of the data structure of the second party, the to-be-processed data in the data interaction request is processed to obtain second target data, and the second target data is processed according to the second version.

6. The data interaction method during online upgrade according to claim 4, characterized in that: After parsing the data interaction request to obtain the first version of the first party and the type field of the first party, the method further includes: The version of this node is read from the version list in the memory of this node as the second version.

7. The data interaction method during online upgrade according to claim 4, characterized in that: Processing the data to be processed in the data interaction request according to the consistent version, including: If the consistent version is an upgraded version, the pending data in the data interaction request is processed based on the upgraded version; if the processing fails, the node is controlled to automatically roll back to the version before the upgrade, and the pending data of the data interaction request is processed according to the data update operation corresponding to the type field of the first party and the second version.

8. The data interaction method during online upgrade according to claim 3 or 6, characterized in that: Also includes: After the node is upgraded and restarted, the version of the software package is parsed, and the version of the software package is used as the upgraded version of the node, and the upgraded version of the node is written into the version list in the memory of the node; Add the current node to the distributed cluster, and send the upgraded version of the current node to each node in the distributed cluster, so that each node updates the version list in its memory.

9. The data interaction method during online upgrade according to any one of claims 1 to 7, characterized in that: After processing the data to be processed in the data interaction request, the method further includes: encapsulate the processed data according to the second version of the second party and the type field corresponding to the second version to obtain reply information; The reply information is returned to the first party.

10. The data interaction method during online upgrade according to claim 1, characterized in that: Also includes: Receive static data read requests for the database; During the distributed cluster upgrade process, the database includes old version data and new version data, and the new version data is constructed based on the old version data using the data structure of the upgraded version; If the current node is a pre-upgrade node, read the data from the old version data; If the node is an upgraded node, data is read from the new version data.

11. The data interaction method during online upgrade according to claim 10, characterized in that: Also includes: receiving a static data write request for the database; According to the static data write request and the upgrade version field, corresponding data is written into both the old version data and the new version data.

12. The data interaction method during online upgrade according to claim 10, characterized in that: Also includes: When the distributed cluster upgrade is completed, the data corresponding to the new version data in the old version data is deleted to obtain an updated database.

13. The data interaction method during online upgrade according to claim 1 or 10, characterized in that: If the first version of the first party is greater than the second version of the second party, processing the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version, including: If the first version of the first party is greater than the second version of the second party, the pending data of the data interaction request is processed according to the data update operation corresponding to the type field of the first party and the second version; if the processing fails, the pending data is written into the waiting queue. When the current node is successfully upgraded, the pending data is read from the waiting queue and processed according to the upgraded version.

14. The data interaction method during online upgrade according to claim 1, characterized in that: Also includes: If the current node is not one of the first batch of test upgrade nodes in the distributed cluster, then the test success information of the first batch of test nodes is received; Among them, the first batch of test upgrade nodes is used to verify that data processing can be performed when the first version of the first party and the second version of the second party are inconsistent.

15. A data interaction device for online upgrading, characterized in that: include: An acquisition module is configured to acquire a data interaction request from a first party during a distributed cluster upgrade process, wherein a version field and a type field are added to a data header of the data interaction request; if the first version of the first party is an upgraded version, the version field is an upgraded version field, and the type field is a data update operation for the upgraded version; a parsing module, configured to parse the data interaction request to obtain the first version of the first party and the type field of the first party; a first processing module, configured to process the to-be-processed data in the data interaction request according to the consistent versions if the first version of the first party and the second version of the second party are consistent; a second processing module, configured to process the pending data of the data interaction request according to the data update operation corresponding to the type field of the first party and the second version, if the first version of the first party is greater than the second version of the second party; a second processing module configured to, if the type field of the first party is an add type, remove the add field of the to-be-processed data of the data interaction request to obtain first target data, where the add field is an add field corresponding to the add type; If the type field of the first party is a deletion type, the deletion field of the to-be-processed data of the data exchange request is padded with zeros to obtain the first target data, where the deletion field is a deleted field corresponding to the deletion type; If the type field of the first party is a delete-add type, removing the add field of the to-be-processed data of the data exchange request, and then filling the delete field of the to-be-processed data of the data exchange request with zeros to obtain the first target data; The first target data is processed according to the second version.

16. An electronic device, characterized in that: include: Memory for storing computer programs; A processor is used to execute the computer program to implement the steps of the data interaction method during online upgrade according to any one of claims 1 to 14.

17. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the data interaction method during online upgrade according to any one of claims 1 to 14 are implemented.

18. A computer program product comprising a computer program / instructions, characterized in that When the computer program / instruction is executed by a processor, the steps of the online upgrade data interaction method according to any one of claims 1 to 14 are implemented.

Images