A method, device, medium and product for managing consistency of service data

Abstract

Embodiments of the present application provide a business data consistency management method and device, medium and product, and relate to the technical field of data processing. The method is applied to a distributed system, the distributed system comprising a plurality of nodes, and the method comprises: when a version of business data is changed, retaining the business data of the version before the change in a local cache of the plurality of nodes, and caching the business data of the version after the change; after a distributed transaction is initiated, a first node determines a version number of the business data corresponding to the distributed transaction from the local cache, and after writing the version number into a transaction message, sends the transaction message to a subsequent node; after receiving the transaction message, the subsequent node extracts the version number, and extracts the business data corresponding to the version number from the local cache, to perform business processing. Thus, the method can improve the accuracy of transaction results by performing consistency management on business data.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, device, medium and product for consistency management of business data. Background Technology

[0002] In a distributed financial system, business data is the core foundational data that supports the operation of distributed transactions across multiple nodes. Each node in a distributed financial system frequently reads business data.

[0003] Currently, the management and control of business data mainly adopts the following approach: Each node in the distributed financial system caches a copy of the business data locally. When the business data undergoes a version change, each node responds to the version change notification and synchronously updates the locally cached business data. That is, the business data of the changed version directly overwrites the business data of the previous version.

[0004] However, due to network latency and other factors, the timing of each node completing business data updates varies. When a distributed transaction in transit flows between multiple nodes, it is highly likely that subsequent nodes will read different versions of the business data than the first node, resulting in deviations in the transaction outcome. Summary of the Invention

[0005] To address the aforementioned issues, this application provides a method, device, medium, and product for business data consistency management, which can improve the accuracy of transaction results by managing the consistency of business data.

[0006] The embodiments of this application disclose the following technical solutions: Firstly, this application provides a method for consistency management of business data, applied to a distributed system comprising multiple nodes, the method comprising: When business data undergoes a version change, the local cache of the multiple nodes retains the business data of the previous version and caches the business data of the new version. After a distributed transaction is initiated, the first node determines the version number of the business data corresponding to the distributed transaction from the local cache, and after writing the version number into the transaction message, sends the transaction message to the subsequent nodes. Upon receiving the transaction message, the subsequent node extracts the version number and retrieves the business data corresponding to the version number from the local cache to perform business processing.

[0007] Optionally, the business data of the modified version is generated in the following way: When the node detects a version number change notification for business data, it retrieves the business data change log. Based on the business data change log and the business data of the previous version in the local cache, generate the business data of the changed version.

[0008] Optionally, the method further includes: During the startup phase of any of the nodes, if the business data undergoes a version change, the base version number of the business data at the startup time is obtained. If the local cache of the node does not contain the business data corresponding to the base version number, then the full business data is obtained from the server and stored in the local cache of the node. If the version number of the full set of business data is greater than the baseline version number, then obtain the business data change log between the version number of the full set of business data and the baseline version number; Based on the business data change log, the full amount of business data in the local cache of the node is restored to the business data corresponding to the base version number.

[0009] Optionally, the business data change log includes multiple business data change records, each of which includes a record type, a business data identifier, and the business data of the previous version; The step of restoring the full amount of business data in the local cache of the node to the business data corresponding to the base version number based on the business data change log includes: If the record type of the business data change record is a new record, then the corresponding business data is deleted from the full business data in the local cache of the node according to the business data identifier. If the record type of the business data change record is deletion, then the business data of the previous version will be added again in the full business data in the local cache of the node; If the record type of the business data change record is update type, then in the full business data in the local cache of the node, the business data to be changed is determined according to the business data identifier, and the business data to be changed is restored to the business data of the previous version.

[0010] Optionally, after writing the version number into the transaction message, sending the transaction message to subsequent nodes includes: After the version number is written into the system header of the transaction message, the transaction message is sent to subsequent nodes; the version number in the system header is set to remain unchanged throughout the entire link of the distributed transaction flowing between the multiple nodes.

[0011] Optionally, the method further includes: If the subsequent node fails to retrieve the business data corresponding to the version number from the local cache, an alarm indication will be triggered.

