Method, device and electronic equipment for arbitrating data change conflicts

Abstract

The application provides a data change conflict arbitration method and device and electronic equipment. The method comprises the following steps: obtaining multiple conflicting data change requests; determining multiple confidence weights based on the multiple data change requests; determining multiple first data change requests from the multiple data change requests in the case where multiple same maximum confidence weights exist; determining a target data change request for changing first data from the multiple first data change requests based on judgment information, wherein the judgment information comprises at least one of reference information in each first data change request and a timestamp of each first data change request, and the reference information comprises multiple version values, each version value being used for identifying the version of the first data in the local data of the requestor of the corresponding first data change request. The arbitration method provided by the application can be used to process the conflict caused by the simultaneous change of the same main data by multiple systems in real time, improve the operation efficiency of the system, and reduce the business errors.

Description

Technical Field

[0001] This application relates to the field of arbitration technology, and in particular to an arbitration method, apparatus and electronic device for resolving data change conflicts. Background Technology

[0002] Enterprise core business operations typically run within a complex information technology (IT) architecture comprised of multiple different systems, such as Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), and Supply Chain Management (SCM). These systems collectively form a multi-master architecture data environment, meaning each system can independently read and write core master data. Master data refers to key data describing core business entities, such as customer information, product information, and supplier information, and can be reused by various systems within the multi-master architecture. However, in a multi-master architecture, the same master data is often distributed across different systems to meet the business needs of different systems. This results in these master data forming independent data silos within each system, meaning that changes to master data in one system are often imperceptible to other systems.

[0003] To address these issues, various methods have been proposed to ensure data synchronization and consistency. For example, centralized Master Data Management (MDM) establishes a central data hub to manage master data, with all systems synchronizing with it. This improves the consistency of master data across different systems, thereby helping to reduce business errors.

[0004] However, none of the above solutions can handle conflicts arising from simultaneous changes to the same master data by multiple systems in real time. Consequently, when data change conflicts occur, it is often necessary to stop the entire system for conflict resolution, which greatly reduces system efficiency and can lead to business errors. Summary of the Invention

[0005] In view of this, this application discloses an arbitration method, apparatus and electronic device for data change conflicts, which can handle conflicts arising from multiple systems simultaneously initiating changes to the same master data, thereby improving system operating efficiency and reducing business errors.

[0006] In a first aspect, embodiments of this application provide an arbitration method for data change conflicts, the arbitration method comprising: Obtain multiple conflicting data change requests, wherein each data change request is used to request a change to first data, and the difference between the timestamps of any two data change requests is less than a first threshold. Multiple confidence weights are determined based on the multiple data change requests, wherein each confidence weight corresponds one-to-one with the multiple data change requests, and each confidence weight is used to identify the degree of authority of the requester of the corresponding data change request as the data source of the first data. In the case where there are multiple identical maximum confidence weights among the multiple confidence weights, multiple first data change requests are determined from the multiple data change requests, and the multiple first data change requests correspond one-to-one with the multiple identical maximum confidence weights; Based on the judgment information, a target data change request for changing the first data is determined from the plurality of first data change requests. The judgment information includes at least one of reference information in each first data change request and a timestamp of each first data change request. The reference information includes multiple version values, each version value being used to identify the version of the first data in the local data of the requester of the corresponding first data change request.

[0007] Therefore, in the embodiments of this application, a two-dimensional arbitration mechanism combining confidence weights and judgment information is introduced to achieve conflict arbitration when multiple systems simultaneously initiate changes to the same master data. Confidence weights give higher priority to changes from authoritative business systems, while judgment information includes at least one of reference information and a timestamp. Reference information contains multiple version values, comprehensively recording the version status of the data locally in each system, while the timestamp reflects the time of data change. This constructs a hierarchical arbitration path, prioritizing arbitration based on confidence weights. When multiple maximum confidence weights exist, the next level of arbitration is initiated based on the judgment information, providing an efficient, automatic, and accurate conflict resolution process. The synergistic effect of these two mechanisms allows the arbitration process to be completed in real-time without interrupting system operation, reducing system hangs or manual intervention caused by the inability to make automatic decisions. While improving the operational efficiency of multi-master architectures, it can also select the most suitable change data for the overall system to take effect, effectively reducing business errors caused by data conflicts and improving processing efficiency in multi-system concurrent scenarios. Meanwhile, since confidence weights essentially represent the authority of different business systems on specific data dimensions, prioritizing changes to systems with high confidence weights can improve the consistency of business statements and the authority of decisions, making the rulings naturally aligned with the company's overall business rules and reducing business risks caused by adopting non-authoritative data.

[0008] In conjunction with the first aspect, in one possible implementation, the determination information is reference information in each first data change request, and the step of determining the target data change request for changing the first data from the plurality of first data change requests based on the determination information includes: Sum the multiple version values ​​in the reference information of each first data change request to obtain the version and value of each first data change request; If a unique maximum version and value exist, the first data change request corresponding to the unique maximum version and value is determined as the target data change request.

[0009] As can be seen, in the embodiments of this application, when multiple maximum confidence weights exist, using the version and value in the reference information as the arbitration basis reduces the impact on system operating efficiency caused by lengthy arbitration processes. Simultaneously, the version and value reflect the overall activity level of data entities in the distributed system, and using this as a ruling standard can quickly identify data versions that change more frequently. More frequently changing data versions mean that the data context on which the change is based is richer and integrates more historical change information, representing a more complete change. Therefore, selecting the first data change request with the largest version and value as the standard for data change reduces the coverage of changes with information lag and allows for the selection of change data that is more complete in terms of information content and closer to the current business state for the overall system.

[0010] In conjunction with the first aspect, in one possible implementation, determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information includes: In the case of multiple identical maximum versions and values, multiple second data change requests are determined, and each of the multiple second data change requests corresponds one-to-one with the multiple identical maximum versions and values; Determine the system priority of each second data change request based on the requester of each second data change request; The second data change request with the highest system priority is determined as the target data change request.

[0011] As can be seen, in the embodiments of this application, when there are multiple maximum versions and values, system priority is introduced as a further adjudication dimension. This allows system administrators to preset the priority levels of each system according to business importance, thereby enabling automatic and accurate adjudication even in extreme conflict scenarios. This makes the arbitration mechanism complete and allows for a deterministic adjudication result without stopping the system in any concurrent conflict scenario. Simultaneously, the system priority is preset by the system administrator based on actual needs, ensuring that the arbitration result aligns with the overall system's actual needs and core business orientation.

[0012] In conjunction with the first aspect, in one possible implementation, determining the target data change request for changing the first data from the plurality of first data change requests further includes: If there are multiple identical highest system priorities among the multiple second data change requests, multiple third data change requests are determined from the multiple second data change requests, and the multiple third data change requests correspond one-to-one with the multiple identical highest system priorities; In response to a user's selection action, the target data change request is determined from the plurality of third data change requests, the selection action indicating the third data change request that the user expects to be the target data change request.

[0013] As can be seen, in the embodiments of this application, when multiple candidate change requests that cannot be automatically distinguished still exist after step-by-step adjudication based on confidence weight, version and value, and system priority, manual arbitration is introduced as a final fallback adjudication mechanism. This ensures that the arbitration process can obtain a deterministic adjudication result under any extreme concurrency scenario, improving the completeness and closed-loop nature of the arbitration mechanism. Simultaneously, manual arbitration is triggered only in the very few cases where multi-level automatic adjudication fails to reach a decision, and will not have a substantial impact on the overall automated operation efficiency of the system, thus balancing the efficiency of automated processing with the accuracy and business rationality of manual decision-making.

[0014] In conjunction with the first aspect, in one possible implementation, the determination information comprises reference information in each first data change request and a timestamp for each first data change request. The step of determining, based on the determination information, a target data change request for changing the first data from the plurality of first data change requests includes: If a unique maximum timestamp exists, the first data change request corresponding to the unique maximum timestamp will be determined as the target data change request; In the case of multiple identical maximum timestamps, at least two first data change requests are identified, and the at least two first data change requests correspond one-to-one with the multiple identical maximum timestamps. Summing multiple version values ​​in the reference information of each of the at least two first data change requests yields the version and value of each first data change request. If a unique maximum version and value exist, the first data change request corresponding to the unique maximum version and value is determined as the target data change request.

