Data interaction method and device during online upgrading, equipment, medium and product

Abstract

The invention relates to the technical field of distributed clusters, in particular to a data interaction method, device, equipment, medium and product during online upgrade.The method comprises the steps that in the distributed cluster upgrading process, a data interaction request of a first party is obtained, and a version field and a type field are added to a data head of the data interaction request; if the first version 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 version; and if the first version is greater than the second version, processing the to-be-processed data of the data interaction request according to the data updating operation corresponding to the type field of the first party and the second version. By means of the method, when the distributed cluster is upgraded online, the first party and the second party of different versions can communicate normally, smooth online upgrading between the high version and the low version is achieved, the risk of upgrading failure is greatly reduced, the stability and reliability of service operation can be guaranteed in the large-scale cluster upgrading process, and the upgrading efficiency of the distributed cluster is improved. And zero-sensing system version switching is basically realized.

Description

Technical Field

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

[0002] With the rapid development of cloud computing, big data, and AI technologies, distributed cluster systems have become the core infrastructure to support large-scale business scenarios. Distributed cluster systems usually consist of multiple nodes and are often used to support services with high concurrency, low latency, and continuous online. However, with the continuous iteration and update of functions and technologies, distributed cluster systems need to be upgraded frequently. To ensure the continuity and reliability of running services, the upgrade of distributed cluster systems needs to ensure online service upgrade.

[0003] When the distributed cluster system performs an online upgrade, all nodes in the distributed cluster system cannot completely replace the RPM packages (Red Hat Package Manager, software data packages) at the same time and cannot restart the services simultaneously. As a result, there will be a situation of inconsistent versions within the distributed cluster system. One case is that the RPM package of a certain node has been updated, but its storage service has not been restarted yet. At this time, the communication between the client service (client-side service) and the server service (server-side service) on this node belongs to data communication between different versions. The second case is that some nodes in the distributed cluster system have been upgraded to the new version, while the remaining nodes have not been upgraded and are still in the old version. At this time, the communication between these nodes belongs to data communication between different versions of nodes. Therefore, when the data structures for communication between the new and old versions are the same, even if the distributed cluster system is in the process of online upgrade, various data communications can proceed normally. However, the optimization of functions and the repair of problems are often accompanied by changes in the data structure, that is, some data structures in the new version will change, such as addition or deletion, compared with the old version. If the data structures used for communication between the new version and the old version change, it may lead to communication failures between the client service and the server service of the same node or between different nodes during the upgrade process, and the communication data cannot be effectively parsed after receiving the data from the peer, resulting in communication anomalies, which in turn affect the business operation of the system. Currently, for such problems, the common approach is to completely retain a set of old-version data structures in the new-version code. When the distributed cluster system needs to be upgraded online, regardless of whether the nodes in the distributed cluster system have completed the upgrade, these nodes are allowed to continue to communicate in the old-version manner. After the distributed cluster system has been fully upgraded, they are then uniformly switched to the new-version data structure for communication. This method can avoid communication between different-version data, but it has a defect when large-scale distributed clusters are upgraded online. A large-scale distributed cluster system may involve hundreds, thousands, or even tens of thousands of nodes, and the online upgrade cannot be completed quickly in a short time. It is possible that the devices at some sites have been upgraded, while the devices at some sites have not been upgraded. In this way, even the nodes that have completed the upgrade cannot immediately provide new functions externally. In addition, if some nodes encounter failures during the upgrade process and require a certain amount of time for fault location and repair, it will also affect the nodes that have completed the upgrade from providing the latest functions externally.

[0004] It can be seen that how to efficiently perform data interaction during the upgrade of the distributed cluster is a problem that needs to be solved by those skilled in the art. 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 upgrade of the distributed cluster.

[0006] In a first aspect, a data interaction method during online upgrade is provided, including: during the upgrade process of a distributed cluster, obtaining a data interaction request of a first party, where version fields and type fields are added to the data header of the data interaction request. If the first version of the first party is an upgrade version, the version field is an upgrade version field and the type field is a data update operation for the upgrade 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 the same as the second version of the second party, processing the data to be processed in the data interaction request according to the same version; if the first version of the first party is greater than the second version of the second party, processing the data to be processed in 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 of the present application, it can be further configured that: processing the data to be processed in the data interaction request according to the data update operation corresponding to the type field of the first party and the second version includes: processing the data to be processed in the data interaction request according to the data update operation corresponding to the type field of the first party to obtain first target data, and processing the first target data according to the second version.

[0008] In a preferred example of the present application, it can be further configured that: processing the data to be processed in the data interaction request according to the data update operation corresponding to the type field of the first party to obtain first target data includes: if the type field of the first party is an addition type, removing the addition fields of the data to be processed in the data interaction request to obtain the first target data, where the addition fields are the added fields corresponding to the addition type; if the type field of the first party is a deletion type, filling the deletion fields of the data to be processed in the data interaction request with zeros to obtain the first target data, where the deletion fields are the deleted fields corresponding to the deletion type; if the type field of the first party is a deletion-addition type, removing the addition fields of the data to be processed in the data interaction request, and then filling the deletion fields of the data to be processed in the data interaction request with zeros to obtain the first target data.

[0009] In a preferred example of the present application, it can be further configured that: if the first version of the first party is less than the second version of the second party, the version field and type field in 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 the client service inside the present node, and the second party is the server service inside the present node; the first version of the first party is the version of the software data packet inside the node, and the second version of the second party is the version of the present node in the version list in the memory of the present node, and the version list stores the versions 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 present node; the method for data interaction during online upgrade further includes: if the first version of the first party is less than the second version of the second party, then process the data to be processed in 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.

[0012] In a preferred example, the present application can be further configured as follows: process the data to be processed in 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, including: process the data to be processed in 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 to obtain second target data, and process 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 to obtain the first version of the first party and the type field of the first party, it further includes: read the version of the present node from the version list in the memory of the present node as the second version.

