CN116910143A - Method, device, equipment and medium for synchronously auditing data of multiparty MDB (Multi-party MDB) repository - Google Patents

Method, device, equipment and medium for synchronously auditing data of multiparty MDB (Multi-party MDB) repository Download PDF

Info

Publication number
CN116910143A
CN116910143A CN202211396329.5A CN202211396329A CN116910143A CN 116910143 A CN116910143 A CN 116910143A CN 202211396329 A CN202211396329 A CN 202211396329A CN 116910143 A CN116910143 A CN 116910143A
Authority
CN
China
Prior art keywords
mdb
data
blockchain
local
memory bank
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202211396329.5A
Other languages
Chinese (zh)
Inventor
陈彦翔
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Mobile Communications Group Co Ltd
China Mobile Group Henan Co Ltd
Original Assignee
China Mobile Communications Group Co Ltd
China Mobile Group Henan Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Mobile Communications Group Co Ltd, China Mobile Group Henan Co Ltd filed Critical China Mobile Communications Group Co Ltd
Priority to CN202211396329.5A priority Critical patent/CN116910143A/en
Publication of CN116910143A publication Critical patent/CN116910143A/en
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The application provides a method, a device, equipment and a medium for synchronously auditing data of multi-party MDB (media data base) repository. Different ones of the multi-party MDB repositories are each configured with a different blockchain node in the blockchain, each blockchain node being configured with an independent blockchain billing right, respectively. The method comprises the following steps: and after updating the local MDB data, each MDB repository calls a local corresponding block chain node and records the local MDB data into the block chain. After triggering a preset condition, each MDB memory bank invokes a blockchain ledger of a blockchain node corresponding to the local and a blockchain ledger of a blockchain node corresponding to at least one other MDB memory bank to check whether the local MDB data is synchronous with MDB data of the other MDB memory banks. The application realizes the synchronous auditing of the data of the multiparty MDB repository based on the blockchain technology.

Description