[0015] As can be seen, in the embodiments of this application, when the judgment information includes reference information and timestamps, if the confidence weight cannot uniquely determine the target data change request, the timestamp is used as a secondary adjudication basis, taking precedence over the version and value. A larger timestamp indicates a more recent change; prioritizing the change with the largest timestamp as the target data change request reflects the latest business intent while maintaining business authority, ensuring both timeliness and authority in the adjudication result. When timestamps are also the same, multiple data change requests corresponding to the same largest timestamp are used as the first data change request, and then the first data change request is arbitrated based on the version and value. The version and value reflect the overall change activity of the data entity in the distributed system, and using this as the adjudication standard can quickly identify data versions that change more frequently. More frequently changing data versions mean that the change is based on a richer data context and integrates more historical change information, resulting in more comprehensive information. Subsequently, selecting the first data change request with the largest version and value as the standard for data changes can reduce the overwriting of more comprehensive changes due to information lag, while filtering out change data that is more complete in terms of information content for the overall system and is closer to the current business status. Furthermore, it reduces the risk of non-authoritative data overwriting authoritative data due to relying solely on timestamps.

[0016] In conjunction with the first aspect, in one possible implementation, determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information includes: In the case of multiple identical maximum versions and values, multiple second data change requests are determined, and each of the multiple second data change requests corresponds one-to-one with the multiple identical maximum versions and values; Determine the system priority of each second data change request based on the requester of each second data change request; The second data change request with the highest system priority is determined as the target data change request.

[0017] As can be seen, in the embodiments of this application, when there are multiple maximum versions and values, system priority is introduced as a further adjudication dimension. This allows system administrators to preset the priority levels of each system according to business importance, thereby enabling automatic and accurate adjudication even in extreme conflict scenarios. This makes the arbitration mechanism complete and allows for a deterministic adjudication result without stopping the system in any concurrent conflict scenario. Simultaneously, the system priority is preset by the system administrator based on actual needs, ensuring that the arbitration result aligns with the overall system's actual needs and core business orientation.

[0018] In conjunction with the first aspect, in one possible implementation, determining the target data change request for changing the first data from the plurality of first data change requests further includes: If there are multiple identical highest system priorities among the multiple second data change requests, multiple third data change requests are determined from the multiple second data change requests, and the multiple third data change requests correspond one-to-one with the multiple identical highest system priorities; In response to a user's selection action, the target data change request is determined from the plurality of third data change requests, the selection action indicating the third data change request that the user expects to be the target data change request.

[0019] As can be seen, in the embodiments of this application, when multiple candidate change requests that cannot be automatically distinguished still exist after step-by-step adjudication based on confidence weight, version and value, and system priority, manual arbitration is introduced as a final fallback adjudication mechanism. This ensures that the arbitration process can obtain a deterministic adjudication result under any extreme concurrency scenario, improving the completeness and closed-loop nature of the arbitration mechanism. Simultaneously, manual arbitration is triggered only in the very few cases where multi-level automatic adjudication fails to reach a decision, and will not have a substantial impact on the overall automated operation efficiency of the system, thus balancing the efficiency of automated processing with the accuracy and business rationality of manual decision-making.

[0020] In conjunction with the first aspect, in one possible implementation, after determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information, the arbitration method further includes: The reference information in the target data change request, the field name of the first data to be changed in the target data change request, and the field value of the first data are encapsulated into an incremental data packet; The incremental data packet is sent to the system portfolio to synchronize the changes to the first data. The system portfolio includes all systems in the multiple systems related to the first data except for the system corresponding to the requester of the target data change request.

[0021] As can be seen, in the embodiments of this application, efficient and reliable data synchronization is achieved by encapsulating the changed data resulting from arbitration and the updated reference information into incremental packets for distribution. Synchronizing only the changed incremental data, rather than the full data, significantly reduces network transmission load and processing pressure on each system. Simultaneously, the carried reference information provides a data version identifier for the system portfolio, enabling each system in the portfolio to quickly complete synchronization and reducing business errors caused by synchronization delays.

[0022] In conjunction with the first aspect, in one possible implementation, the determination information is the timestamp of each first data change request, and the step of determining the target data change request for changing the first data from the plurality of first data change requests based on the determination information includes: If a unique maximum timestamp exists, the first data change request corresponding to the unique maximum timestamp is determined as the target data change request.

[0023] As can be seen, in the embodiments of this application, when the information is a timestamp, since a larger timestamp indicates a more recent change, the change with the largest timestamp is adopted as the target data change request. Therefore, while maintaining business authority, the latest business intent is reflected, making the ruling both timely and authoritative.

[0024] In conjunction with the first aspect, in one possible implementation, determining multiple confidence weights based on the multiple data change requests includes: Retrieve the field name of the first data field requested to be changed in each data change request; Based on the field name of each data change request and the requester of each data change request, the multiple confidence weights are determined. The higher the correlation between the requester and the field name, the greater the confidence weight.

[0025] As can be seen, in the embodiments of this application, fine-grained control over data authority is achieved by introducing field-level confidence weight configuration. The system can set different confidence weights for different fields, enabling arbitration decisions to be accurate to the field level. Therefore, when multiple systems simultaneously modify different fields of the same master data, conflicts between fields can be processed in parallel, further improving concurrency capabilities and system operating efficiency.

[0026] In conjunction with the first aspect, in one possible implementation, after determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information, the arbitration method further includes: Receive a data read request, the data read request being used to request the reading of second data; Determine whether the second data has been changed within a preset time period, wherein the preset time period is a time period with a preset duration ending at the moment the data read request is received; If the second data has been changed during the preset time period, one or more target information is obtained from one or more systems related to the second data. The one or more systems correspond one-to-one with the one or more target information. Any target information includes multiple target version values. Each target version value is used to identify the version in the local data of the requester of the data change request corresponding to the second data when it has been changed. Based on the one or more target information, the target field value is determined, and at least one target system is identified from the one or more systems; The target field value is sent to the at least one target system, causing the at least one target system to synchronize the target field value.

[0027] As can be seen, in the embodiments of this application, by introducing an active verification mechanism triggered by read operations, the system is endowed with the self-healing capability to detect inconsistencies and actively trigger repairs. When a read request is received, the system can actively verify the data version of the second data in each system related to the second data being read, and trigger fixed-point synchronization when inconsistencies are detected. This ensures that the business always reads the latest and most accurate data, and that the data in the system possesses consistency and accuracy.

[0028] In conjunction with the first aspect, in one possible implementation, determining the target field value based on the one or more target information, and determining at least one target system from the one or more systems, includes: Sum the multiple target version values ​​in each target information to obtain the target version and value for each target information. Among the one or more systems, at least one system in which the target version and value are less than the maximum value is identified as the at least one target system; The field value of the second data corresponding to the maximum value among the target version and value is determined to be the target field value.

[0029] As can be seen, in the embodiments of this application, by comparing the version and value in the target information, the target system with lagging data is accurately identified. This ensures that data in all systems remains up-to-date and synchronized, preventing business errors caused by data inconsistency, and ensuring that the data read by the business is always accurate and reliable.

[0030] In conjunction with the first aspect, in one possible implementation, the reference information is represented in the form of a vector clock.

[0031] As can be seen, in the embodiments of this application, the reference information is explicitly represented in the form of a vector clock. Utilizing the characteristic of vector clocks to completely record the evolution history of data versions in each system provides an accurate global view for version comparison, conflict detection, and consistency verification during the arbitration process. This allows the arbitration results to reflect the most comprehensive data change context, improving the accuracy and reliability of arbitration and synchronization.