[0014] In a preferred example, the present application can be further configured as follows: process the data to be processed in the data interaction request according to a consistent version, including: if the consistent version is an upgrade version, then process the data to be processed in the data interaction request based on the upgrade version; if the processing fails, then control the present node to automatically roll back to the version before the upgrade, and process the data to be processed in 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 further includes: after the present node completes the upgrade and restarts, parse the version of the software data packet, and use the version of the software data packet as the version after the upgrade of the present node, and write the version after the upgrade of the present node into the version list in the memory of the present node; add the present node to the distributed cluster, and send the version after the upgrade of the present 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 further 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 a reply message; and returning the reply message to the first party.

[0017] In a preferred example, the present application can be further configured as follows: it further includes: receiving a static data reading request for the database; during the upgrade process of the distributed cluster, 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 upgrade version; if this node is a pre-upgrade node, read data from the old version data; if this node is an upgrade node, read data from the new version data.

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

[0019] In a preferred example, the present application can be further configured as follows: it further includes: after the upgrade of the distributed cluster 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 process the data to be processed in 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 process the data to be processed in 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 data to be processed into the waiting queue, and after this node is successfully upgraded, read the data to be processed from the waiting queue and process the data to be processed according to the upgrade version.

[0021] In a preferred example, the present application can be further configured as follows: it further includes: if this node is not one of the first batch of test upgrade nodes in the distributed cluster, then receive 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 is inconsistent with the second version of the second party.

[0022] In a second aspect, a data interaction device during online upgrade is provided, including: an acquisition module, configured to acquire a data interaction request of a first party during the upgrade process of a distributed cluster, where 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 upgrade version, the version field is an upgrade version field and the type field is a data update operation for the upgrade 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, if the first version of the first party is the same as the second version of the second party, process the data to be processed in the data interaction request according to the same version; a second processing module, configured to, if the first version of the first party is greater than the second version of the second party, process the data to be processed in the data interaction request according to the data update operation corresponding to the type field of the first party and the second version.

[0023] In a third aspect, an electronic device is provided. The electronic device includes a memory and a processor. A computer program is stored in the memory, and when the processor runs the computer program, it executes the data interaction method during online upgrade according to any one of the first aspect.

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

[0025] In a fifth aspect, a computer program product is provided, including a computer program or instruction. When the computer program or instruction is executed by the processor, it implements the data interaction method during online upgrade according to any one of the first aspect.

[0026] In summary, the data interaction method during online upgrade provided by this application includes the following beneficial technical effects: During the upgrade process of a distributed cluster, obtain the data interaction request of the first party. The data header of the data interaction request adds a version field and a type field. If the first version of the first party is the upgrade version, the version field is the upgrade version field and the type field is the data update operation of the upgrade version; parse 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 the same as the second version of the second party, process the data to be processed 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, process the data to be processed in the data interaction request according to the data update operation corresponding to the type field of the first party and the second version. Through this method, during the online upgrade of a distributed cluster, the first party and the second party with different versions can communicate normally, realizing smooth online upgrade between high and low versions, greatly reducing the risk of upgrade failure, ensuring the stable and reliable operation of the service during the upgrade process of a large-scale cluster, and basically achieving zero-perception system version switching.

[0027] In addition, this application also provides a data interaction device, device, medium, and product during online upgrade, all of which have the above beneficial technical effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] To more clearly illustrate the embodiments of the present invention, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0029] Figure 1 It is a schematic flowchart of a data interaction method during online upgrade provided by an embodiment of this application.

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

[0031] Figure 3 It 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 this application.

[0032] Figure 4 It is a schematic diagram of the interaction process between the first party and the second party provided by an embodiment of this application.

[0033] Figure 5 It is a schematic flowchart of the version number update of the node memory during the online upgrade process of the cluster provided by an embodiment of this application.

[0034] Figure 6It is a schematic flowchart of the compatibility processing of static database data between different versions provided by an embodiment of the present application.

[0035] Figure 7 It is a schematic structural diagram of a data interaction device during online upgrade provided by an embodiment of the present application.

[0036] Figure 8 It is a schematic structural diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0037] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the protection scope of the present invention.

[0038] The terms "including" and "having" in the specification of the present invention and the accompanying drawings above, as well as any variations related to "including" and "having", are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may include steps or units not listed.

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

[0040] Distributed storage systems often undertake important customer services. When version upgrades are required, the online upgrade method is usually adopted. When a distributed storage system is upgraded online, each node in the cluster often adopts a rolling upgrade method, that is, each node is upgraded serially. Therefore, during the upgrade process, new and old version nodes in the cluster may coexist. When the new version of the product adds more new features and functions, the underlying data structure will change greatly. In this way, data communication between the new and old versions faces the risk of failure, and a specific method needs to be adopted for processing to better meet the reliability and stability of the services provided by the distributed storage system during the online upgrade process.

[0041] Since the underlying layer is a distributed storage system, which undertakes the role of providing service I / O to the outside, in order to achieve the continuity of services during the upgrade process, therefore, in combination with the needs of product iteration output, the present invention proposes a method for processing data interaction during the online upgrade of a distributed cluster. As Figure 1As shown, the method provided in the embodiments of the present application can be executed by an electronic device. The electronic device is a node in a distributed cluster. The node can be an independent physical server, or a server cluster or a distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. The node can also be a terminal device, such as a smart phone, a tablet computer, a laptop computer, a desktop computer, etc., but is not limited thereto. The terminal device and the electronic device can be directly or indirectly connected through wired or wireless communication methods. The embodiments of the present application do not limit this. The method includes: S101. During the upgrade process of the distributed cluster, obtain a data interaction request from a first party. The data header of the data interaction request adds a version field and a type field. If the first version of the first party is an upgrade version, the version field is an upgrade version field and the type field is a data update operation of the upgrade version.

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

[0043] In the embodiments of the present application, the data interaction request is a request message that needs to be interacted and sent by the first party. The data header refers to the part of the data interaction request used to carry metadata, and this part adds a version field and a type field. Among them, the version field is used to represent the version of the first party; the type field is used to represent the data update operation of the upgrade version if the first party is an upgrade version; the upgrade version refers to the new version after the distributed cluster is upgraded; the data update operation of the upgrade version means that under the upgrade version, operations such as adding and deleting data are performed.

