Account reconciliation method, device and electronic device

Abstract

The embodiments of this specification disclose a reconciliation method, device and electronic device. The method includes: obtaining first transaction data from a first message queue of a message system, the message system includes multiple first message queues, each first message queue corresponds to a system, including first transaction data collected from a data table of the system, the system is used to process branch transactions in distributed transactions, and the data table is used to store the processing results of branch transactions; determining the transaction scenario corresponding to the first transaction data; screening the first transaction data to obtain second transaction data; writing the second transaction data into a second message queue in the message system that corresponds to both the transaction scenario and the system, so as to reconcile the second transaction data in the second message queue. The embodiments of this specification can realize the reconciliation of branch transaction processing results of different systems.

Description

Technical Field

[0001] The embodiments of the present specification relate to the field of computer technology, and in particular to a reconciliation method, device and electronic device. Background Art

[0002] Distributed transaction systems can process business data more flexibly and efficiently. In view of this, more and more Internet service providers have begun to use distributed transaction systems to provide business services to users. Distributed transaction systems can include multiple systems, each of which is used to process a branch transaction in a distributed transaction.

[0003] In some cases, the branch transaction processing results of each system may be inconsistent. How to reconcile the branch transaction processing results of different systems is a technical problem that needs to be solved urgently. Summary of the invention

[0004] The embodiment of the present specification provides a reconciliation method, device and electronic device to reconcile branch transaction processing results of different systems. The technical solution of the embodiment of the present specification is as follows.

[0005] A first aspect of the embodiments of this specification provides a reconciliation method, including:

[0006] Acquire first transaction data from a first message queue of a message system, the message system comprising a plurality of first message queues, each of which corresponds to a system, including first transaction data collected from a data table of the system, the system being used to process branch transactions in distributed transactions, and the data table being used to store processing results of the branch transactions;

[0007] Determining a transaction scenario according to the first transaction data;

[0008] Determining second transaction data according to the first transaction data;

[0009] The second transaction data is written into a second message queue in the message system that corresponds to both the transaction scenario and the system of the first transaction data, so as to perform reconciliation processing on the second transaction data in the second message queue.

[0010] A second aspect of the embodiments of this specification provides a reconciliation method, including:

[0011] Acquire multiple second transaction data from multiple second message queues of the message system, where the multiple second message queues correspond to the same transaction scenario and respectively correspond to different systems;

[0012] Reconciliation processing is performed on the plurality of second transaction data.

[0013] According to a third aspect of the embodiments of this specification, a reconciliation device is provided, including:

[0014] an acquisition unit, configured to acquire first transaction data from a first message queue of a message system, the message system comprising a plurality of first message queues, each first message queue corresponding to a system, including first transaction data collected from a data table of the system, the system being configured to process a branch transaction in a distributed transaction, the data table being configured to store a processing result of the branch transaction;

[0015] A first determining unit, configured to determine a transaction scenario according to the first transaction data;

[0016] a second determining unit, configured to determine second transaction data according to the first transaction data;

[0017] The writing unit is used to write the second transaction data into a second message queue in the message system that corresponds to both the transaction scenario and the system of the first transaction data, so as to perform reconciliation processing on the second transaction data in the second message queue.

[0018] A fourth aspect of the embodiments of this specification provides a reconciliation device, including:

[0019] An acquisition unit, configured to acquire a plurality of second transaction data from a plurality of second message queues of the message system, wherein the plurality of second message queues correspond to the same transaction scenario and correspond to different systems respectively;

[0020] A reconciliation unit is used to perform reconciliation processing on the plurality of second transaction data.

[0021] According to a fifth aspect of the embodiments of this specification, an electronic device is provided, including:

[0022] at least one processor;

[0023] A memory storing program instructions, wherein the program instructions are configured to be suitable for being executed by the at least one processor, and the program instructions include instructions for executing the method as described in the first aspect or the second aspect.

[0024] The technical solution provided in the embodiments of this specification utilizes the message queue in the message system to achieve reconciliation of branch transaction processing results between different systems without intruding the business code, effectively alleviating the risks that may be caused by inconsistent branch transaction processing results of various systems in high-concurrency business scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. The drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0026] Figure 1 This is a schematic diagram of the structure of a distributed transaction system in an embodiment of this specification;