[0032] Secondly, embodiments of this application provide an arbitration device for data change conflicts, the arbitration device comprising: The acquisition unit is used to acquire multiple conflicting data change requests, wherein each data change request is used to request a change to first data, and the difference between the timestamps of any two data change requests is less than a first threshold. The determining unit is used to determine multiple confidence weights based on the multiple data change requests, wherein the multiple confidence weights correspond one-to-one with the multiple data change requests, and each confidence weight is used to identify the degree of authority of the requester of the corresponding data change request as the data source of the first data; An arbitration unit is configured to, when multiple identical maximum confidence weights exist among the multiple confidence weights, determine multiple first data change requests from the multiple data change requests, wherein each of the multiple first data change requests corresponds one-to-one with the multiple identical maximum confidence weights; and, based on judgment information, determine a target data change request for changing the first data from the multiple first data change requests, wherein the judgment information includes at least one of reference information in each first data change request and a timestamp of each first data change request, wherein the reference information includes multiple version values, each version value being used to identify the version of the first data in the local data of the requester of the corresponding first data change request.

[0033] Thirdly, embodiments of this application provide an electronic device including a memory and a processor. The memory stores a computer program, the computer program includes program instructions, and the processor is configured to invoke the program instructions to execute the steps in the method designed in the first aspect above.

[0034] Fourthly, embodiments of this application provide a computer-readable storage medium storing computer-readable instructions that, when executed on a computer, cause the computer to perform some or all of the steps described in the method of the first aspect of embodiments of this application.

[0035] Fifthly, embodiments of this application provide a computer program product, wherein the computer program product includes a computer program, which, when executed by a processor, implements some or all of the steps described in the method of the first aspect of embodiments of this application. The computer program product may be a software installation package.

[0036] The beneficial effects of the technical solutions in the second to fifth aspects can be found in the technical effects of the technical solution in the first aspect, and will not be repeated here. Attached Figure Description

[0037] 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 A schematic diagram of an electronic device provided for an embodiment of this application; Figure 2 A flowchart illustrating an arbitration method for data change conflicts provided in this application embodiment; Figure 3 A schematic diagram of an arbitration procedure provided for an embodiment of this application; Figure 4 A flowchart illustrating a data synchronization method provided for an embodiment of this application; Figure 5 A flowchart illustrating another data synchronization method provided for an embodiment of this application; Figure 6 This is a block diagram of the functional units of an arbitration device for data change conflicts provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0039] Explanation of reference numerals in the attached figures: 100 - Electronic devices; 110 - Arbitration software; 120 - Operating system; 130 - Hardware; 140 - Heterogeneous system; 150 - External system; 160 - Server; 131-Central Processing Unit; 132-Memory; 133-External Devices; 600 - Arbitration device; 601 - Acquisition Unit; 602 - Determination Unit; 603 - Arbitration Unit; 700 - Electronic Equipment; 701 - Processor; 702 - Memory. Detailed Implementation

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

[0041] The terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.

[0042] In the embodiments of this application, "at least one item" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. "One or more" refers to one or more items, while "multiple" refers to two or more items. For example, "at least one item" of a, b, or c can represent the following seven cases: a, b, c; a and b; a and c; b and c; a, b, and c. Each of a, b, and c can be an element or a set containing one or more elements.

[0043] In the embodiments of this application, "connection" refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices. The embodiments of this application do not impose any limitations on this. In the description of this application, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "connection" should be interpreted broadly. In one example, it can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection, an electrical connection, or a connection that allows mutual communication; it can be a direct connection or an indirect connection through an intermediate medium; it can be the internal communication of two components or the interaction between two components.

[0044] In this document, the term "implementation" means that a specific feature, structure, or characteristic described in connection with an implementation may be included in at least one implementation of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same implementation, nor is it a separate or alternative implementation mutually exclusive with other implementations. It will be explicitly and implicitly understood by those skilled in the art that the implementations described herein can be combined with other implementations.

[0045] First, it should be noted that the data change conflict arbitration method provided in this application can be applied to a multi-master architecture data environment. This architecture can include multiple heterogeneous systems, each capable of independently reading and writing core master data. Master data refers to key data describing core business entities. For example, in a multi-master architecture for a sales system, heterogeneous systems such as ERP, CRM, and SCM may be included, and master data may include customer information, product information, supplier information, etc. The data change conflict arbitration method provided in this application, by setting confidence weights and reference information, can arbitrate data change conflicts involving changes to the same master data in multiple heterogeneous systems in real time. This improves the operational efficiency of the multi-master architecture while selecting the most suitable change data for the overall system to take effect, effectively reducing business errors caused by data conflicts.

[0046] Specifically, see Figure 1 , Figure 1 This is a schematic diagram of an electronic device provided for an embodiment of this application. An arbitration method for data change conflicts provided in this application can be executed in this electronic device. Specifically, the electronic device 100 includes arbitration software 110, an operating system 120, and hardware 130. The hardware 130 may include a central processing unit (CPU) 131, a memory 132, and external devices 133.

[0047] In this embodiment, the electronic device 100 can be a device with communication functions, and may be referred to as a terminal, user equipment (UE), mobile station (MS), mobile terminal (MT), access terminal equipment, vehicle-mounted terminal equipment, industrial control terminal equipment, UE unit, UE station, mobile station, remote station, remote terminal equipment, mobile device, UE terminal equipment, wireless communication equipment, UE agent, or UE device, etc. The electronic device 100 can be fixed or mobile. It should be noted that the electronic device 100 can support at least one wireless communication technology, such as LTE, new radio (NR), wideband code division multiple access (WCDMA), etc. For example, the host computer can be a mobile phone, tablet, desktop computer, laptop computer, all-in-one computer, vehicle terminal, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, cellular phone, cordless phone, session initiation protocol (SIP) phone, wireless local loop (WLL) station, personal digital assistant (PDA), handheld device with wireless communication capabilities, computing device or other processing device connected to a wireless modem, wearable device, terminal device in future mobile communication networks, or terminal device in future evolved public land mobile network (PLMN), etc. In some embodiments of this application, the electronic device 100 may also be a device with transceiver functions, such as a chip system. The chip system may include chips, and may also include other discrete components.

[0048] In this embodiment, the electronic device 100 can also be a server. For example, it can be a standalone server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms. This application does not make specific limitations in this regard.

[0049] In this embodiment, the memory 132 may be: a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions; a random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions; or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device; or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer. This application does not specifically limit this type of storage.

[0050] In this embodiment, the user can control the electronic device 100 through the operating system 120. Simultaneously, with the support of hardware 130, the electronic device 100 can run arbitration software 110 to arbitrate data change conflicts. During the arbitration process, the electronic device 100 can obtain data change requests from other heterogeneous systems 140 in the architecture, external systems 150, servers 160, etc.

[0051] Understandable, Figure 1 The form and quantity of the arbitration software 110, operating system 120 and hardware 130 in the electronic device 100 shown are for illustrative purposes only and do not constitute a limitation on the implementation of this application.

[0052] For example, electronic device 100 may include other software besides the arbitration software 110 shown.

[0053] For example, the electronic device 100 may include other operating systems besides the operating system 120 shown.

[0054] For example, electronic device 100 may include other hardware besides the hardware 130 shown.

[0055] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the above content and the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application. At the same time, these embodiments can be related to each other or independent of each other, and the same content between different embodiments can be referenced by each other, which will not be elaborated here.

[0056] The following will combine Figure 2 An arbitration method for data change conflicts in one embodiment of this application, Figure 2 A flowchart illustrating an arbitration method for data change conflicts provided in this application, which can be applied to... Figure 1 The electronic device 100 shown specifically includes the following steps: S201: Retrieve conflicting multiple data change requests.

[0057] In this embodiment, conflicting multiple data change requests refer to requests for changes to the same first data, where each request is for a change to the same first data, and the timestamp difference between any two of the multiple data change requests is less than a first threshold. Simply put, it means receiving multiple requests to change the same data within a very short time interval. The first threshold can be determined based on the actual application scenario or requirements, and can be a threshold at the millisecond or microsecond level.

[0058] Furthermore, in this embodiment, different first thresholds can be set for different first data. For example, for first data 1, the first threshold can be set to 5ms. Then, if three change requests for first data 1 are received, they will be processed as follows: Change request 1, timestamp: 10:30:25.123; Change request 2, timestamp: 10:30:25.122; Change request 3, timestamp: 10:30:25.124.