[0044] It can be understood that all data involved in communication within the distributed cluster is transformed. A version field (version field) and a type field (modify field) are added to the data header. When communicating, the version field is filled with the version information of the sender of this information, and the modify field is a field filled when the high-version communication side sends data during the online upgrade process of the cluster, indicating that the high version has performed operations such as deletion or addition on this structure. This data structure is the basis for data interaction in communication between different versions.

[0045] In an implementable manner, each node in the distributed cluster knows the versions of each other. The first party knows its own first version and the second version of the second party. Only when its own first version is greater than the second version, will the first party fill in the fields corresponding to the upgraded version and the type corresponding to the type field in the version field. Otherwise, both fields are empty or zero. In another implementable manner, each node knows the versions of each other 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 only when the first version is an upgraded version, will it fill in the type field. Of course, there may be other situations, which are not limited in the embodiments of the present application.

[0046] It can be seen that the present invention proposes a definition of the basic format of communication data. Refer to Figure 2 , Figure 2 which is a schematic diagram of the basic format of communication data provided by the embodiments of the present application. A version field (V1 represents the version before upgrade, and V2 represents the upgraded version) and a type field are added to the data related to communication. As Figure 2 shown, the version field is used to record the software version number of the data sender. The type field is only used and valid during the online upgrade process of the cluster. mainly in the code logic that has completed the upgrade, when sending communication data, it identifies what type of change has occurred to the data: type field = 1 represents that some fields have been deleted. In the present invention, it is agreed that the original deleted data range is filled with 0 after the fields are deleted. type field = 2 represents that some fields have been added. In the present invention, it is agreed that the added fields are appended at the end of the original data structure; type field = 3 represents 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 be achieved by deleting a field and adding a field at the same time to replace directly modifying a field. Since the change to the specific communication data structure is caused by manual modification, the modify type of the high version for the specific communication data structure is also fixed, and the default value of the modify for the new version data is the processing done by the new version.

[0047] S102. Analyze the data interaction request to obtain the first version of the first party and the type field of the first party.

[0048] S103. If the first version of the first party is the same as the second version of the second party, process the data to be processed in the data interaction request according to the same version.

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

[0050] S104. If the first version of the first party is greater than the second version of the second party, process the data to be processed in the data interaction request according to the data update operation corresponding to the type field of the first party and the second version.

[0051] When the first version of the first party is greater than the second version of the second party, it means that the first party uses an updated version and the data structure has changed. Then, query the pre-defined operation mapping table according to the type field. This mapping table records the data update operations corresponding to different type fields. Then, based on the data update operation, use the second version to process the data to be processed.

[0052] Specifically, in an implementable manner, the data to be processed in the data interaction request can be processed first based on the data update operation so that the data can adapt to the second version, and then the data is processed based on the second version. In another implementable manner, during the process of processing the data using the second version, targeted processing is performed according to the fields involved in the data update operation.

[0053] Furthermore, when the upgrade of this node fails, version rollback can be automatically performed, so that the old version can still seamlessly take over, thereby greatly reducing the risk faced by the upgrade.

[0054] It can be seen that in the embodiments of this application, during the upgrade process of the distributed cluster, the data interaction request of the first party is obtained. The data header of the data interaction request adds a version field and a type field. If the first version of the first party is the upgrade version, the version field is the upgrade version field and the type field is the data update operation of the upgrade version; parse 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 the same as the second version of the second party, process the data to be processed in the data interaction request according to the same version; if the first version of the first party is greater than the second version of the second party, process the data to be processed in the data interaction request according to the data update operation corresponding to the type field of the first party and the second version. Through this method, when the distributed cluster is upgraded online, the first party and the second party of different versions can communicate normally, realizing smooth online upgrade between high and low versions, greatly reducing the risk of upgrade failure, ensuring the stable and reliable operation of the business during the large-scale cluster upgrade process, and basically realizing zero-perception system version switching.

[0055] It can avoid data processing errors or service interruptions caused by version incompatibility, improve the compatibility and stability of the system, enable different versions of the client and server to work together to a certain extent, ensure the continuity of the business and the accuracy of the data, and at the same time provide more flexible support for system upgrade and version management.

[0056] In a possible implementation manner of the embodiment of the present application, the to-be-processed 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: processing the to-be-processed data 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, and processing the first target data according to the second version.

[0057] Among them, the first target data is the result data obtained by processing the to-be-processed data according to the data update operation corresponding to the type field of the first party. Taking Figure 2 the deletion field type as an example, the data update operation deletes the last preset field. Furthermore, the first target data is the data formed by the data and the preset field filled with zeros, and this data format can adapt to the second version. If the first version is greater than the second version, the second party queries the pre-defined operation mapping table according to the type field. This mapping table records the data update operations corresponding to different type fields; the second party processes the to-be-processed data according to the rules in the mapping table to obtain the first target data. Then, the second party performs business processing on the first target data according to the second version.

[0058] It can be seen that in the embodiment of the present application, when the first version of the first party is greater than the second version of the second party, by first processing the to-be-processed data according to the version and type field of the first party to obtain the first target data, it is ensured that the data interaction request can be correctly processed, and the finally obtained data can be normally used in the environment of the second party; then performing business processing on the first target data according to the second version improves the compatibility and stability of the system.

[0059] Based on the above embodiment, in a possible implementation manner of the embodiment of the present application, the to-be-processed data of the data interaction request is processed 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 the addition type, removing the addition field of the to-be-processed data of the data interaction request to obtain the first target data, and the addition field is the added field corresponding to the addition type; if the type field of the first party is the deletion type, filling the deletion field of the to-be-processed data of the data interaction request with zeros to obtain the first target data, and the deletion field is the deleted field corresponding to the deletion type; if the type field of the first party is the deletion and addition type, removing the addition field of the to-be-processed data of the data interaction request, and then filling the deletion field of the to-be-processed data of the data interaction request with zeros to obtain the first target data.

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