[0012] Optionally, the business data includes one or more of the following: transaction fee rate, business rule parameters, accounting parameters, and control threshold parameters.

[0013] In a second aspect, this application provides an electronic device including a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in the first aspect.

[0014] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0015] Fourthly, this application provides a computer program product, including a computer program or instructions that, when executed by a processor, implement the method described in the first aspect.

[0016] Compared with the prior art, this application has the following beneficial effects: This application provides a method, device, medium, and product for business data consistency management. The method is applied to a distributed system comprising multiple nodes. The method includes: when business data undergoes a version change, retaining the previous version of the business data in the local caches of multiple nodes, and caching the new version of the business data; after a distributed transaction is initiated, the first node determines the version number of the business data corresponding to the distributed transaction from its local cache, writes the version number into the transaction message, and sends the transaction message to subsequent nodes; upon receiving the transaction message, subsequent nodes extract the version number and retrieve the corresponding business data from their local cache to perform business processing. Therefore, this method can improve the accuracy of transaction results by managing the consistency of business data. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a business data consistency management method provided in this application embodiment; Figure 2This is a schematic diagram of a distributed system provided in an embodiment of this application. Detailed Implementation

[0019] As described above, the current management and control of business data mainly adopts the following approach: Each node in the distributed financial system (hereinafter referred to as the "distributed system") caches a copy of the business data locally. When the business data undergoes a version change, each node responds to the version change notification and synchronously updates the locally cached business data. That is, the business data of the changed version directly overwrites the business data of the previous version.

[0020] However, due to network latency and other factors, the timing of each node completing business data updates varies. When a distributed transaction in transit flows between multiple nodes, it is highly likely that subsequent nodes will read different versions of the business data than the first node, resulting in deviations in the transaction outcome.

[0021] The inventors, through research, provide a method, device, medium, and product for business data consistency management. This method is applied to a distributed system comprising multiple nodes. The method includes: when business data undergoes a version change, retaining the previous version of the business data in the local caches of multiple nodes, and caching the new version of the business data; after a distributed transaction is initiated, the first node determines the version number of the business data corresponding to the distributed transaction from its local cache, writes the version number into the transaction message, and sends the transaction message to subsequent nodes; upon receiving the transaction message, subsequent nodes extract the version number and retrieve the corresponding business data from their local cache to perform business processing. Thus, this application establishes a dual-version cache queue across multiple nodes. When a distributed transaction is initiated, the first node persists the version number of the business data used locally at the time of transaction initiation into the transaction message, ensuring its consistency throughout the subsequent end-to-end flow. When processing the transaction, subsequent nodes do not blindly use the currently effective local version, but strictly follow the version number carried in the transaction message to accurately extract the corresponding business data from their local dual-version cache, thereby improving the accuracy of transaction results through consistency management of business data.

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0023] See Figure 1This figure is a flowchart of a business data consistency management method provided in an embodiment of this application. This method is applied to a distributed system. See also... Figure 2 This figure is a schematic diagram of a distributed system provided in an embodiment of this application. Figure 2 As shown, the distributed system includes multiple nodes (node ​​1, node 2... node N). These nodes can communicate over a network to transmit transaction messages and, based on specific business logic, jointly complete the processing flow of a distributed transaction. The method includes: S101: When business data undergoes a version change, the business data of the previous version is retained in the local cache of multiple nodes, and the business data of the changed version is cached.

[0024] Business data includes one or more of the following: transaction fees, business rule parameters, accounting parameters, and control threshold parameters. In a distributed system, business data is the core foundational data supporting the operation of multi-node distributed transactions, and each node in the distributed system frequently reads business data. For example, transaction fees affect the calculation result of each transaction's commission, business rule parameters determine the branching path of the transaction process, accounting parameters affect the accuracy of fund settlement, and control threshold parameters are used to control and intercept transaction risks. Inconsistencies in any of the above business data between different nodes (e.g., node 1 reads the old fee rate, while node 2 reads the updated new fee rate) may cause deviations in the transaction results.