[0059] As can be seen, the difference in timestamps between change request 1 and change request 2 is 1ms, the difference in timestamps between change request 1 and change request 3 is 1ms, and the difference in timestamps between change request 2 and change request 3 is 2ms. All of these are less than the first threshold of 5ms corresponding to the first data 1. Therefore, change request 1, change request 2, and change request 3 are conflicting data change requests.

[0060] For the first data 2, the first threshold can be set to 2ms. Then, if three change requests for the first data 2 are received, they will be as follows: Change request 1, timestamp: 10:30:25.123; Change request 2, timestamp: 10:30:25.122; Change request 3, timestamp: 10:30:25.126.

[0061] It can be seen that the difference in timestamps between change request 1 and change request 2 is 1ms, the difference in timestamps between change request 1 and change request 3 is 3ms, and the difference in timestamps between change request 2 and change request 3 is 4ms. Only the difference in timestamps between change request 1 and change request 2 is less than the first threshold of 2ms for the first data 2. Even if they are all less than the first threshold of 5ms corresponding to the first data 1, for the first data 2, only change request 1 and change request 2 are considered to be conflicting data change requests.

[0062] Therefore, for different types of data, it is possible to determine what level of time difference can constitute a conflict, thus achieving more flexible conflict determination and control. This application does not impose any restrictions on this.

[0063] S202: Determine multiple confidence weights based on multiple data change requests.

[0064] In this implementation, each confidence weight corresponds one-to-one with a data change request, and each confidence weight is used to identify the authority of the requester of the corresponding data change request as the data source of the first data. Specifically, the authority level refers to a preset quantitative indicator used to measure the credibility or priority of different business systems when using specific data as a data source, reflecting the business authority of the business system on a specific data dimension. The higher the authority level, the more worthy the system's change results on that data are to be adopted. For example, the financial system has a higher authority level for "credit limit" than the sales system because credit limit falls under the scope of financial control; the customer relationship management system has a higher authority level for "contact number" than the supply chain system because customer contact information is more accurately maintained by front-line business personnel.

[0065] Therefore, in this embodiment, the field name of the first data requested for modification in each data change request can be obtained. Then, based on the field name of each data change request and the requester of each data change request, multiple confidence weights can be determined. Generally, the higher the correlation between the requester and the field name, the greater the confidence weight. For example, confidence weights for the data field names under different systems can be pre-set, forming a confidence weight lookup table as shown in Table 1. Table 1:

[0066] Then, the confidence weight of each data change request can be determined by querying Table 1 using the field names of each data change request and the requesting party (system) of each data change request. For example, if the field name of the first data to be changed in a data change request is "credit limit" and the requesting party of the data change request is the CRM system, then the confidence weight of the data change request is 30.

[0067] S203: In the case where there are multiple identical maximum confidence weights among multiple confidence weights, determine multiple first data change requests from multiple data change requests.

[0068] In this implementation, since the confidence weight essentially represents the authority of different business systems on a specific data dimension, if there is a unique maximum confidence weight, it means that among the multiple data change requests in this conflict, there is a change that is more authoritative than the others. Therefore, the data change request corresponding to the maximum confidence weight can be directly identified as the target data change request.

[0069] For example, the two conflicting change requests are shown in Table 2: Table 2:

[0070] Since change request A has the highest and unique confidence weight, it can be directly determined that change request A is the target data change request.

[0071] In this implementation, if multiple identical maximum confidence weights exist, it indicates the existence of multiple authoritative and equivalent changes. Arbitration cannot be performed solely based on the confidence weight dimension, requiring arbitration in the next dimension. These multiple data change requests corresponding to the same maximum confidence weights have higher authority than the remaining data change requests and are more likely to be the final target data change requests. Therefore, in the next arbitration dimension, multiple first data change requests corresponding to the same maximum confidence weights can be used for arbitration, reducing the number of arbitration objects and improving arbitration efficiency.

[0072] S204: Based on the judgment information, determine the target data change request for changing the first data from multiple first data change requests.

[0073] In this embodiment, each first data change request may include changed data, a source identifier, a timestamp, and reference information. The changed data consists of the field names and changed values ​​of the changed first data, used to identify the changed content. The source identifier is the identifier of the requester of the change request, used to determine the source of the change request, or the data source. The timestamp is the time the change request was initiated, with precision at the millisecond or microsecond level. The reference information can be represented in the form of a vector clock, including multiple version values. Each version value identifies the version of the first data in the local data of the requester of the corresponding data change request, used to determine data freshness and causality.

[0074] In this embodiment, the determination information may include at least one of the reference information and the timestamp in each first data change request.

[0075] The following will use "vector clock" to refer to reference information, and will describe in detail one type of reference information provided in this application. In each embodiment, "vector clock" can be replaced with "reference information" for understanding.

[0076] Specifically, a vector clock can be configured for each piece of data. This vector clock includes multiple version values, each corresponding to a system associated with that data. Here, "associated with data" means that the system has the ability to read and write the data. For example, ERP, CRM, and SCM can all read and write the data "credit limit." Therefore, the data "credit limit" is associated with these three systems, and the vector clock for the data "credit limit" includes three version values ​​corresponding to these three systems respectively.

[0077] In this implementation, during the initial runtime of the framework, the version value in the vector clock of each data item is 1. Taking the data "Credit Limit" as an example, its vector clock is initially {CRM:1, ERP:1, SCM:1}. During subsequent framework operation, if the data is changed—for example, if the CRM system modifies the field and submits a change request—the vector clock for that field will change to {CRM:2, ERP:1, SCM:1} in the change request, indicating that the CRM has modified it. Similarly, if the ERP system modifies the field and submits a change request, the vector clock for that field will change to {CRM:1, ERP:2, SCM:1} in the change request, indicating that the ERP has modified it.

[0078] In this implementation, after a successful modification, the electronic device synchronizes the vector clock from the successful change request to each system, enabling them to synchronize the vector clock and thus the version change status of the data. For example, taking the data "credit limit" as an example, change requests for this field are received simultaneously from the CRM system and the ERP system. If, after arbitration, the ERP system's change request wins, its vector clock in the change request is changed to {CRM:1, ERP:2, SCM:1} and synchronized to the remaining CRM and SCM systems, indicating that the ERP system has successfully modified the data.

[0079] It's important to note that during a change request, only the vector clock within the request itself is modified. The vector clocks in each system remain unchanged. The vector clocks in each system are only modified during data synchronization after arbitration is complete, based on the vector clocks being synchronized. Specifically, taking the data "Credit Limit" as an example, when the CRM and ERP systems submit change requests for this field, the vector clocks for this field in the CRM, SCM, and ERP systems remain {CRM:1, ERP:1, SCM:1}. Only in the CRM system's change request are the included vector clocks modified to {CRM:2, ERP:1, SCM:1}, and in the ERP system's change request, the included vector clocks are modified to {CRM:1, ERP:2, SCM:1}. Meanwhile, after the change request in the ERP system is approved, the vector clock {CRM:1, ERP:2, SCM:1} in it will be synchronized to all systems related to this field. Only then will the vector clock of this field in the CRM system, SCM system, and ERP system be modified to {CRM:1, ERP:2, SCM:1}.

[0080] Here is an example of two conflicting change requests: Change Request A: { "request_id": "REQ_20240510_006_A", "timestamp": "2024-05-10 10:34:00.123", "source": {"system": "CRM"}, "entity": {"entity_type": "CUSTOMER", "entity_id": "CUST_10001"}, "operation": { "type": "UPDATE", "change_mode":"COMPLEX", "requires_approval": true, "approval_workflow": "FINANCE_APPROVAL" }, "vector_clock": {"CRM": 5, "ERP": 3, "SCM": 2}, "changes": [ { "field": "remark", "new_value": "VIP customer, requires special treatment" } ] } Change Request B: { "request_id": "REQ_20240510_006_B", "timestamp": "2024-05-10 10:34:00.124", / / Almost simultaneously "source": {"system": "ERP"}, "entity": {"entity_type": "CUSTOMER", "entity_id": "CUST_10001"}, / / Same data "operation": { "type": "UPDATE", "change_mode":"COMPLEX", "requires_approval": true, "approval_workflow": "FINANCE_APPROVAL" }, "vector_clock": {"CRM": 4, "ERP": 4, "SCM": 2}, "changes": [ { "field": "remark", "new_value": "High-value customers receive bonus points." } ] } The descriptions of each field are shown in Table 3: Table 3:

[0081] Having clarified the various elements of the change request, the following will provide a detailed explanation of the arbitration method for determining the target data change request based on the judgment information: In this embodiment, refer to Figure 3 , Figure 3 A schematic diagram of an arbitration procedure provided for an embodiment of this application specifically includes: S301: Compare the timestamps of each first data change request to determine if a unique maximum timestamp exists. If it does, determine the first data change request corresponding to the unique maximum timestamp as the target data change request; otherwise, proceed to step S302.

[0082] In this implementation, if arbitration cannot be completed at the confidence weight level, a second-level arbitration is conducted using the timestamp included in the data change request. Specifically, as a time-domain parameter, a larger (newer) timestamp reflects a more recent business intent. Therefore, using the timestamp as the basis for second-level arbitration allows for prioritizing the most recently occurring business operation while maintaining business authority. This ensures that the arbitration result meets timeliness requirements without the risk of non-authoritative data overwriting authoritative data due to reliance solely on timestamps.

[0083] For example, the two conflicting change requests are shown in Table 4: Table 4:

[0084] Since change request A and change request B have equal confidence weights, they are further determined using timestamps. Specifically, the timestamp of change request B is greater than the timestamp of change request A, thus change request B is determined to be the target data change request.

[0085] S302: Identify at least two first data change requests.

[0086] In this embodiment, the at least two first data change requests correspond one-to-one with a plurality of identical maximum timestamps.

[0087] Of course, it should be noted that the execution of steps S301-S302 is based on the premise that the judgment information contains a timestamp. If the judgment information does not contain a timestamp, steps S301-S302 can be skipped directly, and step S303 can be executed to carry out the arbitration process under the version and value dimensions calculated by the vector clock.

[0088] S303: Sum the multiple version values ​​in the vector clock of each first data change request to obtain the version and value of each first data change request.

[0089] In this embodiment, as described in step S203, the vector clock includes multiple version values. For example, if the vector clock included in data change request 1 can be {CRM:5, ERP:4, SCM:2}, then the version and value of data change request 1 can be 5+4+2, i.e., 11.

[0090] S304: Compare the version and value of each first data change request to determine if there is a unique maximum version and value. If so, determine the first data change request corresponding to the unique maximum version and value as the target data change request; otherwise, proceed to step S305.

[0091] In this implementation, if arbitration cannot be completed in either the confidence weight dimension or the timestamp dimension, a third-level arbitration can be performed using the version sum calculated by the vector clock. Specifically, the size of the version sum reflects the overall activity level of data entities in the distributed system, and using this as a arbitration criterion can quickly identify data versions that change more frequently. More frequently changing data versions mean that the change is based on a richer data context and integrates more historical change information, making it a more comprehensive change. Therefore, selecting the first data change request with the largest version sum as the standard for data change can reduce the possibility of delayed changes overshadowing more comprehensive changes, while simultaneously filtering out change data that is more complete in terms of information content and closer to the current business state for the overall system.

[0092] For example, the two conflicting change requests are shown in Table 5: Table 5:

[0093] Since change request A and change request B have equal confidence weights and timestamps, the version sum is calculated using a vector clock to determine which is the target data change request. Change request A has a version sum of 11, and change request B has a version sum of 10. Since change request A's version sum is greater than change request B's version sum, change request A is therefore determined to be the target data change request.

[0094] S305: Identify multiple second data change requests from multiple first data change requests.

[0095] In this embodiment, the plurality of second data change requests correspond one-to-one with a plurality of identical maximum versions and values.

[0096] S306: Determine the system priority of each second data change request based on the requester of each second data change request.

[0097] In this approach, system priority can be preset by the system administrator based on the importance of the business.

[0098] S307: Compare the system priorities of each second data change request to determine if there is a unique highest system priority. If so, determine the second data change request corresponding to the unique highest system priority as the target data change request; otherwise, proceed to step S308.

[0099] In this implementation, if arbitration cannot be completed in the confidence weight dimension, timestamp dimension, and vector clock dimension, a fourth level of arbitration can be performed through system priority. Specifically, the system priority is set in advance by the system administrator based on actual needs, so that the arbitration result can match the actual needs and core business orientation of the overall system.

[0100] For example, the two conflicting change requests are shown in Table 6: Table 6:

[0101] Since change request A and change request B have the same confidence weight, timestamp, version, and value, the system priority of the requester will be used to determine the priority.

[0102] Specifically, the system priority can be shown in Table 7: Table 7:

[0103] Based on this, the requester of change request A is CRM, with a preset system priority of 2, while the requester of change request B is SCM, with a preset system priority of 4. Since a lower system priority value corresponds to a higher priority in the system, change request A is determined to be the target data change request.

[0104] S308: Identify multiple third data change requests from multiple second data change requests.

[0105] In this embodiment, the multiple third data change requests correspond one-to-one with multiple identical highest system priorities.

[0106] S309: In response to a user's selection action, determine the target data change request from multiple third-party data change requests.

[0107] In this embodiment, the selection operation indicates the third data change request that the user expects to be the target data change request. Simply put, multiple third data change requests are sent to the user for manual arbitration, and the third data change request selected by the user is determined as the target data change request.

[0108] In this embodiment, before entering the arbitration process, the fields and change items of the first data requested to be changed in the change request can be locked at a granular level to better synchronize data and reduce business errors.

[0109] Specifically, the first step is to determine whether the first piece of data is critical by identifying its fields. This determination can be made by system administrators who pre-label each field. For example, the field "credit limit" affects a lot of data in the financial sales system and is critical data for many business operations; therefore, this field can be pre-labeled as critical data. Similarly, the field "gender" does not affect business operations in the financial sales system, and thus, this field can be pre-labeled as non-critical data.

[0110] In this implementation, for non-critical data, row-level optimistic locking can be applied to allow concurrency, and the vector clock can be checked for changes upon completion of arbitration and submission. For critical data, column-family locking needs to be applied, with an intention write lock applied to the corresponding field column family. This blocks other write operations on that column family during the arbitration synchronization phase, but allows reads and write operations on other column families.

[0111] Furthermore, by examining the fields and changes in the first set of data, it's possible to determine whether the change involves multiple column families, such as simultaneous modification of multiple fields. In such cases, a transaction lock, such as a distributed transaction lock, needs to be applied to expand the lock granularity to the entity level, thereby improving atomicity.

[0112] In summary, the method implemented in this application, by introducing a two-dimensional arbitration mechanism combining confidence weights and judgment information, achieves conflict arbitration when multiple systems simultaneously initiate changes to the same master data. Confidence weights grant higher priority to changes from authoritative business systems, while judgment information includes at least one of reference information and a timestamp. The reference information contains multiple version values, comprehensively recording the version status of the data locally in each system, while the timestamp reflects the time of data change. This constructs a hierarchical arbitration path, prioritizing arbitration based on confidence weights. When multiple maximum confidence weights exist, the next level of arbitration is initiated based on the judgment information, providing an efficient, automatic, and accurate conflict resolution process. The synergistic effect of these two mechanisms allows the arbitration process to be completed in real-time without interrupting system operation, reducing system hangs or manual intervention caused by the inability to make automatic decisions. While improving the operational efficiency of multi-master architectures, it also selects the most suitable change data for the overall system to take effect, effectively reducing business errors caused by data conflicts and improving processing efficiency in multi-system concurrent scenarios. Meanwhile, since confidence weights essentially represent the authority of different business systems on specific data dimensions, prioritizing changes to systems with high confidence weights can improve the consistency of business statements and the authority of decisions, making the rulings naturally aligned with the company's overall business rules and reducing business risks caused by adopting non-authoritative data.

[0113] See Figure 4 , Figure 4 A flowchart illustrating a data synchronization method provided in this application embodiment is shown. This method can also be applied to... Figure 1 The electronic device 100 shown specifically includes the following steps: S401: Arbitrate conflicting data change requests to determine the target data change request.

[0114] In this embodiment, the specific implementation of step S401 can refer to the above description of steps S201-S204 and steps S301-S309, and will not be repeated here.