[0061] In a possible implementation manner of the embodiment of the present application, if the first version of the first party is less than the second version of the second party, the version field and the type field in the data header of the data interaction request are empty or zero. It can be seen that in the embodiment of the present application, the version field and the type field are valid only when the first version of the first party is greater than the second version of the second party, which can quickly identify the situations of the two versions and greatly improve the version judgment efficiency.

[0062] In a possible implementation manner of the embodiment of the present application, after processing the data to be processed in the data interaction request, it further 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 a reply message; returning the reply message to the first party.

[0063] It should be noted that the present invention mainly proposes a method for processing data interaction during online upgrade of a distributed cluster. When the distributed cluster is in the process of online upgrade, using this method can achieve communication compatibility between different versions of the client service and the server service within the same node in the cluster. At the same time, it can also meet the communication data compatibility between different nodes in the cluster when they are in different versions. It effectively guarantees the reliability of the production service during the online upgrade of the cluster, and at the same time greatly reduces the risk of failure in the online upgrade of the distributed cluster.

[0064] Specifically, when the distributed cluster needs to be upgraded online, it will involve the transformation of the data structures for communication between the client service and the server service inside the node and the communication between nodes. Version number information, i.e., the version field, and data update-related information, i.e., the type field, are 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 certain node completes the upgrade and restarts, the version number of this node in the memory of each node is updated in a timely manner. This version number provides a basis for the interaction of data with different versions 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 peer, the version number of the node and what changes have occurred to the data structure are marked in the data, so that the peer node can make a judgment based on the version number. If the version numbers are the same, the data is directly parsed. If the version numbers are different, the received communication data is parsed correspondingly according to the type field carried in the data to obtain the data content required by itself, realizing good compatibility of data communication between different versions. Among them, a version information of each node in the cluster is maintained in the process memory information of each node. During the upgrade process, when a certain node completes the upgrade and restarts the service, the node obtains its own version information according to the version of the RPM package (software data package), and then notifies other nodes in the cluster when restarting and joining the cluster, and each node updates the version information of this node in the cluster. The version information of each node in the cluster recorded by the node is conducive to the encapsulation of communication data information when the node communicates with each node. At the same time, each node recording and maintaining the version information of each node in the cluster is conducive to improving communication efficiency and avoiding affecting performance by reading from the database or other methods every time communication occurs.

[0065] In a possible implementation manner of the embodiment of the present application, the first party is the client service inside the node itself, and the second party is the server service inside the node itself; the first version of the first party is the version of the software data package inside the node, and the second version of the second party is the version of this node in the version list in the memory of this node, and the version list stores the versions of each node in the distributed cluster.

[0066] In the distributed cluster system, the acquisition or setting of certain information can be interacted with the process memory information of the node through the command line form of a single node. During online upgrade, when the RPM package of the node is updated, since the command line is a separate process, the logic executed by the client service when using the command line at this time is the logic of the latest installed RPM package. However, at this time, the cluster service has not been restarted, and the server service still runs with the logic of the old version. See Figure 3 , Figure 3 It is a schematic diagram of the version update process of the client service and the server service during the node upgrade provided by the embodiment of the present application.

[0067] During the process of upgrading a node, there may be inconsistencies in the communication data between the client service and the server service. However, in this case, only the version of the client service will be newer than that of the server service. Therefore, during the online upgrade process, when the command-line client service of the node encapsulates a request, it encapsulates the version number into the request data, and at the same time records that the request data has been added or deleted. Then it encapsulates the normal request data. After receiving the data, if the version numbers of the server service itself and the request information are inconsistent, the server service will parse and process the request data according to the changes, and finally fill its own version number and the processing result into the response information. The client service can then parse the information it needs according to the changes in the new version; in this way, the information communication between the client service and the server service within the same node can be effectively achieved.

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

[0069] Such as Figure 4 In the information interaction process between the client (as the first party) and the server (as the second party) of the node in [FIGURE REFERENCE], when data interaction is performed, first the client obtains the RPM package version number Vi of the current node.

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

[0071] 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 the initial value 0. Then the req data of the request, that is, 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, it directly processes the req information according to its own version logic, and encapsulates the processing result into the rsp information, that is, the response information, and returns it 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 the same as its own, it can directly process it according to its own logic.

[0072] When the client detects that its version = V2 when sending a request, in addition to encapsulating version = V2 in the req data, it also needs to encapsulate the modify information, and encapsulate the default modify of the structure into the req information. After receiving the req information, the server first determines whether the version number of the req is equal to the node version number carried in its own memory. If they are the same, the processing method is the same as described above and will not be elaborated here; if they are not equal (for internal node communication, there is only the case where the version of the client service is higher than the version of the server service), the server first determines the modify information. If modify = 2, it means that a certain field has been added to the information structure carried by the req. Then the server can normally process the data within the data length it needs (ignoring the content of the added field). If modify = 1, it means that a certain field has been deleted from the information structure carried by the req. Then when the server processes the fields it needs, when obtaining the deleted field, it regards it as 0 and does not need to report an error and can ignore further processing of this field; when modify = 3, the server still processes the data within the data length it needs, and when the data of a certain field is 0, it ignores further processing of this field. After waiting for the processing to be completed, encapsulate the rsp information. The version field of the rsp carries the version information in the node memory, and modify = 0, and then return it to the client side; after the client receives the response information rsp of the request req, it compares the version in the rsp with the version information of the node RPM. If they are not equal, the client combines the modify situation in the high-version data structure to process the data in the rsp. For the newly added fields, fill in the initial values and then perform subsequent processing. For the deleted fields, it no longer cares about the content of the fields in the rsp data.

[0073] It can be seen that in the embodiment of the present application, it is possible to interact between the client service and the server service in the node when the versions are inconsistent through changes in the data structure.

[0074] A possible implementation manner of the embodiment of the present application is that the first party is a node in a distributed cluster, and the second party is this node; the data interaction method during online upgrade further includes: if the first version of the first party is less than the second version of the second party, then update the data to be processed in 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.