[0025] In this embodiment, each node's local cache contains a dual-version cache queue, which simultaneously stores business data from the previous version (i.e., the old version) and the new version (i.e., the new version). When the business data undergoes a version change, the new version does not directly overwrite the previous version. Instead, both versions are co-located in the local cache, ensuring that both versions are accessible and usable.

[0026] In this embodiment, to meet the performance requirements of low latency and low bandwidth consumption in a distributed system, the generation method of the modified version of the business data is as follows: First, when a node receives a notification of a version number change in the business data, it retrieves the business data change log through a parameter proxy service. This business data change log records all business data change operations from the old version to the new version, including but not limited to which business data was added, which business data was deleted, which business data was modified, and their values ​​before and after the modification. Subsequently, based on the business data change log and the business data of the previous version in the local cache, the modified version of the business data is generated by executing the business data change operations recorded in the business data change log. Therefore, this lightweight generation method reduces the communication overhead of synchronously updating business data between nodes, greatly alleviating the concurrent distribution pressure on the server.

[0027] It should be noted that, as Figure 2 As shown, after a node generates business data V3.0 based on the business data change log, business data V3.0 is not immediately put into use. To ensure that each node has sufficient time to complete the retrieval of the business data change log and the generation of the changed version of business data, this embodiment introduces a delayed version switching mechanism. Specifically, business data V3.0 is marked as "pending activation" for a preset delay period (e.g., 30 seconds). At this time, the business data V2.0, which is in the "currently active" state, is still actually used. Only after the preset delay period will the node perform a rolling version state switch, that is, change the state of business data V3.0 to "currently active" while downgrading the state of business data V2.0 from "currently active" to "historical version" (i.e., the version before the change), and completely delete and clean up the original business data V1.0, which was in the "currently active" state, from the dual-version cache queue to release the node's memory cache space and ensure that the node always maintains a lightweight and efficient operating state with no more than two versions.

[0028] S102: After a distributed transaction is initiated, the first node determines the version number of the business data corresponding to the distributed transaction from its local cache, and after writing the version number into the transaction message, sends the transaction message to subsequent nodes.

[0029] When a distributed transaction is initiated, the request for that transaction first enters a node in the distributed system; this node is the "first node" of the distributed transaction (e.g., ...). Figure 2 Node 1 in the middle).

[0030] Upon receiving a distributed transaction request, the first node first determines the version number of the business data corresponding to the distributed transaction from its locally cached dual-version cache queue. Understandably, considering the delayed switching mechanism in step S101, since the dual-version cache queue may simultaneously contain business data V2.0 in a "currently effective state" and business data V3.0 in a "pending effectiveness state," the first node uses the version number of the business data currently in the "currently effective state" (i.e., V2.0) as the version number of the business data corresponding to the distributed transaction. Subsequently, after writing the version number into the system header of the transaction message, the transaction message is sent to subsequent nodes.

[0031] It should be noted that the version number in the system message header is set to remain absolutely unchanged throughout the entire chain of the distributed transaction flowing between multiple nodes, and no subsequent node downstream of the transaction chain may or can modify this version number.

[0032] After writing the version number into the transaction message, the first node uses the business data corresponding to the version number to complete the business logic of this node, such as calculating the transaction fee rate, validating business rules, and referencing accounting parameters.

[0033] S103: After receiving the transaction message, the subsequent node extracts the version number and retrieves the business data corresponding to the version number from the local cache to perform business processing.

[0034] When a request message for a distributed transaction is passed from the first node to the next node according to the orchestration rules, that next node is the "subsequent node" of the distributed transaction. It is understood that a distributed transaction's chain can include one or more sequential / parallel subsequent nodes.

[0035] Upon receiving a transaction message, subsequent nodes first parse it, extracting the version number from the system header. This version number represents the version baseline of the business data that should be used consistently throughout the entire distributed transaction chain. Then, using this version number as an index, a matching search is performed in the dual-version cache queue locally cached by the subsequent nodes. The business data corresponding to this version number is used to complete the business logic of this node, such as calculating transaction fees, validating business rules, and referencing accounting parameters. Therefore, this application ensures that the processing logic of the same distributed transaction has a consistent parameter basis across different nodes, avoiding accounting deviations or rule validation errors caused by using different versions of business data.