[0115] S402: Encapsulate the reference information in the target data change request, the field name and field value of the first data to be changed in the target data change request into an incremental data packet.

[0116] S403: Send incremental data packets to the system assembly.

[0117] In this embodiment, the system portfolio includes all systems related to the first data except for the system corresponding to the requester of the target data change request. For example, the first data is related to a CRM system, an SCM system, and an ERP system. If the requester of the target data change request is the CRM system, then the remaining SCM and ERP systems are included in this system portfolio. Upon receiving the incremental data packet, the systems in the system portfolio can synchronize the changes to the first data and update the reference information.

[0118] Meanwhile, during the synchronization process, synchronization can be based on business script rules. For example, if a business script rule stipulates that "bank account changes must be manually approved", then when an incremental package related to a bank account change is received, manual approval is triggered. After the manual approval is passed, data synchronization is performed to meet the business rules.

[0119] In addition, if synchronization fails, a manual repair process can be triggered to generate a corresponding repair task and push it to the relevant staff.

[0120] In summary, the method implemented in this application achieves efficient and reliable data synchronization by encapsulating the changed data resulting from arbitration and the updated reference information into incremental packets for distribution. Synchronizing only the changed incremental data, rather than the entire dataset, significantly reduces network transmission load and processing pressure on each system. Simultaneously, the included vector clock provides a data version identifier for downstream systems, enabling rapid synchronization and reducing business errors caused by synchronization delays.

[0121] See Figure 5 , Figure 5 A flowchart illustrating another data synchronization method provided in this application embodiment, which can also be applied to... Figure 1 The electronic device 100 shown specifically includes the following steps: S501: Arbitrate conflicting data change requests to determine the target data change request.

[0122] S502: Encapsulate the reference information in the target data change request, the field name and field value of the first data to be changed in the target data change request into an incremental data packet.

[0123] S503: Send incremental data packets to the system assembly.

[0124] In this embodiment, the specific implementation of steps S501-S503 can refer to the above-described steps S401-S403, and will not be repeated here.

[0125] S504: Receive data read request.

[0126] In this embodiment, the data read request is used to request the reading of second data.

[0127] S505: Determine whether the second data has been changed within the preset time period. If yes, proceed to step S506; otherwise, return the field values ​​of the second data.

[0128] In this embodiment, the time period is a preset duration ending at the time the data read request is received. That is, upon receiving the data read request, it is determined whether the second data has been recently modified. If it has not been modified within the preset time period, the field value of the second data can be directly returned as the read result.

[0129] S506: Obtain one or more target information from one or more systems related to the second data.

[0130] In this embodiment, the one or more target information items correspond one-to-one with one or more systems. Specifically, if the second data has been changed within a preset time period, to prevent the data in the current system from not being synchronized and thus returning an incorrect field value, a target information retrieval request is sent to one or more systems related to the second data to obtain the target information in each system, resulting in one or more target information items. Each target information item includes multiple target version values, each target version value identifying the version in the local data of the requester of the data change request corresponding to the changed second data. Therefore, it is possible to determine whether the second data in the current system is the latest synchronized data based on the one or more target information items.

[0131] S507: Based on one or more target information, determine the target field value and identify at least one target system from one or more systems.

[0132] In this embodiment, multiple target version values ​​in each target information can be summed to obtain the target version sum value for each target information. Then, at least one system among the one or more systems whose target version sum value is less than the maximum value is identified as the target system, and the field value of the second data corresponding to the maximum value in the target version sum value is identified as the target field value.

[0133] Specifically, the target version and its value reflect the age of the second data stored in the system from the perspective of the overall system. If the target version and its value are less than the maximum value, it indicates that the version of the second data in this system lags behind other systems, resulting in data inconsistency. Therefore, this system is identified as the target system for synchronization repair. Conversely, if the target version and its value are at their maximum values, it means that the second data in this system is the latest version with the most complete information among all related systems. Therefore, this value is identified as the target field value and serves as the benchmark for synchronization repair.

[0134] S508: Send the target field value to at least one target system, so that at least one target system can synchronize the target field value.

[0135] In this implementation, the target field value can be returned after synchronization is complete.

[0136] It should be noted that if all target versions and values ​​are equal, it means that the second data is synchronized in all its related systems. In this case, there is no need to perform step S508, and the field value of the second data can be returned directly as the read result.

[0137] In summary, the method implemented in this application, by introducing an active verification mechanism triggered by read operations, endows the system with the self-healing capability to proactively trigger repairs upon detecting inconsistencies. When a read request is received, the system can proactively verify the data versions of each system related to the second data being read, and trigger fixed-point synchronization upon detecting inconsistencies. This ensures that the business always reads the latest and most accurate data, and maintains data consistency and accuracy within the system.

[0138] The foregoing primarily describes the implementation scheme of this application from a methodological perspective. It is understood that, to achieve the above functions, the apparatus may include hardware structures and / or software circuits corresponding to the execution of each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in a hardware or computer software-driven hardware 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 beyond the scope of this application.

[0139] The embodiments of this application can divide the device into functional units according to the above method examples. For example, each function can be divided into a separate functional unit, or two or more functions can be integrated into one processing unit. It should be noted that the unit division in the embodiments of this application is illustrative and is only a logical functional division, while other division methods may be used in actual implementation.

[0140] In this embodiment, refer to Figure 6 , Figure 6 This is a functional unit block diagram of an arbitration device for data change conflicts provided in an embodiment of this application. The arbitration device 600 includes an acquisition unit 601, a determination unit 602, and an arbitration unit 603.

[0141] In this embodiment, the acquisition unit 601, the determination unit 602, and the arbitration unit 603 can be any circuit unit used to receive and process signals, information, etc., or to determine a monitoring mechanism, and there are no specific limitations on this.

[0142] In this embodiment, the arbitration device 600 may further include a storage unit for storing computer program code or instructions executed by the arbitration device 600. The storage unit may be a memory.

[0143] In this embodiment, the arbitration device 600 may be a chip or a chip module.

[0144] In this embodiment, the acquisition unit 601, the determination unit 602, and the arbitration unit 603 can be integrated into the communication unit. The communication unit can be a communication interface, transceiver, transceiver circuit, etc.

[0145] In this embodiment, the acquisition unit 601, the determination unit 602, and the arbitration unit 603 can be integrated into the processing unit.

[0146] It should be noted that the processing unit can be a processor or controller, such as a baseband processor, baseband chip, CPU, general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, transistor logic device, hardware component, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processing unit can also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0147] In this embodiment, the arbitration device 600 is used to perform any of the steps performed by the chip / chip module, etc., as described in the above method embodiment.

[0148] In specific implementation, the acquisition unit 601, the determination unit 602, and the arbitration unit 603 are used to perform any of the steps in the above method implementation, and when performing actions such as sending, other units can be selectively invoked to complete the corresponding operation. A detailed explanation follows.

[0149] The acquisition unit 601 is used to acquire multiple conflicting data change requests, wherein each data change request is used to request a change to the first data, and the difference between the timestamps of any two data change requests among the multiple data change requests is less than a first threshold. The determining unit 602 is used to determine multiple confidence weights based on multiple data change requests, wherein the multiple confidence weights correspond one-to-one with the multiple data change requests, and each confidence weight is used to identify the degree of authority of the requester of the corresponding data change request as the data source of the first data; Arbitration unit 603 is used to determine multiple first data change requests from multiple data change requests when multiple identical maximum confidence weights exist among multiple confidence weights. The multiple first data change requests correspond one-to-one with multiple identical maximum confidence weights. Based on judgment information, it determines the target data change request for changing the first data from the multiple first data change requests. The judgment information includes at least one of the reference information in each first data change request and the timestamp of each first data change request. The reference information includes multiple version values, each version value is used to identify the version of the first data in the local data of the requester of the corresponding first data change request.

[0150] In this embodiment, the determination information is the reference information in each first data change request. Based on this, in determining the target data change request for changing the first data from multiple first data change requests based on the determination information, the arbitration unit 603 is specifically used for: Sum the multiple version values ​​in the reference information of each first data change request to obtain the version and value of each first data change request; If a unique maximum version and value exist, the first data change request corresponding to the unique maximum version and value is determined as the target data change request.