[0027] Figure 2 This is a schematic diagram of the structure of the reconciliation system in the embodiment of this specification;

[0028] Figure 3 This is a flow chart of the reconciliation method in the embodiment of this specification;

[0029] Figure 4 This is a flow chart of the reconciliation method in the embodiment of this specification;

[0030] Figure 5 This is a schematic diagram of the structure of the account reconciliation device in the embodiment of this specification;

[0031] Figure 6 This is a schematic diagram of the structure of the account reconciliation device in the embodiment of this specification;

[0032] Figure 7 It is a schematic diagram of the structure of an electronic device in an embodiment of this specification. DETAILED DESCRIPTION

[0033] The following will be combined with the drawings in the embodiments of this specification to clearly and completely describe the technical solutions in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0034] A distributed transaction system can include a coordinator and a system. A coordinator can be used to initiate and manage distributed transactions. The subjects involved in a distributed transaction can include a coordinator. A system can be used to process branch transactions in a distributed transaction. The subjects involved in a distributed transaction can include multiple systems. If a failure or anomaly occurs in the storage, network, or other infrastructure during the business process, it may lead to inconsistent branch transaction processing results in different systems. For example, see Figure 1, the distributed transaction system may include a coordinator, system A, and system B. In the TCC distributed transaction, it may include a first phase and a second phase. The first phase may be a preprocessing phase (Try phase), and the second phase may be a confirmation phase (Confirm phase). The coordinator may send instructions to execute the first phase of the branch transaction to system A and system B respectively. The first phase of both system A and system B is successfully executed. Furthermore, the coordinator may send instructions to execute the second phase of the branch transaction to system A and system B respectively. The second phase of system A is successfully executed. Due to an infrastructure failure, system B did not receive the instruction to execute the second phase of the branch transaction. Therefore, system B did not execute the second phase of the branch transaction. In this way, the branch transaction processing results of system A and system B are inconsistent.

[0035] For business scenarios with high concurrency, a short failure may cause inconsistency problems in hundreds or thousands of transactions. In related technologies, the results of branch transaction processing between different systems can usually be checked through end-of-day batch processing, but there are disadvantages such as long checking cycle and late problem discovery, which is easy to cause financial risks and cannot adapt to high-concurrency scenarios.

[0036] See also Figure 2 . An embodiment of this specification provides a reconciliation system. The reconciliation system may include a message system, a data acquisition device, a data processing device, and a reconciliation device. The data acquisition device, the data processing device, and the reconciliation device may be different devices respectively. Alternatively, multiple of the data acquisition device, the data processing device, and the reconciliation device may be integrated into one device. The message system may include a distributed message system. The distributed message system may include Kafka. The message system may include multiple first message queues and multiple second message queues. Among them, each first message queue may correspond to a system, and each system may correspond to a first message queue. Each second message queue may correspond to a system and a transaction scenario. Each transaction scenario may correspond to one or more second message queues. Each system may correspond to one or more second message queues.

[0037] After processing the branch transaction, each system in the distributed transaction system can store the branch transaction processing result in the form of transaction data in a local data table. To this end, the data acquisition device can be used to monitor the changes in the data in the local data table of each system in the distributed transaction system; after monitoring the changes in the data in the local data table of the system, the first transaction data can be collected from the local data table of the system; the collected first transaction data can be written into the first message queue corresponding to the system in the message system. For example, the data table can be a data table in a database. The data acquisition device can monitor the local database log of the system through the database CDC (change data capture) component, and can collect the changed first transaction data in real time from the local data table of the system. The data processing device can obtain the first transaction data from the first message queue of the message system; can determine the transaction scenario corresponding to the first transaction data; can determine the second transaction data based on the first transaction data; can write the second transaction data into the second message queue of the message system corresponding to the transaction scenario and the system of the first transaction data at the same time, so as to reconcile the second transaction data in the second message queue. The reconciliation device can obtain multiple second transaction data from multiple second message queues of the message system, the multiple second message queues correspond to the same transaction scenario and correspond to different systems respectively; and can reconcile the multiple second transaction data.