[0036] It should be noted that after retrieving the version number, subsequent nodes can first perform a validity check on the version number, such as verifying whether the version number is a valid positive number. If the validity check passes, the business data corresponding to the version number is retrieved from the local cache to execute the business processing. If the validity check fails, the transaction is directly deemed to have failed and a security alarm is recorded and returned to avoid subsequent processing errors due to invalid version numbers.

[0037] In one specific implementation, if a subsequent node fails to retrieve the business data corresponding to the specified version number from its local cache (e.g., due to occasional local network latency, node crash and restart, or synchronization service anomalies, the subsequent node has not yet completed the retrieval and caching of the specified version data, or the version has been accidentally cleaned up due to being too old), the distributed transaction is deemed to have failed, the current transaction process is terminated, and an alarm is immediately triggered. This alarm is used to notify the relevant stakeholders (e.g., operations personnel or development managers) to perform manual intervention or system repair.

[0038] It should be noted that in actual distributed systems, the startup of business applications and the version change of business data are two relatively independent operations that can occur at any time. When the startup process of business applications and the version change process of business data overlap in time—that is, when the application is loading business data and a version change of business data occurs simultaneously—a mismatch may occur between the business data actually loaded by the node and the startup baseline version recorded by itself. To address this, the embodiments of this application provide the following steps A1 to A4: A1: During the startup phase of any node, if the business data undergoes a version change, obtain the base version number of the business data at the startup time.

[0039] It should be noted that if the business data has not undergone any version changes during the startup phase, the node can directly load the business data without performing subsequent restore operations. If the business data has undergone version changes during the startup phase, the node needs to execute steps A1 to A4 to correct the business data.

[0040] For example, if the business data undergoes a version change at startup time t0 of node 1, node 1 sends a version number query command to the parameter proxy service to obtain the base version number V1.0 of the business data at startup time t0, and records V1.0 as the base version number.

[0041] A2: If the business data corresponding to the base version number does not exist in the node's local cache, then obtain the full business data from the server and store the full business data in the node's local cache.

[0042] For example, if the node's local cache does not contain business data corresponding to the base version number V1.0, then the node retrieves all business data (the business data corresponding to version number V2.0) from the server (e.g., a parameter proxy service) and stores the full business data in the node's local cache. In this case, the node's local cache stores the business data corresponding to version number V2.0, but the base version number is V1.0, resulting in an inconsistency.

[0043] A3: If the version number of all business data is greater than the base version number, then obtain the business data change log between the version number of all business data and the base version number.

[0044] If the version number of all business data is equal to the base version number, it means that no version change of business data occurred during the node startup phase, and no further action is required.

[0045] If the version number of the full set of business data is greater than the base version number (e.g., V2.0 is greater than V1.0), it indicates that a business data version change occurred during the node's startup phase. At this time, the node obtains a business data change log from the server, comparing the version number of the full set of business data with the base version number. The business data change log includes multiple business data change records. Each record includes at least a record type (indicating the type of operation performed on the change, including add, delete, and update types), a business data identifier (uniquely identifying a piece of business data, such as a business data ID), and the business data from the previous version. Additionally, it may include the business data from the current version. See Table 1, which is a schematic table of a business data change log provided in an embodiment of this application.

[0046] Table 1

[0047] It should be noted that this application uses the fact that the version number of the full set of business data is greater than the base version number as the basis for determining that a version change of business data has occurred during the startup phase of a node. In practical applications, other determining criteria can also be set, and this application does not limit this.

[0048] A4: Based on the business data change log, restore all business data in the node's local cache to the business data corresponding to the base version number.

[0049] If the record type of the business data change record is "new", then the corresponding business data will be deleted from the full business data in the local cache of the node according to the business data identifier.

[0050] If the record type of the business data change record is deletion, then the previous version of the business data will be re-added in the full business data in the local cache of the node.

[0051] If the record type of the business data change record is update type, then in the full amount of business data in the local cache of the node, the business data to be changed is determined according to the business data identifier, and the business data to be changed is restored to the business data of the previous version.