[0151] In this embodiment, in determining the target data change request for changing the first data from multiple first data change requests based on judgment information, the arbitration unit 603 is specifically used for: In the case of multiple identical maximum versions and values, multiple second data change requests are identified, and each of the multiple second data change requests corresponds one-to-one with the multiple identical maximum versions and values. Determine the system priority of each second data change request based on the requester of each second data change request; The second data change request with the highest system priority is identified as the target data change request.

[0152] In this embodiment, in determining the target data change request for changing the first data from multiple first data change requests based on judgment information, the arbitration unit 603 is further configured to: In the case where there are multiple identical highest system priorities among multiple second data change requests, multiple third data change requests are determined from the multiple second data change requests, and the multiple third data change requests correspond one-to-one with the multiple identical highest system priorities; In response to the user's selection action, the target data change request is determined from multiple third data change requests. The selection action indicates the third data change request that the user expects to be the target data change request.

[0153] In this embodiment, the determination information includes the reference information in each first data change request and the timestamp of each first data change request. Based on this, in determining the target data change request for changing the first data from multiple first data change requests based on the determination information, the arbitration unit 603 is further configured to: If a unique maximum timestamp exists, the first data change request corresponding to the unique maximum timestamp will be identified as the target data change request. In the case of multiple identical maximum timestamps, at least two first data change requests are identified, and at least two first data change requests correspond one-to-one with the multiple identical maximum timestamps. Summing multiple version values ​​in the reference information of each of the at least two first data change requests yields the version and value of each first data change request. If a unique maximum version and value exist, the first data change request corresponding to the unique maximum version and value is determined as the target data change request.

[0154] In this embodiment, in determining the target data change request for changing the first data from multiple first data change requests based on judgment information, the arbitration unit 603 is specifically used for: In the case of multiple identical maximum versions and values, multiple second data change requests are identified, and each of the multiple second data change requests corresponds one-to-one with the multiple identical maximum versions and values. Determine the system priority of each second data change request based on the requester of each second data change request; The second data change request with the highest system priority is identified as the target data change request.

[0155] In this embodiment, in determining the target data change request for changing the first data from multiple first data change requests based on judgment information, the arbitration unit 603 is specifically used for: In the case where there are multiple identical highest system priorities among multiple second data change requests, multiple third data change requests are determined from the multiple second data change requests, and the multiple third data change requests correspond one-to-one with the multiple identical highest system priorities; In response to the user's selection action, the target data change request is determined from multiple third data change requests. The selection action indicates the third data change request that the user expects to be the target data change request.

[0156] In this embodiment, the arbitration device 600 may further include a synchronization unit. After determining the target data change request for changing the first data from a plurality of first data change requests based on judgment information, the synchronization unit is specifically used for: The reference information in the target data change request, the field name of the first data to be changed in the target data change request, and the field value of the first data are encapsulated into an incremental data packet; Incremental data packets are sent to the system portfolio to synchronize the changes to the first data. The system portfolio includes all systems related to the first data except for the system corresponding to the requester of the target data change request.

[0157] In this embodiment, the determination information is the timestamp of each first data change request. Based on this, in determining the target data change request for changing the first data from multiple first data change requests based on the determination information, the arbitration unit 603 is specifically used for: If a unique maximum timestamp exists, the first data change request corresponding to the unique maximum timestamp is identified as the target data change request.

[0158] In this embodiment, the determining unit 602, in determining multiple confidence weights based on multiple data change requests, is specifically used for: Retrieve the field name of the first data field requested to be changed in each data change request; Based on the field name of each data change request and the requester of each data change request, multiple confidence weights are determined. The higher the correlation between the requester and the field name, the greater the confidence weight.

[0159] In this embodiment, after determining the target data change request for changing the first data from multiple first data change requests based on the judgment information, the synchronization unit is further configured to: Receive a data read request, which is used to request the reading of second data; Determine whether the second data has been changed within a preset time period, which is a time period with a preset duration ending at the moment the data read request is received; If the second data has been changed within a preset time period, one or more target information will be obtained from one or more systems related to the second data. One or more systems correspond one-to-one with one or more target information. Any target information includes multiple target version values. Each target version value is used to identify the version in the local data of the requester of the data change request corresponding to the second data when it has been changed. Based on one or more target information, determine the target field value, and identify at least one target system from one or more systems; Send the target field value to at least one target system, so that at least one target system can synchronize the target field value.

[0160] In this embodiment, regarding determining target field values ​​based on one or more target information and identifying at least one target system from one or more systems, the synchronization unit is specifically used for: Sum the multiple target version values ​​in each target information to obtain the target version and value for each target information. Identify at least one target system among one or more systems whose target version and value are less than the maximum value; Determine the target field value by identifying the field value of the second data corresponding to the maximum value in the target version and value.

[0161] In this embodiment, the reference information is represented in the form of a vector clock.

[0162] It should be noted that, Figure 6 The specific implementation of each operation in the implementation method can be found in the description of the method implementation method shown above, and will not be repeated here.

[0163] In this embodiment, refer to Figure 7 , Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 7 As shown, the electronic device 700 includes a processor 701 and a memory 702. The processor 701 is coupled to the memory 702. The memory 702 is used to store computer programs or instructions and / or data. The processor 701 is used to execute the computer programs or instructions stored in the memory 702, or to read the data stored in the memory 702.

[0164] Optionally, there may be one or more processors 701.

[0165] Optionally, the memory 702 may be one or more.

[0166] Alternatively, the memory 702 can be integrated with the processor 701, or it can be set separately.

[0167] Optionally, the electronic device 700 may also include a transceiver for receiving and / or transmitting signals. For example, a processor 701 may be used to control the transceiver to receive and / or transmit signals.

[0168] In a specific implementation, the processor 701 in the electronic device 700 executes the computer program or instructions stored in the memory 702 to perform the following operations: Get multiple conflicting data change requests, where each data change request is used to request a change to the first data, and the difference between the timestamps of any two data change requests is less than a first threshold. Multiple confidence weights are determined based on multiple data change requests. Each confidence weight corresponds one-to-one with a data change request, and each confidence weight is used to identify the authority of the requester of the corresponding data change request as the data source of the first data. In the case where there are multiple identical maximum confidence weights among multiple confidence weights, multiple first data change requests are determined from multiple data change requests, and the multiple first data change requests correspond one-to-one with the multiple identical maximum confidence weights; Based on the judgment information, a target data change request for changing the first data is determined from multiple first data change requests. The judgment information includes at least one of the reference information in each first data change request and the timestamp of each first data change request. The reference information includes multiple version values, each version value being used to identify the version of the first data in the local data of the requester of the corresponding first data change request.

[0169] It should be noted that, Figure 7 The specific implementation of each operation in the above-described method implementation can be found in the description of the method implementation, and will not be repeated here.

[0170] Furthermore, embodiments of this application also provide a computer-readable storage medium storing computer instructions, which, when executed on a computer, cause the methods in the various method embodiments of this application to be performed.

[0171] Furthermore, this application also provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program operable to cause a computer to perform some or all of the steps of any of the methods described in the above method embodiments. The computer program product may be a software installation package, and the computer may include an electronic device.

[0172] Furthermore, embodiments of this application also provide a chip, which includes a processor. A memory for storing a computer program is provided independently of the chip, and the processor is used to execute the computer program stored in the memory, so that the methods in the various method embodiments of this application are performed.

[0173] Furthermore, the chip may also include a communication interface. The communication interface may be an input / output interface or an interface circuit, etc. Furthermore, the chip may also include a memory.

[0174] It should be understood that the processor in the embodiments of this application can be an integrated circuit chip with the ability to process signals. In implementation, each step of the above method embodiments can be completed by the integrated logic circuitry in the processor's hardware or by instructions in software form. The processor can be a CPU, or other general-purpose processors, DSPs, ASICs, FPGAs, or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware encoding processor, or by a combination of hardware and software modules in the encoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0175] The memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be ROM, Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), EEPROM, or flash memory. Volatile memory can be RAM, which serves as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), and synchronous link dynamic random access memory (SLDRAM).

[0176] It should be noted that when the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, the memory can be integrated into the processor.