[0075] Further, update the data to be processed in the data interaction request according to the data update operation and the second version corresponding to the type field in the data structure of the second party, including: processing the data to be processed in the data interaction request according to the data update operation corresponding to the type field in the data structure of the second party to obtain second target data, and processing the second target data according to the second version.

[0076] During the online upgrade of a distributed cluster, data interaction still needs to be carried out between nodes. However, communication data needs to be adapted and compatible during communication between the old and new versions. Different from the interaction between the client and server services within a single node, there are situations where the first party has a newer version than the second party and where the second party has a newer version than the first party node during the interaction between nodes in the cluster. Therefore, version fields can be filled in the data when sending and receiving data, and type fields also need to be filled when the local version is the higher version. After the second party obtains the information of the first party each time, it first parses the version number and parses and processes the received data according to whether the type field is carried. After the processing is completed, it replies to the first party. When encapsulating the reply information, it should also judge whether the type field needs to be carried according to the version number, so as to effectively realize the communication of information between nodes of different versions.

[0077] Regarding the interaction of communication information between cluster nodes, the communication between cluster nodes can also be regarded as the communication between the client node and the server node. During the communication between nodes in the cluster, there is a situation where a node that has not started the upgrade is the client of this communication, and another node that has completed the upgrade is the server of this communication. At this time, the client version number is lower than the server version number. When the client sends a req request message, it obtains the version of the local node in the local memory version list. If the version is the old version, the version is filled into the version field in the req message, and the data with the old version can be submitted to the server node by carrying the old version data. After the server node receives the req message, it parses the carried version information.

[0078] If it is less than the version information of this node, then this node, according to the default modify information in its own data structure, if modify = 2, then normally process the data information of req, and for the newly added fields, only use the default initialization logic for processing; when modify = 1, the server side only parses and processes the information of the non-deleted fields in the corresponding structure of the req data, and does not perform any processing on the already deleted fields; when modify = 3, first parse and process the data information of the non-deleted fields in the req, and for the newly added fields, use the initialization logic for processing. After the server finishes processing, encapsulate the processing result in the latest version data structure, and at the same time fill the version information of the server node with the version information, and fill modify with the modify information in the new version data structure. After filling, send the data to the client. After the Client node receives the reply message from the server node, check the version carried by the rsp and its own version. If its own version is less than the version of the rsp, since the client node does not yet have the processing ability for newly added fields, the client node only needs to parse and process the fields with the length of its own data structure. If modify = 2 or modify = 3, it means that a certain field has been deleted in the data structure of the server side. Then when the data of a certain field is obtained as 0, further processing of this stage can be abandoned.

[0079] It can be seen that in the embodiment of the present application, it is possible to perform interaction between nodes in a distributed cluster during the upgrade process.

[0080] A possible implementation manner of the embodiment of the present application, after parsing the data interaction request to obtain the first version of the first party and the type field of the first party, further includes: reading the version of this node from the version list in the memory of this node as the second version.

[0081] A possible implementation manner of the embodiment of the present application, processing the data to be processed in the data interaction request according to a consistent version, includes: if the consistent version is an upgrade version, then process the data to be processed in the data interaction request based on the upgrade version; if the processing fails, then control this node to automatically roll back to the version before the upgrade, and update the operation corresponding to the type field of the first party and the second version, and process the data to be processed in the data interaction request.

[0082] In the embodiment of the present application, if a failure occurs during the process of processing the data to be processed based on the upgraded version, it may be due to a logical error in the node itself. If the processing still cannot be completed after repeating the 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 in 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, ensuring that the data interaction request can be correctly processed and improving the stability and reliability of the system.

[0083] It can be seen that in the embodiment of the present application, by first attempting to process the data based on the upgraded version and automatically rolling back to the version before the upgrade for data processing if it fails, the stability and reliability of the system are improved.

[0084] A possible implementation manner of the embodiment of the present application further includes: after the node is upgraded and restarted, parsing the version of the software data packet, using the version of the software data packet as the version after the upgrade of the node, and writing the version after the upgrade of the node into the version list in the memory of the node; adding the node to the distributed cluster, and sending the version after the upgrade of the node to each node in the distributed cluster, so that each node updates the version list in its own memory.

[0085] See Figure 5 , Figure 5 FIG. is a schematic flow diagram of updating the version number in the node memory during the online upgrade of the cluster provided by the embodiment of the present application. A version list is maintained in the process memory of each node, and this list records the version information of the services running on each node in the distributed cluster. The version lists maintained in the memories 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 and restart the service, node A first parses the version number of the RPM and records it in its own memory. When node A joins the cluster, A notifies its own version number to node B and node C. Node B and node C update the version number of node A recorded in their own memories, and at the same time, node B and node C synchronize the version number to A, finally achieving the consistency of the list information maintained in the memories of each node.

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

[0087] Further, when all nodes have completed the upgrade and uniformly switched to the new version of communication, the reading of some static data still requires structural transformation, which will also affect the operation of the service to a certain extent in a short period of time. When the data structure in the database needs to be modified during the version upgrade, the present invention proposes to add a new mapped stored data in the database, which is constructed with the data structure in the new version, and design the data conversion rules between the old and new versions. Specifically, a possible implementation manner of the embodiments of the present application further includes: receiving a static data reading request for the database; during the upgrade process of the distributed cluster, 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 this node is a pre-upgrade node, read data from the old version data; if this node is an upgrade node, read data from the new version data.

[0088] Further, receive a static data writing request for the database; write the corresponding data into the old version data and the new version data according to the static data writing request and the upgrade version field. Further, after the upgrade of the distributed cluster is completed, delete the data in the old version data corresponding to the new version data to obtain the updated database.

[0089] During the online upgrade of the cluster, the new version reads and writes new data, and the old version reads and writes old data. When a write operation occurs, the data of the old and new versions is synchronized according to the formulated conversion rules, ensuring the consistency of the data of the old and new versions. After the upgrade is completed, clear the data of the old version and only retain the data of the new version.

[0090] See Figure 6 , Figure 6 FIG. is a schematic flowchart of the compatibility processing of static database data between different versions provided by the embodiments 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, first create a new structure data key-value pair new_key-new_value for the data mapping involved in this upgrade. During the upgrade process, each time the database is read or written, first determine the current version. If it is in the old version, read and write key-value. If it is in the new version, read and write new_key-new_value. The etcd_watcher will monitor the put (write) operation of the key or new_key. If it detects that it is written, it will call the specific compatibility logic to synchronize the values of value and new_value, thus ensuring the consistency of the static data read and written by the 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 the smooth upgrade of the static data.

[0091] Exemplarily, if the structure data corresponds to key-value as node-ip, and the updated new_key-new_value is node-(ip + port number), and if the amount of structure data is 100 and the amount of structure data involved in the cluster upgrade is 50, then 50 new_key-new_value are mapped out, and at this time the data supply is 150; after all upgrades are completed, 50 unchanged data in the key-value and 50 new_key-new_value are retained, totaling 100, to achieve the update of static data.

[0092] It can be seen that in the embodiment of the present application, for the data in the static database, the present invention adopts the method of mapping old and new data. During the upgrade process, the new version reads and writes the data of the new structure, and the old version reads and writes the data of the old data structure. After the upgrade is completed, all are switched to the data of the new data structure, realizing the smooth online upgrade of the cluster, greatly reducing the probability of upgrade failure, and improving the stability of the online upgrade service operation of the distributed cluster.

[0093] A possible implementation manner of the embodiment of the present application. If the first version of the first party is greater than the second version of the second party, then according to the data update operation corresponding to the type field of the first party and the second version, the data to be processed in the data interaction request is processed, including: if the first version of the first party is greater than the second version of the second party, then according to the data update operation corresponding to the type field of the first party and the second version, the data to be processed in the data interaction request is processed; if the processing fails, the data to be processed is written into the waiting queue. After the upgrade of this node is successful, the data to be processed is read from the waiting queue, and the data to be processed is processed according to the upgrade version.

[0094] The waiting queue is a data structure used to temporarily store data that cannot be processed temporarily, and is used to store the data to be processed that fails in this step.

[0095] Optionally, if the processing fails, the second party encapsulates the data to be processed into a specific data structure and writes it into the waiting queue in the memory. At the same time, a timing task is set to regularly check the upgrade status of this node. When it is detected that the upgrade of this node is successful, the timing task sequentially reads the data to be processed from the waiting queue, processes the data to be processed according to the upgrade version, and returns the processing result to the first party.

[0096] Optionally, a message middleware is introduced as a waiting queue. If the processing fails, the second party sends the data to be processed to the message middleware in the form of a message, which contains the detailed information of the data to be processed and the identifier of the first party. During the upgrade process of this node, the progress and status of the upgrade will be recorded. After the upgrade is successful, this node subscribes to the messages related to itself from the message middleware and processes them according to the data to be processed and the identifier of the first party in the message, based on the upgraded version.

[0097] Optionally, a waiting queue table is created in the database. If the processing fails, the second party inserts the relevant information of the data to be processed, such as data content, type field, first party identifier, etc., into the waiting queue table. When this node is upgraded, there will be corresponding upgrade scripts to record the upgrade operations. After the upgrade is successful, this node queries the waiting queue table, obtains the data to be processed, and processes it.

[0098] It can be seen that in the embodiments of this application, by first writing the data to be processed with failed processing into the waiting queue and reprocessing it after the upgrade of this node is successful, the interruption of data processing caused by version problems is avoided, the continuity of the service is guaranteed, the system can transition more smoothly during the version upgrade process, and the integrity and accuracy of data interaction are ensured.

[0099] A possible implementation manner of the embodiments of this application further includes: if this node is not one of the first batch of test upgrade nodes in the distributed cluster, it receives 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 is inconsistent with the second version of the second party.

[0100] In the embodiments of this application, when a version upgrade is required, it is not a random upgrade. Instead, multiple 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 the way of adding fields provided by this application. If the test is successful, the nodes in the cluster are randomly upgraded and a full-scale upgrade is promoted. In the embodiments of this application, some nodes are upgraded in a small range first, and the interaction situation 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 and ensuring that the stability and reliability of the system can improve the communication efficiency.

[0101] Furthermore, during the test process, the interaction situations under multiple service scenarios can be simulated to determine the interaction success rate under each service scenario. For the target service scenario with a low interaction success rate, when the versions are inconsistent, the requests can be written into the pause queue and processed when the versions are consistent.

[0102] A possible implementation of the embodiment of the present application further includes: if this node has not been upgraded and a data interaction request from more than a preset number of upgraded nodes is received within a preset time period, it is determined that the business of this node is relatively large. Therefore, a priority upgrade request is sent to the master node; in response to the upgrade command of the master node, this node executes the upgrade process.

[0103] If this node is not suitable for the data interaction method, that is, the accuracy of data processing is relatively low. At this time, a virtual interaction environment can be created, which can be a virtual machine, a container, or a virtual network, etc. A middleware is deployed in the virtual environment as a bridge for interaction between this node and other nodes. The middleware can simulate the operating environment and functions of the version of this node. Other nodes will send requests to the middleware, and the middleware will convert the requests and then forward them to this node. In this way, version isolation between nodes is achieved, and compatibility problems caused by direct interaction are avoided.

[0104] Based on any of the above embodiments, the present application mainly includes the following steps through the definition of communication data rules, the maintenance of version number information during the upgrade process, the communication and parsing methods for different version data, and the compatibility processing method for static database data: Step 1. Add version number information and data change type information to the data involved in communication. When the cluster is upgraded online, these information are encapsulated in the communication data for the receiving party to perform corresponding parsing and processing. Step 2. Each node in the cluster maintains a version information of all nodes and updates the version information when the node completes the upgrade and restarts. On the one hand, this facilitates this node to quickly identify its own version information when encapsulating or receiving information and compare it with the version information in the communication data, and then select the corresponding processing method. Step 3. When communicating between the client and the server within the node or between different nodes, different processing methods are performed according to the version number and the data structure change type in the communication data. Only the data that can be mutually compatible between high and low versions is processed, and the incompatible data is selected to be ignored, which can achieve effective information communication. Step 4. When upgrading online, both high-version data and low-version data exist in the static data. The two data are mapped, and the two data are synchronized in real time after each write, and finally all are switched to the new version.

[0105] In this application, first, version number information and data change type information are added to the communication data structure involved in the online upgrade process of the cluster. Additionally, a node version list is maintained in the memory information of each node to record in real time the version information of the programs running on each node currently. When data communication occurs within a node or between different nodes, the version number of the information and the data change type information of the new version data are carried. Processes of different versions within the cluster parse and process the communication data according to the version number information and data change type carried in the communication data according to the agreed rules, ultimately achieving smooth compatibility of communication data between different versions within the cluster during the online upgrade process. At the same time, for the compatibility of different versions of data in the static database, the present invention proposes that both old and new version data exist simultaneously during the upgrade process, and they are mapped and associated. Processes of different versions read and write data of their respective versions, and the two copies of data are synchronized in real time, waiting until the upgrade is completed and then uniformly switching to the new version data.

[0106] The following introduces a device provided by an embodiment of the present application. The device described below can be correspondingly referred to the method described above. The device of this embodiment is set in an electronic device. Refer to Figure 7 , Figure 7 which is the structural block diagram of the device of an embodiment of the present application, including: an acquisition module 210, configured to obtain a data interaction request of a first party during the upgrade process of a distributed cluster. 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 upgrade version, the version field is an upgrade version field and the type field is a data update operation of the upgrade version; a parsing module 220, 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 230, configured to process the data to be processed in the data interaction request according to the consistent version if the first version of the first party is the same as the second version of the second party; a second processing module 240, configured to process the data to be processed in 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.

[0107] Among them, the first processing module 230 and the second processing module 240 can be the same module or different modules, which is not limited in the embodiments of the present application.

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

[0109] In a preferred example, the present application can be further configured as follows: The second processing module 240 is used to, if the type field of the first party is the addition type, remove the addition field of the data to be processed in the data interaction request to obtain the first target data, where the addition field is the added field corresponding to the addition type; if the type field of the first party is the deletion type, fill the deletion field of the data to be processed in the data interaction request with zeros to obtain the first target data, where the deletion field is the deleted field corresponding to the deletion type; if the type field of the first party is the deletion and addition type, remove the addition field of the data to be processed in the data interaction request, and then fill the deletion field of the data to be processed in the data interaction request with zeros to obtain the first target data.

[0110] In a preferred example, the present application can be further configured as follows: If the first version of the first party is less than the second version of the second party, the version field and the type field in the data header of the data interaction request are empty or zero.

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

[0112] 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 present node; when the data interaction device is upgraded online, it further includes: a third processing module, which is used to, if the first version of the first party is less than the second version of the second party, process the data to be processed in the data interaction request according to the data update operation corresponding to the type field in the data structure of the second version and the second version.

[0113] In a preferred example, the present application can be further configured as follows: The third processing module is 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 data structure of the second version to obtain the second target data, and process the second target data according to the second version.

[0114] In a preferred example, the present application can be further configured as follows: It further includes: a reading module, which is used to read the version of the present node from the version list in the memory of the present node as the second version.

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

[0116] In a preferred example, the present application can be further configured as follows: further comprising: a synchronization module, which is used for, after the node upgrade is completed and restarted, parsing the version of the software data packet, and taking the version of the software data packet as the version after the node upgrade, and writing the version after the node upgrade into the version list in the memory of the node; adding the node to the distributed cluster, and sending the version after the node upgrade to each node in the distributed cluster, so that each node updates the version list in its own memory.

[0117] In a preferred example, the present application can be further configured as follows: further comprising: a reply module, which is used for encapsulating the processed data according to the second version of the second party and the type field corresponding to the second version to obtain a reply message; and returning the reply message to the first party.

[0118] In a preferred example, the present application can be further configured as follows: further comprising: a static data reading module, which is used for receiving a static data reading request for the database; during the upgrade process of the distributed cluster, 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 node is a pre-upgrade node, reading data from the old version data; if the node is an upgrade node, reading data from the new version data.

[0119] In a preferred example, the present application can be further configured as follows: further comprising: a static data writing module, which is used for receiving a static data writing request for the database; and writing corresponding data into both the old version data and the new version data according to the static data writing request and the upgraded version field.

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

[0121] In a preferred example, the present application can be further configured as follows: 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, update the operation corresponding to the type field of the first party and the second version, and process the data to be processed in the data interaction request; if the processing fails, write the data to be processed into the waiting queue, and after the node is successfully upgraded, read the data to be processed from the waiting queue and process the data to be processed according to the upgraded version.

[0122] In a preferred example, the present application can be further configured as follows: it further includes: a receiving module, which is used to receive the test success information of the first batch of test nodes if the node is not the first batch of test upgrade nodes in the distributed cluster; among them, 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 is inconsistent with the second version of the second party.

[0123] Figure 8 It is a structural diagram of an electronic device provided by an embodiment of the present invention, as Figure 8 shown. The electronic device includes: a memory 60, which is used to store a computer program; a processor 61, which is used to implement the steps of the data interaction method during online upgrade as described in the above embodiment when executing the computer program.

[0124] Among them, the processor 61 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 61 can be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 61 can also include a main processor and a coprocessor. The main processor is a processor used to process data in the wake state, also known as the central processing unit (CPU); the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 61 can be integrated with a graphics processing unit (GPU), and the GPU is used to be responsible for the rendering and drawing of the content to be displayed on the display screen. In some embodiments, the processor 61 can also include an artificial intelligence (AI) processor, and the AI processor is used to process the computing operations related to machine learning.

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

[0126] 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.

[0127] Those skilled in the art can understand that Figure 8 the structure shown in

[0128] does not constitute a limitation on the electronic device, and may include more or fewer components than those shown in the figure.

[0129] 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 data interaction method during online upgrade as described above are implemented.

[0130] Based on this, an embodiment of the present invention further provides a computer program product, including a computer program / instructions. When the computer program / instructions are executed by a processor, the steps of the data interaction method during online upgrade as described above are implemented.

[0131] The above has introduced in detail a data interaction method, device, equipment, medium and product during online upgrade provided by the embodiments of the present invention. The various embodiments in the specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. For the same and similar parts among the various embodiments, reference can be made to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple. For the relevant parts, reference can be made to the description in the method part.

[0132] Those skilled in the art can further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of the two. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of the present invention.

[0133] The above has introduced in detail a data interaction method, device, equipment, medium and product during online upgrade provided by the present invention. Specific examples are used herein to elaborate on the principle and implementation manner of the present invention. The description of the above embodiments is only used to help understand the method and its core idea of the present invention. It should be noted that for those of ordinary skill in the art in the technical field, without departing from the principle of the present invention, several improvements and modifications can be made to the present invention, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A data interaction method during online upgrade, characterized in that, Including: During the upgrade process of a distributed cluster, obtain the data interaction requests of the first party. The data header of the data interaction request adds a version field and a type field. If the first version of the first party is the upgrade version, the version field is the upgrade version field, and the type field is the data update operation of the upgrade version. Parse 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 the same as the second version of the second party, process the data to be processed in the data interaction request according to the same version. If the first version of the first party is greater than the second version of the second party, process the data to be processed in the data interaction request according to the data update operation corresponding to the type field of the first party and the second version.

2. The data interaction method during online upgrade according to claim 1, wherein Processing the data to be processed in the data interaction request according to the data update operation corresponding to the type field of the first party and the second version includes: Process the data to be processed in 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, and process the first target data according to the second version.

3. The data interaction method during online upgrade according to claim 2, wherein Processing the data to be processed in 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 includes: If the type field of the first party is the addition type, remove the addition field of the data to be processed in the data interaction request to obtain the first target data. The addition field is the added field corresponding to the addition type. If the type field of the first party is the deletion type, fill the deletion field of the data to be processed in the data interaction request with zeros to obtain the first target data. The deletion field is the deleted field corresponding to the deletion type. If the type field of the first party is the deletion and addition type, remove the addition field of the data to be processed in the data interaction request, and then fill the deletion field of the data to be processed in the data interaction request with zeros to obtain the first target data.

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

5. The data interaction method during online upgrade according to claim 1, wherein The first party is the client service inside the node, and the second party is the server service inside the node. The first version of the first party is the version of the software data packet inside the node, and the second version of the second party is the version of the node in the version list in the memory of this node. The version list stores the versions of each node in the distributed cluster.

6. 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 this node. The data interaction method during online upgrade further includes: If the first version of the first party is less than the second version of the second party, process the data to be processed in 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.

7. The data interaction method during online upgrade according to claim 6, wherein Processing the data to be processed in 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, including: Processing the data to be processed in 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, obtaining second target data, and processing the second target data according to the second version.

8. The data interaction method during online upgrade according to claim 6, 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, it further includes: Reading the version of this node from the version list in the memory of this node as the second version.

9. The data interaction method during online upgrade according to claim 6, wherein Processing the data to be processed in the data interaction request according to a consistent version, including: If the consistent version is an upgraded version, processing the data to be processed 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 data to be processed in the data interaction request according to the data update operation corresponding to the type field of the first party and the second version.

10. The data interaction method during online upgrade according to claim 5 or 8, characterized in that, It further includes: After this node completes the upgrade and restarts, parsing the version of the software data packet, taking the version of the software data packet as the version after the upgrade of this node, and writing the version after the upgrade of this node into the version list in the memory of this node; Adding this node to the distributed cluster, and sending the version after the upgrade of this node to each node in the distributed cluster, so that each node updates the version list in its own memory.

11. The data interaction method during online upgrade according to any one of claims 1 to 9, characterized in that After processing the data to be processed in the data interaction request, it further 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 a reply message; Returning the reply message to the first party.

12. The data interaction method during online upgrade according to claim 1, wherein It further includes: Receiving a static data reading request for the database; During the upgrade process of the distributed cluster, 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 this node is a node before the upgrade, reading data from the old version data; If this node is an upgraded node, reading data from the new version data.

13. The data interaction method during online upgrade according to claim 12, wherein It further includes: Receiving a static data writing request for the database; Writing corresponding data into the old version data and the new version data according to the static data writing request and the upgraded version field.

14. The data interaction method during online upgrade according to claim 12, wherein It further includes: 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.

15. The data interaction method during online upgrade according to claim 1 or 12, characterized in that, If the first version of the first party is greater than the second version of the second party, processing the data to be processed in 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, process the data to be processed in 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 data to be processed into the waiting queue. After the node is successfully upgraded, read the data to be processed from the waiting queue and process the data to be processed according to the upgraded version.

16. The data interaction method during online upgrade according to claim 1, characterized in that It further includes: If this node is not one of the first batch of test upgrade nodes in the distributed cluster, receive the test success information of the first batch of test nodes; Among them, the first batch of test upgrade nodes are used to verify the ability to process data when the first version of the first party is inconsistent with the second version of the second party.

17. An on-line upgrade data interaction device, characterized in that, It includes: An acquisition module, configured to acquire a data interaction request of a first party during the upgrade process of the distributed cluster. The data header of the data interaction request adds 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; 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, if the first version of the first party is consistent with the second version of the second party, process the data to be processed in the data interaction request according to the consistent version; A second processing module, configured to, if the first version of the first party is greater than the second version of the second party, process the data to be processed in the data interaction request according to the data update operation corresponding to the type field of the first party and the second version.

18. An electronic device, characterized in that, It includes: A memory, configured to store a computer program; A processor, configured to execute the computer program to implement the steps of the data interaction method during online upgrade as described in any one of claims 1 to 16.

19. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, and when the computer program is executed by the processor, the steps of the data interaction method during online upgrade as described in any one of claims 1 to 16 are implemented.

20. A computer program product, comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, the steps of the data interaction method during online upgrade as described in any one of claims 1 to 16 are implemented.

Images