[0038] See also Figure 3 The embodiment of this specification provides a reconciliation method. The reconciliation method can be applied to the data processing device, and specifically can include the following steps.

[0039] Step S11: Obtain first transaction data from a first message queue of a message system, wherein the message system includes multiple first message queues, each first message queue corresponds to a system, and includes first transaction data collected from a data table of the system, wherein the system is used to process branch transactions in distributed transactions, and the data table is used to store processing results of branch transactions.

[0040] In some embodiments, the first transaction data may be obtained from the first message queue of the message system according to the configuration information. The configuration information may include the communication address of the message system and the identifier of the first message queue. For example, the data processing device may send a request to the message system according to the communication address of the message system, and the request may include the identifier of the first message queue. The message system may receive the request; may obtain the first transaction data from the first message queue according to the identifier of the first message queue; and may send the first transaction data to the data processing device.

[0041] Step S13: Determine a transaction scenario according to the first transaction data.

[0042] In some embodiments, the transaction scenario may be determined based on the sub-data used to indicate the business type in the first transaction data. For example, the sub-data used to indicate the business type may include transaction code sub-data and business category sub-data. Specifically, for example, the transaction code sub-data may be 1234, and the business category sub-data may be ebank.

[0043] Step S15: Determine the second transaction data according to the first transaction data.

[0044] In some embodiments, sub-data corresponding to the transaction primary key can be extracted from the first transaction data; sub-data corresponding to the field to be checked can be extracted from the first transaction data; and second transaction data can be constructed based on the sub-data corresponding to the transaction primary key and the sub-data corresponding to the field to be checked.

[0045] For example, by concatenating fields such as the remittance sequence number and the channel event number, a transaction primary key field can be obtained. The transaction primary key field can be used to uniquely identify a transaction. Therefore, the sub-data corresponding to the remittance sequence number field and the sub-data corresponding to the channel event number can be obtained from the first transaction data as the sub-data corresponding to the transaction primary key. The field to be checked may include fields such as processing status and accounting amount. Therefore, the sub-data corresponding to the processing status field and the sub-data corresponding to the accounting amount field can be extracted from the first transaction data as the sub-data corresponding to the field to be checked.

[0046] It is worth noting that if the field registration rules between different systems are different, the conversion can be performed based on the initiator. For example, the processing status of system A is registered as: 0 for success, 1 for failure; the processing status of downstream system B is: 1 for success, 2 for failure, then the conversion is performed based on system A, and uniformly recorded as: 0 for success, 1 for failure.

[0047] For example, the format of the second transaction data may be:

[0048]

[0049] Step S17: writing the second transaction data into a second message queue in the message system that corresponds to both the transaction scenario and the system of the first transaction data, so as to perform reconciliation processing on the second transaction data in the second message queue.

[0050] In some embodiments, the system of the first transaction data may be the source system of the first transaction data. Specifically, for example, if the first transaction data is collected from a data table of system A, the system of the first transaction data may be system A.

[0051] The reconciliation method of the embodiment of this specification can obtain the first transaction data from the first message queue of the message system; can determine the transaction scenario based on the first transaction data; can determine the second transaction data based on the first transaction data; can write the second transaction data into the second message queue in the message system that corresponds to the transaction scenario and the system of the first transaction data at the same time, so as to reconcile the second transaction data in the second message queue. In this way, by using the message queue in the message system, the reconciliation of the branch transaction processing results between different systems can be achieved without intruding the business code, effectively alleviating the risks that may be caused by the inconsistency of the branch transaction processing results of each system in a high-concurrency business scenario.

[0052] See also Figure 4 The embodiment of this specification provides a method for reconciliation. The method for reconciliation can be applied to the reconciliation device, and specifically can include the following steps.

[0053] Step S21: Acquire multiple second transaction data from multiple second message queues of the message system, where the multiple second message queues correspond to the same transaction scenario and correspond to different systems respectively.

[0054] Step S23: reconcile the plurality of second transaction data.