[0177] It should be noted that the memory described in this article is intended to include, but is not limited to, these and any other suitable types of memory.

[0178] It should be noted that, for the sake of simplicity, the various embodiments described above are all presented as a series of actions. Those skilled in the art should understand that this application is not limited by the described order of actions, as some steps in the embodiments of this application can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions, steps, modules, or units involved are not necessarily essential to the embodiments of this application.

[0179] In the above embodiments, the descriptions of each embodiment in this application have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0180] The steps of the methods or algorithms described in this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, portable hard disk, read-only optical disc (CD-ROM), or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a terminal device or management device. Alternatively, the processor and storage medium can exist as discrete components in the terminal device or management device.

[0181] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in the embodiments of this application can be implemented, in whole or in part, by software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs (DVDs)), or semiconductor media (e.g., solid-state disks (SSDs)).

[0182] The modules / units included in the various devices and products described in the above embodiments can be software modules / units, hardware modules / units, or a combination of both. For example, for devices and products applied to or integrated into a chip, all modules / units can be implemented using hardware methods such as circuits, or at least some modules / units can be implemented using software programs that run on a processor integrated within the chip, while the remaining (if any) modules / units can be implemented using hardware methods such as circuits. For devices and products applied to or integrated into a chip module, all modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components of the chip module, or at least some modules / units can be implemented using hardware methods such as circuits. The implementation is achieved through a software program that runs on the processor integrated within the chip module. The remaining modules / units (if any) can be implemented using hardware methods such as circuits. For various devices and products applied to or integrated into terminal equipment, each of their modules / units can be implemented using hardware methods such as circuits. Different modules / units can be located in the same component (e.g., chip, circuit module, etc.) or different components within the terminal equipment. Alternatively, at least some modules / units can be implemented through a software program that runs on the processor integrated within the terminal equipment, while the remaining modules / units (if any) can be implemented using hardware methods such as circuits.

[0183] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the embodiments of this application. It should be understood that the above description is only a specific embodiment of the embodiments of this application and is not intended to limit the protection scope of the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made on the basis of the technical solution of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. An arbitration method for data change conflicts, characterized in that, The arbitration methods include: Obtain multiple conflicting data change requests, wherein each data change request is used to request a change to first data, and the difference between the timestamps of any two data change requests is less than a first threshold. Multiple confidence weights are determined based on the multiple data change requests, wherein each confidence weight corresponds one-to-one with the multiple data change requests, and each confidence weight is used to identify the degree of authority of the requester of the corresponding data change request as the data source of the first data. In the case where there are multiple identical maximum confidence weights among the multiple confidence weights, multiple first data change requests are determined from the multiple data change requests, and the multiple first data change requests correspond one-to-one with the multiple identical maximum confidence weights; Based on the judgment information, a target data change request for changing the first data is determined from the plurality of first data change requests. The judgment information includes at least one of the reference information in each first data change request and the timestamp of each first data change request. The reference information includes multiple version values, each version value being used to identify the version of the first data in the local data of the requester of the corresponding first data change request.

2. The arbitration method according to claim 1, characterized in that, The judgment information is reference information in each first data change request. The step of determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information includes: Sum the multiple version values ​​in the reference information of each first data change request to obtain the version and value of each first data change request; If a unique maximum version and value exist, the first data change request corresponding to the unique maximum version and value is determined as the target data change request.

3. The arbitration method according to claim 2, characterized in that, The step of determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information includes: In the case of multiple identical maximum versions and values, multiple second data change requests are determined, and each of the multiple second data change requests corresponds one-to-one with the multiple identical maximum versions and values; Determine the system priority of each second data change request based on the requester of each second data change request; The second data change request with the highest system priority is determined as the target data change request.

4. The arbitration method according to claim 3, characterized in that, The step of determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information further includes: If there are multiple identical highest system priorities among the multiple second data change requests, multiple third data change requests are determined from the multiple second data change requests, and the multiple third data change requests correspond one-to-one with the multiple identical highest system priorities; In response to a user's selection action, the target data change request is determined from the plurality of third data change requests, the selection action indicating the third data change request that the user expects to be the target data change request.

5. The arbitration method according to claim 1, characterized in that, The judgment information consists of reference information in each first data change request and a timestamp for each first data change request. The step of determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information includes: If a unique maximum timestamp exists, the first data change request corresponding to the unique maximum timestamp will be determined as the target data change request; In the case of multiple identical maximum timestamps, at least two first data change requests are identified, and the at least two first data change requests correspond one-to-one with the multiple identical maximum timestamps. Summing multiple version values ​​in the reference information of each of the at least two first data change requests yields the version and value of each first data change request. If a unique maximum version and value exist, the first data change request corresponding to the unique maximum version and value is determined as the target data change request.

6. The arbitration method according to claim 5, characterized in that, The step of determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information includes: In the case of multiple identical maximum versions and values, multiple second data change requests are determined, and each of the multiple second data change requests corresponds one-to-one with the multiple identical maximum versions and values; Determine the system priority of each second data change request based on the requester of each second data change request; The second data change request with the highest system priority is determined as the target data change request.

7. The arbitration method according to claim 6, characterized in that, The step of determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information further includes: If there are multiple identical highest system priorities among the multiple second data change requests, multiple third data change requests are determined from the multiple second data change requests, and the multiple third data change requests correspond one-to-one with the multiple identical highest system priorities; In response to a user's selection action, the target data change request is determined from the plurality of third data change requests, the selection action indicating the third data change request that the user expects to be the target data change request.

8. The arbitration method according to any one of claims 1-7, characterized in that, After determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information, the arbitration method further includes: The reference information in the target data change request, the field name of the first data to be changed in the target data change request, and the field value of the first data are encapsulated into an incremental data packet; The incremental data packet is sent to the system portfolio to synchronize the changes to the first data. The system portfolio includes all systems in the multiple systems related to the first data except for the system corresponding to the requester of the target data change request.

9. The arbitration method according to claim 1, characterized in that, The determination information is the timestamp of each first data change request. The step of determining the target data change request for changing the first data from the plurality of first data change requests based on the determination information includes: If a unique maximum timestamp exists, the first data change request corresponding to the unique maximum timestamp is determined as the target data change request.

10. The arbitration method according to any one of claims 1-9, characterized in that, The determination of multiple confidence weights based on the multiple data change requests includes: Retrieve the field name of the first data field requested to be changed in each data change request; Based on the field name of each data change request and the requester of each data change request, the multiple confidence weights are determined. The higher the correlation between the requester and the field name, the greater the confidence weight.

11. The arbitration method according to any one of claims 1-10, characterized in that, After determining the target data change request for changing the first data from the plurality of first data change requests based on the judgment information, the arbitration method further includes: Receive a data read request, the data read request being used to request the reading of second data; Determine whether the second data has been changed within a preset time period, wherein the preset time period is a time period with a preset duration ending at the moment the data read request is received; If the second data has been changed during the preset time period, one or more target information is obtained from one or more systems related to the second data. The one or more systems correspond one-to-one with the one or more target information. Any target information includes multiple target version values. Each target version value is used to identify the version in the local data of the requester of the data change request corresponding to the second data when it has been changed. Based on the one or more target information, the target field value is determined, and at least one target system is identified from the one or more systems; The target field value is sent to the at least one target system, causing the at least one target system to synchronize the target field value.

12. The arbitration method according to claim 11, characterized in that, The step of determining target field values ​​based on the one or more target information, and determining at least one target system from among the one or more systems, includes: Sum the multiple target version values ​​in each target information to obtain the target version and value for each target information. Among the one or more systems, at least one system in which the target version and value are less than the maximum value is identified as the at least one target system; The field value of the second data corresponding to the maximum value among the target version and value is determined to be the target field value.

13. The arbitration method according to any one of claims 1-12, characterized in that, The reference information is represented in the form of a vector clock.

14. An electronic device, characterized in that, The device includes a memory and a processor, the memory being used to store a computer program, the computer program including program instructions, and the processor being configured to invoke the program instructions to perform the method as described in any one of claims 1-13.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions that, when executed on a computer, cause the computer to perform the method described in any one of claims 1-13.

16. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-13.

Images