[0052] In summary, this application provides a method for business data consistency management. This method is applied to a distributed system comprising multiple nodes. The method includes: when business data undergoes a version change, retaining the business data of the previous version and caching the business data of the changed version in the local caches of multiple nodes; after a distributed transaction is initiated, the first node determines the version number of the business data corresponding to the distributed transaction from its local cache, writes the version number into the transaction message, and sends the transaction message to subsequent nodes; upon receiving the transaction message, subsequent nodes extract the version number and retrieve the business data corresponding to the version number from their local cache to perform business processing. Thus, this application establishes a dual-version cache queue across multiple nodes. When a distributed transaction is initiated, the first node persists the version number of the business data used locally at the time of transaction initiation into the transaction message, ensuring its consistency throughout the subsequent end-to-end flow. When processing the transaction, subsequent nodes do not blindly use the currently effective local version, but strictly follow the version number carried in the transaction message to accurately extract the corresponding business data from their local dual-version cache, thereby improving the accuracy of transaction results through consistency management of business data.

[0053] This application provides an electronic device, which includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the method of the first aspect and has the beneficial effects of the first aspect.

[0054] This application provides a computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the method of the first aspect and has the beneficial effects of the first aspect.

[0055] This application provides a computer program product, characterized in that it includes a computer program or instructions, which, when executed by a processor, implement the method of the first aspect and have the beneficial effects of the first aspect.

[0056] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components indicated as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0057] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A method for consistency control of business data, characterized in that, Applied to a distributed system comprising multiple nodes, the method includes: When business data undergoes a version change, the local cache of the multiple nodes retains the business data of the previous version and caches the business data of the new version. After a distributed transaction is initiated, the first node determines the version number of the business data corresponding to the distributed transaction from the local cache, and after writing the version number into the transaction message, sends the transaction message to the subsequent nodes. Upon receiving the transaction message, the subsequent node extracts the version number and retrieves the business data corresponding to the version number from the local cache to perform business processing.

2. The method according to claim 1, characterized in that, The method for generating the business data in the modified version is as follows: When the node detects a version number change notification for business data, it retrieves the business data change log. Based on the business data change log and the business data of the previous version in the local cache, generate the business data of the changed version.

3. The method according to claim 1, characterized in that, The method further includes: During the startup phase of any of the nodes, if the business data undergoes a version change, the base version number of the business data at the startup time is obtained. If the local cache of the node does not contain the business data corresponding to the base version number, then the full business data is obtained from the server and stored in the local cache of the node. If the version number of the full set of business data is greater than the baseline version number, then obtain the business data change log between the version number of the full set of business data and the baseline version number; Based on the business data change log, the full amount of business data in the local cache of the node is restored to the business data corresponding to the base version number.

4. The method according to claim 3, characterized in that, The business data change log includes multiple business data change records. Each business data change record includes a record type, a business data identifier, and the business data of the previous version. The step of restoring the full amount of business data in the local cache of the node to the business data corresponding to the base version number based on the business data change log includes: If the record type of the business data change record is a new record, then the corresponding business data is deleted from the full business data in the local cache of the node according to the business data identifier. If the record type of the business data change record is deletion, then the business data of the previous version will be added again in the full business data in the local cache of the node; If the record type of the business data change record is update type, then in the full business data in the local cache of the node, the business data to be changed is determined according to the business data identifier, and the business data to be changed is restored to the business data of the previous version.

5. The method according to claim 1, characterized in that, The step of sending the transaction message to subsequent nodes after writing the version number into the transaction message includes: After the version number is written into the system header of the transaction message, the transaction message is sent to subsequent nodes; the version number in the system header is set to remain unchanged throughout the entire link of the distributed transaction flowing between the multiple nodes.

6. The method according to claim 1, characterized in that, The method further includes: If the subsequent node fails to retrieve the business data corresponding to the version number from the local cache, an alarm indication will be triggered.

7. The method according to claim 1, characterized in that, The business data includes one or more of the following: transaction fee rate, business rule parameters, accounting parameters, and control threshold parameters.

8. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method according to any one of claims 1-7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1-7.

10. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, implement the method as described in any one of claims 1 to 7.

Images