[0055] In some embodiments, the second transaction data may include sub-data corresponding to the transaction primary key and sub-data corresponding to the field to be checked. In this way, the sub-data corresponding to the transaction primary key in the plurality of second transaction data may be used to perform reconciliation processing on the sub-data corresponding to the field to be checked in the plurality of second transaction data to obtain a reconciliation result. Thus, reconciliation processing can be performed on the branch transaction processing results of multiple systems in the same transaction scenario.

[0056] For example, the plurality of second transaction data may include second transaction data A and second transaction data B.

[0057] The second transaction data A may be:

[0058]

[0059]

[0060] The second transaction data B may be:

[0061]

[0062] Then, we can check whether A.statusA is equal to B.statusB, and whether A.amountA is equal to B.amountB.

[0063] The reconciliation method of the embodiment of this specification can obtain multiple second transaction data from multiple second message queues in the message system, and the multiple second message queues correspond to the same transaction scenario and correspond to different systems respectively; the multiple second transaction data can be reconciled. In this way, by using the message queue in the message system, the reconciliation of branch transaction processing results between different systems can be achieved without intruding the business code, effectively alleviating the risks that may be caused by inconsistent branch transaction processing results of various systems in high-concurrency business scenarios.

[0064] See also Figure 5 The embodiment of this specification provides a reconciliation device, including the following units.

[0065] An acquisition unit 31 is used to acquire first transaction data from a first message queue of a message system, the message system includes multiple first message queues, each first message queue corresponds to a system, including first transaction data collected from a data table of the system, the system is used to process branch transactions in distributed transactions, and the data table is used to store processing results of branch transactions;

[0066] A first determining unit 33, configured to determine a transaction scenario according to the first transaction data;

[0067] A second determining unit 35, configured to determine second transaction data according to the first transaction data;

[0068] The writing unit 37 is used to write the second transaction data into a second message queue in the message system that corresponds to both the transaction scenario and the system of the first transaction data, so as to perform reconciliation processing on the second transaction data in the second message queue.

[0069] See also Figure 6 The embodiment of this specification provides a reconciliation device, including the following units.

[0070] An acquisition unit 41 is used to acquire a plurality of second transaction data from a plurality of second message queues of the message system, wherein the plurality of second message queues correspond to the same transaction scenario and correspond to different systems respectively;

[0071] The reconciliation unit 43 is used to perform reconciliation processing on the plurality of second transaction data.

[0072] See also Figure 7 The embodiments of this specification also provide an electronic device.

[0073] The electronic device may include a memory and a processor.

[0074] In this embodiment, the memory includes but is not limited to dynamic random access memory (DRAM) and static random access memory (SRAM), etc. The memory can be used to store computer instructions.

[0075] In this embodiment, the processor may be implemented in any suitable manner. For example, the processor may take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, a logic gate, a switch, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, etc. The processor may be used to execute the computer instructions to implement Figure 3 , Figure 4 The corresponding embodiment.

[0076] It should be noted that each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for device embodiments and electronic device embodiments, since they are basically similar to method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment. In addition, it is understandable that after reading this specification document, those skilled in the art can think of any combination of some or all of the embodiments listed in this specification without creative work, and these combinations are also within the scope of disclosure and protection of this specification.

[0077] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0078] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0079] It can be known from the above description of the implementation mode that the technicians in this field can clearly understand that the present specification can be implemented by means of software plus the necessary general hardware platform. Based on such an understanding, the technical solution of the present specification can be essentially or the part that contributes to the prior art can be embodied in the form of a software product, which can be stored in a storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present specification or some parts of the embodiments.

[0080] This specification can be used in many general or special computer system environments or configurations, such as personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronic devices, network PCs, minicomputers, mainframe computers, and distributed computing environments that include any of the above systems or devices.

[0081] This specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0082] Although the present specification is described through embodiments, those skilled in the art will appreciate that there are many modifications and changes to the present specification without departing from the spirit of the present specification, and it is intended that the appended claims include these modifications and changes without departing from the spirit of the present specification.

Claims

1. A reconciliation method, the reconciliation method is used to reconcile branch transaction processing results between different systems in a distributed transaction system, the distributed transaction system includes multiple systems, each system is used to process branch transactions of distributed transactions, and the branch transaction processing results of each system are stored in a local data table in the form of transaction data, the reconciliation method includes: Acquire the first transaction data from a first message queue of a message system, wherein the message system includes a plurality of first message queues and a plurality of second message queues, wherein the plurality of first message queues correspond to different systems, each first message queue corresponds to a system, and includes the first transaction data collected from a local data table of the system, and each second message queue of the message system corresponds to a system and a transaction scenario; Determining a transaction scenario according to the first transaction data; Determining second transaction data according to the first transaction data; The second transaction data is written into a second message queue in the message system that corresponds to both the transaction scenario and the system of the first transaction data, so as to perform reconciliation processing on the second transaction data in the second message queue.

2. The method according to claim 1, wherein the message system comprises a distributed message system Kafka.

3. According to the method of claim 1, the first transaction data is written into the first message queue in the following manner: Collecting first transaction data from a data table of the system; The collected first transaction data is written into a first message queue in the message system corresponding to the system of the first transaction data.

4. The method according to claim 1, wherein determining a transaction scenario comprises: A transaction scenario is determined according to the sub-data used to represent the business type in the first transaction data.

5. The method of claim 1, wherein determining the second transaction data comprises: Extracting sub-data corresponding to the transaction primary key from the first transaction data; Extracting sub-data corresponding to the field to be checked from the first transaction data; The second transaction data is constructed according to the sub-data corresponding to the transaction primary key and the sub-data corresponding to the field to be checked.

6. A reconciliation method, the reconciliation method is used to reconcile branch transaction processing results between different systems in a distributed transaction system, the distributed transaction system includes multiple systems, each system is used to process branch transactions of distributed transactions, and the branch transaction processing results of each system are stored in a local data table in the form of transaction data, the reconciliation method includes: Acquire multiple second transaction data from multiple second message queues of the message system, where the multiple second message queues correspond to the same transaction scenario and correspond to different systems respectively; Reconciliation processing is performed on the plurality of second transaction data.

7. The method according to claim 6, wherein the second transaction data includes sub-data corresponding to the transaction primary key and sub-data corresponding to the field to be checked; and the reconciliation processing of the plurality of second transaction data includes: Using the sub-data corresponding to the transaction primary key in the plurality of second transaction data, reconciliation processing is performed on the sub-data corresponding to the to-be-checked fields in the plurality of second transaction data to obtain a reconciliation result.

8. A reconciliation device, wherein the reconciliation method is used to reconcile branch transaction processing results between different systems in a distributed transaction system, wherein the distributed transaction system includes multiple systems, each system is used to process branch transactions of distributed transactions, and the branch transaction processing results of each system are stored in a local data table in the form of transaction data, wherein the reconciliation device includes: an acquisition unit, configured to acquire first transaction data from a first message queue of a message system, wherein the message system includes a plurality of first message queues and a plurality of second message queues, wherein the plurality of first message queues correspond to different systems, each first message queue corresponds to a system, and includes the first transaction data collected from a local data table of the system, and each second message queue of the message system corresponds to a system and a transaction scenario; A first determining unit, configured to determine a transaction scenario according to the first transaction data; a second determining unit, configured to determine second transaction data according to the first transaction data; The writing unit is used to write the second transaction data into a second message queue in the message system that corresponds to both the transaction scenario and the system of the first transaction data, so as to perform reconciliation processing on the second transaction data in the second message queue.

9. A reconciliation device, wherein the reconciliation method is used to reconcile branch transaction processing results between different systems in a distributed transaction system, wherein the distributed transaction system includes multiple systems, each system is used to process branch transactions of distributed transactions, and the branch transaction processing results of each system are stored in a local data table in the form of transaction data, wherein the reconciliation device includes: An acquisition unit, configured to acquire a plurality of second transaction data from a plurality of second message queues of the message system, wherein the plurality of second message queues correspond to the same transaction scenario and correspond to different systems respectively; A reconciliation unit is used to perform reconciliation processing on the plurality of second transaction data.

10. An electronic device, comprising: at least one processor; A memory storing program instructions, wherein the program instructions are configured to be executed by the at least one processor, and the program instructions include instructions for executing the method according to any one of claims 1 to 7.

Images