Method, device, equipment and medium for synchronously auditing data of multiparty MDB (Multi-party MDB) repository
Technical Field
The application relates to the technical field of blockchains, in particular to a method, a device, equipment and a medium for synchronously auditing data of multi-party MDB (media data base) memory banks.
Background
With the development of communication technology, mobile service systems are also becoming more and more complex. Typically, the business system is provided with subsystems executing different business logics, and some important data (such as user versions as data, bills and assets) are stored in message driver MDB (message driven bean) memory banks of the different subsystems respectively and used independently by the subsystems.
The MDB data for each subsystem is normally kept consistent. However, the service logic executed by each subsystem is different, and the change of the MDB data is often independently initiated, which requires the data synchronization between the MDB memory banks of each subsystem. The data synchronization is not successful every time, and once unexpected failure is found, serious influence is brought to service operation and maintenance.
Therefore, a technical scheme capable of conducting data synchronous auditing aiming at the multiparty MDB memory bank is continued at present.
Disclosure of Invention
The application aims to provide a method, a device, equipment and a medium for synchronously auditing data of multi-party MDB memory banks, which can synchronously audit the data of the multi-party MDB memory banks based on a blockchain technology.
In order to achieve the above object, embodiments of the present application are realized as follows:
in a first aspect, a method for synchronously auditing data of multi-party MDB repositories is provided, wherein different MDB repositories in the multi-party MDB repositories are each configured with different blockchain nodes in a blockchain, and each blockchain node is configured with independent blockchain accounting rights, respectively, the method comprising:
after each MDB repository updates the local MDB data, calling a local corresponding block chain node, and recording the local MDB data into the block chain;
after triggering a preset condition, each MDB memory bank invokes a blockchain ledger of a blockchain node corresponding to the local and a blockchain ledger of a blockchain node corresponding to at least one other MDB memory bank to check whether the local MDB data is synchronous with MDB data of the other MDB memory banks.
In a second aspect, there is provided a data synchronization auditing apparatus of multi-party MDB repositories, different ones of the multi-party MDB repositories each configured with a different blockchain node in a blockchain, each blockchain node configured with an independent blockchain billing right, the apparatus comprising:
the uploading module is used for controlling each MDB repository to update the local MDB data, calling the local corresponding block chain node and recording the local MDB data into the block chain;
and the auditing module is used for controlling each MDB memory bank to call the local corresponding block chain account book of the block chain node and the block chain account book of the block chain node corresponding to at least one other MDB memory bank after triggering the preset condition so as to check whether the local MDB data is synchronous with the MDB data of the other MDB memory banks.
In a third aspect, an embodiment of the present application provides an electronic device, including: a processor; and a memory configured to store computer-executable instructions that, when executed, cause the processor to perform the method of the first aspect.
In a fourth aspect, there is provided a computer readable storage medium for storing computer executable instructions which, when executed by a processor, implement the method of the first aspect.
The scheme of the application introduces a block chain independent of a service system, each MDB memory bank in the service system is respectively provided with different block chain nodes in the block chain, each block chain node is respectively provided with independent block chain accounting rights, when the MDB memory bank updates local MDB data, the corresponding block chain node is called, and the MDB data of the local latest version is recorded in the block chain; based on the MDB data of one version corresponding to each block in the block chain, the trace source of MDB data change is provided according to the time stamp and the version number in the block. When the data synchronization audit is needed, the block chain account corresponding to each MDB memory bank can be called, and whether the data synchronization of each MDB memory bank is realized can be judged through the comparison of the block chain account.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort to a person skilled in the art.
Fig. 1 is a schematic flow chart of a method for synchronously auditing data in a multi-party MDB repository according to an embodiment of the present application.
FIG. 2 is a block diagram of a blockchain node itself.
Fig. 3 is a schematic diagram of an application scenario of a method for data synchronization auditing of a multiparty MDB repository according to an embodiment of the present application.
Fig. 4 is a schematic diagram of another application scenario of a method for data synchronization auditing of a multiparty MDB repository according to an embodiment of the present application.
Fig. 5 is a schematic structural diagram of a data synchronization auditing apparatus of a multiparty MDB repository according to an embodiment of the present application.
Fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present application.
Detailed Description
In order to make the technical solution in the present specification better understood by those skilled in the art, the technical solution in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present specification, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.
As described above, with the development of communication technology, mobile service systems are also becoming more and more complex. Typically, the business system is provided with subsystems executing different business logics, and some important data (such as user versions as data, bills and assets) are stored in message driver MDB (message driven bean) memory banks of the different subsystems respectively and used independently by the subsystems. The MDB data for each subsystem is normally kept consistent. However, the service logic executed by each subsystem is different, and the change of the MDB data is often independently initiated, which requires the data synchronization between the MDB memory banks of each subsystem. The data synchronization is not successful every time, and once unexpected failure is found, serious influence is brought to service operation and maintenance.
In view of this, the present application aims to provide a technical solution that can perform data synchronization auditing for multi-party MDB memory banks.
Specifically, the application introduces a block chain independent of a service system, each MDB memory bank in the service system is respectively configured with different block chain nodes in the block chain, each block chain node is respectively configured with independent block chain accounting rights, and when the MDB memory bank updates local MDB data, the corresponding block chain node is called to record the latest local version of MDB data in the block chain; based on the MDB data of one version corresponding to each block in the block chain, the trace source of MDB data change is provided according to the time stamp and the version number in the block. When the data synchronization audit is needed, the block chain account corresponding to each MDB memory bank can be called, and whether the data synchronization of each MDB memory bank is realized can be judged through the comparison of the block chain account.
In one aspect, an embodiment of the present application provides a method for synchronously auditing data in a multi-party MDB repository, and fig. 1 is a flow chart of the method for synchronously auditing data, which specifically includes the following steps:
s102, after each MDB repository updates the local MDB data, calling a local corresponding block chain node, and recording the local MDB data into the block chain.
In the application, the corresponding block chain link point of each MDB memory bank is configured with independent block chain accounting rights, so that each MDB memory bank can independently store local MDB data through the corresponding block chain node.
For each MDB repository, each time MDB data is updated, a block is generated in the corresponding block chain node for certification.
Fig. 2 is a schematic block diagram. As shown in fig. 2, the structure of one block includes: block head and block body.
The block header contains the hash, version number, timestamp and root of the merck tree of the previous block.
The tile body contains leaf nodes of the merck tree.
The application takes the version number of the block as the version number of the MDB data recorded by the block and takes the timestamp of the block as the update time of the MDB data recorded by the block. That is, each MDB library is sequentially recorded in the blockchain network from block to block according to the constant change of the version, and the update time can be traced back.
The lowest leaf node of the merck tree contains stored MDB data or hash values corresponding to the MDB data; the non-leaf node (including the intermediate node and the root node) is the hash value of the contents of both its child nodes, and the merck tree can be generalized to the case of a multi-way tree where the content of the non-leaf node is the hash value of the contents of all its child nodes. The merck tree layer-by-layer records the hash value, which has some unique properties. That is, any movement of the underlying data is passed to its parent, layer by layer, along the path up to the root, meaning that the value of the root hash actually represents a "digital digest" of all the underlying MDB data.
In addition, in practical applications, uploading local MDB data to the blockchain in order to ensure that each MDB repository does not affect the business process of the business system. Each MDB memory bank in the application calls a local corresponding block chain node, and the thread which records the local MDB data to the block chain and the thread which updates the local MDB data are asynchronous threads.
S104, after triggering a preset condition, each MDB memory bank invokes the block chain ledger of the block chain node corresponding to the local and the block chain ledger of the block chain node corresponding to at least one other MDB memory bank to check whether the local MDB data is synchronous with the MDB data of the other MDB memory banks.
The preset conditions of the present application may be, but are not limited to, migration of local MDB data.
Specifically, the application pre-deploys a target intelligent contract for data synchronization auditing in a blockchain. Each MDB repository may submit a transaction to invoke the target smart contract to the locally corresponding blockchain node to run the target smart contract execution prior to migrating the local MDB data: and calling the blockchain ledgers of the blockchain nodes corresponding to the local and the blockchain ledgers of the blockchain nodes corresponding to the at least one other MDB memory bank to check whether the local MDB data are synchronous with MDB data of the other MDB memory banks.
Checking, namely checking whether the merck tree of the latest block in the block chain ledger corresponding to the local is consistent with the merck tree of the latest block in the block chain ledger corresponding to at least one other MDB memory bank; if the MDB data are consistent, judging that the local MDB data are synchronous with MDB data of other MDB memory banks; if not, determining that the local MDB data is not synchronous with MDB data of other MDB memory banks.
As described above, the value of the root hash of the merck tree represents a "digital digest" of all the MDB data at the bottom, and the present application can determine whether the local MDB data is synchronized with the MDB data of the other MDB repository by only checking whether the root hash of the local merck tree is consistent with the corresponding merck tree root hash of the other MDB memory repository.
Further, each MDB repository may initiate an early warning hint when it is verified that the local MDB data is not synchronized with the MDB data of the other MDB repositories.
The early warning prompt comprises a version number and a time stamp of the latest block of the block chain account book record corresponding to the local part and version numbers and time stamps of the latest block of the block chain account book record corresponding to other MDB memory banks. That is, the version numbers of the data differences and the corresponding MDB data can be accurately positioned through early warning prompt, so that clear support is provided for subsequent processing.
In practical applications, execution logic of the early warning prompt may be written into the target smart contract. When the block chain node runs the target intelligent contract to verify that the local MDB data is not synchronous with MDB data of other MDB memory banks, an early warning prompt can be sent out.
It should be understood that the blockchain ledger corresponding to the MDB repository to be called can be flexibly set according to actual requirements, which is not specifically limited herein. Here, as an exemplary introduction, the present application may partition a multiparty MDB memory bank into one enabled MDB memory bank and at least one non-enabled MDB memory bank. The enabled MDB repository acts as a data synchronization object for the non-enabled MDB repository. For the enabled MDB repository, the blockchain ledgers invoked after triggering the preset condition at least include more than half of blockchain ledgers corresponding to the non-enabled MDB repository. For each non-enabled MDB memory bank, the blockchain ledger called after triggering the preset condition at least comprises the blockchain ledger corresponding to the enabled MDB memory bank.
The method according to the embodiment of the present application is described in detail below in conjunction with an application scenario.
In the application scene, the MDB memory bank of the service system specifically comprises: routing memory bank route_mdb, data bank user_mdb, signaling bank abm_mdb, accounting bank aps_mdb.
The four MDB banks, ROUTE_MDB, USER_MDB, ABM_MDB, and APS_MDB, normally maintain data consistency.
Specifically, the application scene builds a synchronous auditing and early warning system based on the MDB route version of the blockchain, and introduces the blockchain technology into the consistency auditing and synchronous work of the MDB version number business data.
Referring to fig. 3, the present application scenario configures one blockchain node for route_mdb, user_mdb, abm_mdb, and aps_mdb, respectively. The block link points of the route_mdb, the user_mdb, the abm_mdb and the aps_mdb have accounting rights, the updated MAD data is uplink through the block chain interface, and the MAD data of each version is recorded to the block chain distributed shared ledger in a block form.
It should be noted that, original data transmission and synchronization mechanisms of route_mdb, user_mdb, abm_mdb and aps_mdb are unchanged, service change data and service data are still obtained in an original manner, and when the version number is modified, the updated version of MAD data is uplink through an asynchronous flow.
Here, route_mdb is taken as a data synchronization object. Wherein fig. 4 shows:
(1) Comparing the USER_MDB with the version of the ROUTE_MDB to see whether the USER_MDB is consistent with the version of the ROUTE_MDB;
(2) Comparing the ABM_MDB with the version of the route_MDB when the ABM_MDB is issued on the asset to see whether the ABM_MDB is consistent with the version of the route_MDB;
(3) The aps_mdb compares to the route_mdb version to see if it is consistent at the time of billing.
The process of comparing versions of the MDB memory banks is to submit a transaction carrying a target version number of local MDB data to the corresponding block chain nodes, and the block chain link points call target intelligent contracts to call the block chain account books of the local corresponding block chain nodes and the block chain nodes corresponding to other MDB memory banks. If so, the MDB data remains consistent. If the difference is inconsistent, generating early warning information of the difference, and searching node information generating the difference according to the traceability of the blockchain.
It can be seen that the MDB route version synchronous auditing and early warning system based on the block chain in the application scene uses the version of the source data as the consistency auditing of the multi-party version numbers on the broadcast trigger chain when the real-time data is changed or the interface is customized, has the capability of timely finding the multi-party version number difference and can provide better processing problems for maintenance personnel. Account book version inconsistency caused by network, interface man-made or program reasons and other factors. The blockchain technology is introduced into the multi-party version number business data consistency auditing and synchronous work, so that the problem of inconsistent data among multi-party version number business systems can be timely found, timely tracing is realized, early warning is timely generated, timely solving is realized, and the loss caused by account book updating failure is recovered.
On the other hand, the embodiment of the application also provides a data synchronous auditing device of the multiparty MDB repository. Fig. 5 is a schematic structural diagram of a data synchronization auditing apparatus, including:
and the uploading module 510 is configured to control each MDB repository to invoke a locally corresponding blockchain node to record the local MDB data into the blockchain after updating the local MDB data.
And the auditing module 520 is configured to control each MDB repository to invoke the blockchain ledger of the locally corresponding blockchain node and the blockchain ledger of the blockchain node corresponding to at least one other MDB repository after triggering the preset condition, so as to check whether the local MDB data is synchronized with the MDB data of the other MDB repository.
Based on the device of the embodiment of the application, the application introduces a block chain independent of a service system, each MDB memory bank in the service system is respectively configured with different block chain nodes in the block chain, each block chain node is respectively configured with independent block chain accounting rights, when the MDB memory bank updates the local MDB data, the corresponding block chain node is called, and the MDB data of the latest local version is recorded in the block chain; based on the MDB data of one version corresponding to each block in the block chain, the trace source of MDB data change is provided according to the time stamp and the version number in the block. When the data synchronization audit is needed, the block chain account corresponding to each MDB memory bank can be called, and whether the data synchronization of each MDB memory bank is realized can be judged through the comparison of the block chain account.
Optionally, the auditing module 520 specifically is configured to: controlling each MDB memory bank to call the blockchain ledger of the blockchain node corresponding to the local and the blockchain ledger of the blockchain node corresponding to at least one other MDB memory bank after triggering a preset condition so as to check whether the merck tree in the blockchain ledger corresponding to the local is consistent with the merck tree in the blockchain ledger corresponding to the at least one other MDB memory bank; if the MDB data are consistent, judging that the local MDB data are synchronous with MDB data of other MDB memory banks; if not, determining that the local MDB data is not synchronous with MDB data of other MDB memory banks.
Optionally, each MDB repository initiates an early warning prompt when it is verified that the local MDB data is not synchronized with the MDB data of the other MDB repositories, where the early warning prompt includes a version number and a timestamp of a latest block of the local corresponding blockchain ledger record, and a version number and a timestamp of a latest block of the blockchain ledger record corresponding to the other MDB repositories.
Optionally, the multiparty MDB memory bank is divided into an enabled MDB memory bank and at least one non-enabled MDB memory bank, and the enabled MDB memory bank is used as a data synchronization object of the non-enabled MDB memory bank; and each non-enabled MDB memory bank at least comprises a blockchain ledger of a blockchain node corresponding to the enabled MDB memory bank, wherein the blockchain ledger is called after a preset condition is triggered.
Optionally, the preset condition includes: and migrating the local MDB data.
Optionally, each MDB memory bank invokes a locally corresponding blockchain node, and the thread that records the local MDB data to the blockchain and the thread that updates the local MDB data are asynchronous threads.
Optionally, the auditing module 520 specifically is configured to: and controlling each MDB repository to submit a transaction for calling the target intelligent contract to a locally corresponding blockchain node after triggering a preset condition so as to operate the target intelligent contract to execute: and calling the blockchain ledgers of the blockchain nodes corresponding to the local and the blockchain ledgers of the blockchain nodes corresponding to the at least one other MDB memory bank to check whether the local MDB data are synchronous with MDB data of the other MDB memory banks.
It is apparent that the cell antenna adjustment device shown in fig. 5 may be used as an execution subject of the method shown in fig. 1, and thus the steps and corresponding functions of the method shown in fig. 1 may be implemented. Because the principle is the same, the description is not repeated here.
Fig. 6 is a schematic structural diagram of an electronic device according to an embodiment of the present specification. Referring to fig. 6, at the hardware level, the electronic device includes a processor, and optionally an internal bus, a network interface, and a memory. The Memory may include a Memory, such as a Random-Access Memory (RAM), and may further include a non-volatile Memory (non-volatile Memory), such as at least 1 disk Memory. Of course, the electronic device may also include hardware required for other services.
The processor, network interface, and memory may be interconnected by an internal bus, which may be an ISA (Industry Standard Architecture ) bus, a PCI (Peripheral Component Interconnect, peripheral component interconnect standard) bus, or EISA (Extended Industry Standard Architecture ) bus, among others. The buses may be classified as address buses, data buses, control buses, etc. For ease of illustration, only one bi-directional arrow is shown in FIG. 6, but not only one bus or type of bus.
And the memory is used for storing programs. In particular, the program may include program code including computer-operating instructions. The memory may include memory and non-volatile storage and provide instructions and data to the processor.
The processor reads the corresponding computer program from the nonvolatile memory into the memory and then runs to form the apparatus shown in fig. 5 above on a logic level. Correspondingly, the processor executes the program stored in the memory and is specifically configured to perform the following operations:
and after each MDB repository is controlled to update the local MDB data, calling a local corresponding block chain node, and recording the local MDB data into the block chain.
And after triggering a preset condition, controlling each MDB memory bank to call the block chain account book of the block chain node corresponding to the local and the block chain account book of the block chain node corresponding to at least one other MDB memory bank so as to check whether the local MDB data are synchronous with MDB data of the other MDB memory banks.
The data synchronization auditing method disclosed in the embodiment shown in the present specification can be applied to a processor and implemented by the processor. The processor may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware in a processor or by instructions in the form of software. The processor may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU), a network processor (Network Processor, NP), etc.; but also digital signal processors (Digital Signal Processor, DSP), application specific integrated circuits (Application Specific Integrated Circuit, ASIC), field programmable gate arrays (Field-Programmable Gate Array, FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present application may be embodied directly in the execution of a hardware decoding processor, or in the execution of a combination of hardware and software modules in a decoding processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method.
Of course, in addition to the software implementation, the electronic device in this specification does not exclude other implementations, such as a logic device or a combination of software and hardware, that is, the execution subject of the following process is not limited to each logic unit, but may also be hardware or a logic device.
Furthermore, an embodiment of the present application also proposes a computer-readable storage medium storing one or more programs, the one or more programs including instructions.
The above instructions, when executed by a portable electronic device comprising a plurality of applications, enable the portable electronic device to perform the steps of the method shown in fig. 1, comprising:
after each MDB repository is controlled to update the local MDB data, calling a local corresponding block chain node, and recording the local MDB data into the block chain;
and after triggering a preset condition, controlling each MDB memory bank to call the block chain account book of the block chain node corresponding to the local and the block chain account book of the block chain node corresponding to at least one other MDB memory bank so as to check whether the local MDB data are synchronous with MDB data of the other MDB memory banks.
It will be appreciated by those skilled in the art that embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, the present specification may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.
The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
The foregoing is merely an example of the present specification and is not intended to limit the present specification. Various modifications and alterations to this specification will become apparent to those skilled in the art. Any modifications, equivalent substitutions, improvements, or the like, which are within the spirit and principles of the present description, are intended to be included within the scope of the claims of the present description. Moreover, all other embodiments obtained by those skilled in the art without making any inventive effort shall fall within the scope of protection of this document.

Claims (10)

1. A method for synchronously auditing data of multi-party MDB libraries, wherein different ones of the multi-party MDB libraries are each configured with a different blockchain node in a blockchain, each blockchain node being configured with an independent blockchain billing right, the method comprising:
after each MDB repository updates the local MDB data, calling a local corresponding block chain node, and recording the local MDB data into the block chain;
after triggering a preset condition, each MDB memory bank invokes a blockchain ledger of a blockchain node corresponding to the local and a blockchain ledger of a blockchain node corresponding to at least one other MDB memory bank to check whether the local MDB data is synchronous with MDB data of the other MDB memory banks.
2. The method of claim 1, wherein the step of determining the position of the substrate comprises,
after triggering a preset condition, each MDB memory bank invokes a blockchain ledger of a blockchain node corresponding to the local and a blockchain ledger of a blockchain node corresponding to at least one other MDB memory bank to check whether the local MDB data is synchronous with MDB data of the other MDB memory banks, including:
each MDB memory bank, after triggering a preset condition, calls a blockchain ledger of a locally corresponding blockchain node and a blockchain ledger of a blockchain node corresponding to at least one other MDB memory bank to check whether the merck tree in the locally corresponding blockchain ledger is consistent with the merck tree in the blockchain ledger corresponding to at least one other MDB memory bank;
if the MDB data are consistent, judging that the local MDB data are synchronous with MDB data of other MDB memory banks;
if not, determining that the local MDB data is not synchronous with MDB data of other MDB memory banks.
3. The method as recited in claim 1, further comprising:
and each MDB repository initiates an early warning prompt when the local MDB data is verified to be asynchronous with the MDB data of other MDB repositories, wherein the early warning prompt comprises the version number and the time stamp of the latest block of the local corresponding block chain account book record and the version number and the time stamp of the latest block of the block chain account book record corresponding to other MDB repositories.
4. The method of claim 1, wherein the step of determining the position of the substrate comprises,
the multi-party MDB memory bank is divided into an enabling MDB memory bank and at least one non-enabling MDB memory bank, and the enabling MDB memory bank is used as a data synchronization object of the non-enabling MDB memory bank;
and each non-enabled MDB memory bank at least comprises a blockchain ledger of a blockchain node corresponding to the enabled MDB memory bank, wherein the blockchain ledger is called after a preset condition is triggered.
5. The method of claim 1, wherein the step of determining the position of the substrate comprises,
the preset conditions include: and migrating the local MDB data.
6. The method according to any one of claims 1 to 5, wherein,
each MDB memory bank calls a local corresponding block chain node, and the thread which records the local MDB data to the block chain and the thread which updates the local MDB data are asynchronous threads.
7. The method according to any one of claims 1 to 5, wherein,
the blockchain is pre-deployed with a target intelligent contract for data synchronization auditing, after triggering a preset condition, each MDB memory bank invokes a blockchain ledger of a locally corresponding blockchain node and a blockchain ledger of a blockchain node corresponding to at least one other MDB memory bank to check whether local MDB data is synchronous with MDB data of the other MDB memory banks, including:
each MDB repository submits a transaction for calling the target intelligent contract to a locally corresponding blockchain node after triggering a preset condition so as to operate the target intelligent contract to execute: and calling the blockchain ledgers of the blockchain nodes corresponding to the local and the blockchain ledgers of the blockchain nodes corresponding to the at least one other MDB memory bank to check whether the local MDB data are synchronous with MDB data of the other MDB memory banks.
8. A data synchronization auditing apparatus for multi-party MDB repositories, wherein different ones of the multi-party MDB repositories are each configured with a different blockchain node in a blockchain, each blockchain node being configured with an independent blockchain billing right, the apparatus comprising:
the uploading module is used for controlling each MDB repository to update the local MDB data, calling the local corresponding block chain node and recording the local MDB data into the block chain;
and the auditing module is used for controlling each MDB memory bank to call the local corresponding block chain account book of the block chain node and the block chain account book of the block chain node corresponding to at least one other MDB memory bank after triggering the preset condition so as to check whether the local MDB data is synchronous with the MDB data of the other MDB memory banks.
9. An electronic device, the device comprising: a processor; and a memory configured to store computer-executable instructions that, when executed, cause the processor to perform the method of any of claims 1-7.
10. A computer readable storage medium for storing computer executable instructions which, when executed by a processor, implement the method of any one of claims 1-7.
CN202211396329.5A 2022-11-09 2022-11-09 Method, device, equipment and medium for synchronously auditing data of multiparty MDB (Multi-party MDB) repository Pending CN116910143A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202211396329.5A CN116910143A (en) 2022-11-09 2022-11-09 Method, device, equipment and medium for synchronously auditing data of multiparty MDB (Multi-party MDB) repository

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211396329.5A CN116910143A (en) 2022-11-09 2022-11-09 Method, device, equipment and medium for synchronously auditing data of multiparty MDB (Multi-party MDB) repository

Publications (1)

Publication Number Publication Date
CN116910143A true CN116910143A (en) 2023-10-20

Family

ID=88357037

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211396329.5A Pending CN116910143A (en) 2022-11-09 2022-11-09 Method, device, equipment and medium for synchronously auditing data of multiparty MDB (Multi-party MDB) repository

Country Status (1)

Country Link
CN (1) CN116910143A (en)

Similar Documents

Publication Publication Date Title
US10509585B2 (en) Data synchronization method, apparatus, and system
CN109614469A (en) A kind of log analysis method and device
CN110032599B (en) Data structure reading and updating method and device, and electronic equipment
CN110046523B (en) Intelligent contract checking method and device and electronic equipment
CN109032631B (en) Application program patch package obtaining method and device, computer equipment and storage medium
CN109885612B (en) Synchronous validation method and device for intelligent contracts of block chains
CN111984264B (en) Static library generation method and device
CN111639127A (en) Method, system, device and equipment for updating intelligent contract
CN116257438A (en) Updating method of interface test case and related equipment
WO2023184052A1 (en) Data processing method, blockchain node and blockchain system
CN106990974B (en) APP updating method and device and electronic equipment
CN114528201A (en) Abnormal code positioning method, device, equipment and medium
CN109522723A (en) POC scenario generation method, device, electronic equipment and storage medium
CN110852752B (en) Method, device, equipment and storage medium for processing recharge order withdrawal exception
CN108710658B (en) Data record storage method and device
CN116910143A (en) Method, device, equipment and medium for synchronously auditing data of multiparty MDB (Multi-party MDB) repository
CN111464319A (en) Transaction storage and signature verification method based on centralized block chain type account book
CN116599881A (en) Cloud platform tenant modeling test method, device, equipment and storage medium
CN115934040A (en) Demand analysis method and device, electronic equipment and storage medium
CN115757172A (en) Test execution method and device, storage medium and computer equipment
CN115203746A (en) Data account access authorization method and device
CN115203747A (en) Data account creation method and device
CN115018499A (en) Block chain-based digital certificate issuing method, device and system
CN113204533A (en) Log level adjusting method and device, computer equipment and storage medium
CN114675995A (en) Data backup method and device and electronic equipment

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination