Recharging transaction state management method and device, equipment, storage medium and product

Abstract

The invention discloses a top-up transaction state management method and device, equipment, a storage medium and a product. The method comprises the steps that a current top-up transaction identifier is generated by adopting an RTL module according to top-up information carried by a top-up application; if the same transaction identifier does not exist, constructing account information of a plurality of dimensions by adopting an HCAA module according to the recharging information so as to determine an account path; a ZTB module is adopted to carry out fund risk verification on the account path; if the verification is passed, splitting the currently recharged transaction into a plurality of sub-transactions by adopting a CMD module, and determining an execution sequence of each sub-transaction; according to the execution sequence, the TTE module is adopted to execute the dynamic account transaction in a layered mode; generating full-link tracing data by adopting an OLS module according to the dynamic account transaction result and the transaction identifier; and updating the transaction state into a completion state, and carrying out result notification. Based on cooperative work of the six modules, the account expansion and audit tracing efficiency can be improved, and real-time risk control interception is realized.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of account recharge, in particular to a recharge transaction state management method, device, equipment, storage medium and product. BACKGROUND

[0002] The advertising agency industry needs to perform multi-batch, large amount, multi-currency recharge for a large number of advertising accounts every day. The traditional financial system of the advertising agency industry adopts a static subject, manual reconciliation, and T+1 reconciliation mode, which has the following defects: because the advertising account involves multiple dimensions such as channels (such as Douyin and Kuaishou), currencies (such as CNY and USD), and fund attributes (such as cash and grants), the traditional static subject table presents a Cartesian product explosion, resulting in a dramatic increase in data definition language (DDL) change cost, and the need for large-scale system adjustment for new dimensions, making it difficult to expand the static matrix; the traditional system only detects fund abnormalities (such as over-recharge and overdraft) in the T+1 offline reconciliation stage, and cannot intercept risks in real time, resulting in long-term existence of fund exposure, increasing the cost of recovering funds and the risk of fund loss; the link tracking granularity is only to the balance snapshot level, lacking time sequence correlation of the atomic events of the application-freezing-transfer-confirmation-recharge full life cycle, resulting in high audit traceability complexity. SUMMARY

[0003] The present application provides a recharge transaction state management method, device, equipment, storage medium and product, which can improve account expansion efficiency, realize real-time risk control interception, improve audit traceability efficiency, and improve fund utilization rate based on the cooperative work of RTL, HCAA, ZTB, CMD, TTE and OLS six modules.

[0004] To achieve the above purpose, the present application embodiment provides a recharge transaction state management method, comprising: When receiving a recharge application, a transaction identifier of the current recharge is generated by using an RTL module according to recharge information carried by the recharge application; If there is no same transaction identifier, account information of several dimensions of the current recharge is constructed by using an HCAA module according to the recharge information, so as to determine the account path of the current recharge; The account path is subjected to fund risk verification by using a ZTB module; if the verification is passed, the current recharge transaction is split into several sub-transactions by using a CMD module, and the execution order of each sub-transaction is determined; The account transaction of each sub-transaction is executed in layers by using a TTE module according to the execution order of each sub-transaction, and the account transaction result of the current recharge is obtained; Full-link traceability data of the current recharge is generated by using an OLS module according to the account transaction result and the transaction identifier; the transaction state of the current recharge is updated to a completed state by using the RTL module, and a result notification is performed.

[0005] As an improvement to the above scheme, when a recharge request is received, generating a transaction identifier for the current recharge using an RTL module based on the recharge information carried in the recharge request includes: When a recharge request is received, the RTL module is used to obtain the recharge request number and channel ID of the current recharge from the recharge information carried in the recharge request; Generate a global idempotent key for the current recharge by combining the recharge request number and the channel ID; The global idempotent key and the current recharge transaction status are written to the distributed log using the Paxos-based distributed log replication protocol to obtain the transaction identifier of the current recharge.

[0006] As an improvement to the above scheme, if no identical transaction identifier exists, the HCAA module is used to construct account information for the current recharge based on the recharge information to determine the account path for the current recharge, including: If no identical transaction identifier exists, the HCAA module is used to map the recharge information to Morton Code using a Z-Order curve to construct account information for the current recharge in several dimensions. The account path for the current recharge is generated based on the account information using the YAML configuration template of the HCAA module.

[0007] As an improvement to the above solution, the ZTB module is used to perform fund risk verification on the account path; if the verification passes, the CMD module is used to split the current recharge transaction into several sub-transactions and determine the execution order of each sub-transaction, including: The eBPF probe in the ZTB module is used to calculate the current available credit limit for the account path through a dynamic credit limit view based on differential privacy; If the current available amount is greater than the current recharge amount, the CMD module is used to construct the DAG model of the current recharge transaction, and the Tarjan algorithm is used to detect strongly connected components in the DAG model. Based on the recharge information, the current recharge transaction is divided into several sub-transactions; After mapping each sub-transaction to a node in the passed DAG model, the execution order of each sub-transaction is determined according to the topological sorting of the passed DAG model.

[0008] As an improvement to the above scheme, the TTE module includes a freeze sub-engine, a delay netting sub-engine, and a dual-mode execution accounting engine.

[0009] As an improvement of the above scheme, the OLS module is adopted to generate full-link trace data of the current recharge according to the dynamic account transaction result and the transaction identification; the RTL module is adopted to update the transaction state of the current recharge to a completed state, and result notification is performed, including: The OLS module is adopted to track the link of the full process of the current recharge according to the dynamic account transaction result and the transaction identification; The tracked data is stored in the LSM-Tree time sequence ledger to generate full-link trace data of the current recharge; The RTL module is adopted to update the transaction state of the current recharge to a completed state, and the transaction state in the distributed log is synchronously updated based on the Paxos distributed log replication protocol, and result notification is performed.

[0010] To achieve the above object, the embodiment of the application correspondingly provides a recharge transaction state management device, which comprises: A transaction identification generation module is configured to generate a transaction identification of a current recharge by using an RTL module according to recharge information carried by a recharge application when the recharge application is received; An account information construction module is configured to construct account information of several dimensions of the current recharge by using an HCAA module according to the recharge information if the same transaction identification does not exist, so as to determine an account path of the current recharge; A recharge transaction splitting module is configured to perform fund risk verification on the account path by using a ZTB module, and split the transaction of the current recharge into several sub-transactions by using a CMD module if the verification is passed, and determine an execution order of each sub-transaction; A dynamic account transaction execution module is configured to perform dynamic account transactions of each sub-transaction by using a TTE module according to the execution order of each sub-transaction, so as to obtain a dynamic account transaction result of the current recharge; A transaction state updating module is configured to generate full-link trace data of the current recharge by using an OLS module according to the dynamic account transaction result and the transaction identification, and update the transaction state of the current recharge to a completed state by using the RTL module, and perform result notification.

[0011] To achieve the above object, the embodiment of the application correspondingly provides a recharge transaction state management device, which comprises a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, and the processor implements the recharge transaction state management method when the computer program is executed.

[0012] To achieve the above object, the embodiment of the present application further provides a computer readable storage medium, which comprises a stored computer program, wherein the computer readable storage medium controls a device where the computer readable storage medium is located to execute the recharging transaction state management method when the computer program runs.

[0013] To achieve the above object, the embodiment of the present application further provides a computer program product, which is stored in a storage medium, and the program product is executed by at least one processor to implement the steps of the recharging transaction state management method.

[0014] Compared with the prior art, the recharging transaction state management method, device, equipment, storage medium and product disclosed by the embodiment of the present application can generate a transaction identifier of the current recharging by using an RTL module according to recharging information carried by a recharging application when the recharging application is received; if there is no same transaction identifier, account information of several dimensions of the current recharging is constructed according to the recharging information by using an HCAA module to determine an account path of the current recharging; the account path is subjected to fund risk verification by using a ZTB module; if the verification is passed, the current recharging transaction is split into several sub-transactions by using a CMD module, and the execution order of each sub-transaction is determined; the account transaction of each sub-transaction is executed in layers according to the execution order of each sub-transaction by using a TTE module to obtain the account transaction result of the current recharging; the full-link traceability data of the current recharging is generated according to the account transaction result and the transaction identifier by using an OLS module; the transaction state of the current recharging is updated to a completed state by using the RTL module, and the result is notified. The collaborative work of the RTL, HCAA, ZTB, CMD, TTE and OLS modules can improve the account expansion efficiency, realize real-time risk control interception, improve the audit traceability efficiency, and improve the fund utilization rate. BRIEF DESCRIPTION OF DRAWINGS

[0015] Figure 1 is a flowchart of a recharging transaction state management method provided by the embodiment of the present application; Figure 2 is a structural schematic diagram of a recharging transaction state management device provided by the embodiment of the present application; Figure 3 is a structural block diagram of a recharging transaction state management equipment provided by the embodiment of the present application. DETAILED DESCRIPTION

[0016] With reference to the drawings of the embodiments of the present application, the technical solutions in the embodiments of the present application will be clearly and completely described. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments of the present application, all the other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present application.

[0017] It should be noted that the terms "comprising" and "specifically" and any variations of them in the present application are intended to cover the non-exclusive inclusion, for example, the process, method, system, product or device including a series of steps or units does not have to be limited to the clearly listed steps or units, but can include other steps or units that are not clearly listed or inherent to the process, method, product or device.

[0018] Please refer to Figure 1 , Figure 1 is a flow diagram of a recharge transaction state management method provided by the embodiments of the present application. The recharge transaction state management method comprises: S1, when receiving a recharge application, generating a transaction identifier of the current recharge by using an RTL module according to recharge information carried by the recharge application; S2, if there is no same transaction identifier, constructing account information of several dimensions of the current recharge by using an HCAA module according to the recharge information, to determine an account path of the current recharge; S3, performing fund risk verification on the account path by using a ZTB module; if the verification is passed, splitting the transaction of the current recharge into several sub-transactions by using a CMD module, and determining the execution order of each sub-transaction; S4, performing the account transaction of each sub-transaction by using a TTE module according to the execution order of each sub-transaction, to obtain the account transaction result of the current recharge; S5, generating full-link traceability data of the current recharge by using an OLS module according to the account transaction result and the transaction identifier; updating the transaction state of the current recharge to a completed state by using the RTL module, and performing result notification.

[0019] An exemplary, the input of the recharge application information initiates the recharge application; wherein the recharge application information at least includes the recharge application number, the channel ID, the recharge amount, the fund attribute and the customer subject, the RTL (Request Transaction Log, idempotent request and global transaction log) module generates a 128-bit Snowflake-ID as a global idempotent key (the unique transaction identifier of the current recharge, to avoid repeated processing) with the recharge application number and the channel ID as the joint key. If there is no same transaction identifier, the HCAA (Hyper Cube Account Assembler, high-dimensional dynamic account assembling engine) module is used to construct at least five-dimensional account information of channel, currency, fund attribute, region and customer subject according to the recharge information, and the YAML configuration template (the preset rule of YAML configuration template: {channel}_{currency}_{fund attribute}_{region}_{customer subject}) of the HCAA module is used to dynamically generate a unique account path to determine the account path of the current recharge. Before executing the actual fund deduction, the ZTB (Risk Zero Trust Blocker, real-time risk control interceptor) module is used to pre-freeze the account path-amount check to determine whether there is an overcharge, overdraft risk, such as constructing a dynamic credit view based on differential privacy, the calculation formula is current available credit Δ = Σ credit (account total available credit) - Σ frozen (other in-transit frozen funds) - Σ confirmed (completed recharge amount) + Σ repayment (media return funds); if the current available credit Δ ≥ recharge amount, the process is allowed to continue; if the current available credit Δ < recharge amount, the risk interception is triggered; if the check passes, the CMD (Causal MergeDAG, causal consistency state merging algorithm) module is used to split the current recharge transaction into several sub-transactions (such as freezing, transferring, and point pre-withdrawal), and determine the execution order of each sub-transaction. According to the execution order of each sub-transaction, the TTE (Tiered Trade Engine AD, tiered heterogeneous transaction engine) module is used to execute each sub-transaction of the dynamic account transaction, such as executing pre-freezing through the frozen sub-engine (Risk Frozen Engine-AD), marking the recharge amount as frozen state; the RTE (Real-Time Event, real-time event) mode of the dual-mode execution kernel is used to complete the fund cross-account transfer; the delay netting sub-engine (Risk Netting Engine-AD) is used to execute delay netting and batch process point calculation to obtain the dynamic account transaction result of the current recharge. According to the dynamic account transaction result and the transaction identifier, the OLS (Omni Ledger Service, global traceable ledger) module is used to generate the full-link traceability data of the current recharge; the RTL module is used to update the transaction state of the current recharge to the completion state, and the result notification is performed.

[0020] Specifically, the step S1 comprises: S11, when receiving the recharge application, using an RTL module to obtain the current recharge application number and channel ID from the recharge information carried by the recharge application; S12, the recharge application number and channel ID are combined to generate a global unique key for the current recharge; S13, using a Paxos-based distributed log replication protocol to write the global unique key and the transaction state of the current recharge into a distributed log to obtain the transaction identification of the current recharge.

[0021] Illustratively, using the recharge application number and channel ID as the joint unique key of the 128-bit Snowflake-ID, using the Paxos-based distributed log replication protocol to write the unique key and transaction state into the WAL of the Raft Group, in the case of lock conflict window <10 ms, avoiding ghost reading through MVCC snapshot reading, realizing linear consistency deduplication; the transaction state of the current recharge: INIT→FROZEN→TRANSFER→CONFIRM→COMPLETE (initialization→freezing→transfer→confirmation→completion); through unique index+Redis SETNX to realize distributed lock, guarantee ≤10 ms of concurrent deduplication. When the request arrives, first query the log table, if there is the same ID and the state is SUCCESS, then directly return the historical result, avoid repeated processing. If there is no or the state is FAILED, then lock the record and execute the business logic, update the state after completion. It can solve the problem of double billing caused by the same recharge instruction repeated delivery due to network jitter or business retry.

[0022] Specifically, the step S2 comprises: S21, if there is no same transaction identification, using an HCAA module to map the recharge information to a Morton Code through a Z-Order curve to construct the account information of the current recharge in several dimensions; S22, generating the account path of the current recharge according to the account information through the YAML configuration template of the HCAA module.

[0023] For example, the Z-Order curve-based multi-dimensional sparse index maps five-dimensional coordinates (recharge information) to a 64-bit Morton Code, reducing query complexity; the rule DSL (Domain Specific Language) uses YAML-AST description, and is compiled into bytecode by GraalVM JIT at runtime, with a hot loading delay of <2 s; new dimensions only need to push incremental patches in the configuration center, and the engine realizes lock-free hot updates through the CRDT (Conflict-Free Replicated Data Type) merging algorithm. For example, the RiskHardRuleRouter routes to the corresponding Supplier processor according to the transaction type (such as FROZEN, TRADE), and each Supplier encapsulates the account logic of a specific scenario. When a new transaction type is added, only the new Supplier needs to be implemented and registered to the routing table, without the need to modify the core code. The configuration rules (such as JSON or YAML) support dynamic loading, and the engine parses the YAML into an Account-Tree object at startup, and dynamically assembles the account path at runtime according to the recharge application. New channels only need to be hot updated in the configuration center, and take effect within 10 s without the need to restart, solving the problem of the difficulty of expanding the traditional two-dimensional subject table. The YAML rule configuration syntax is as follows: Extension mechanism: |accountTemplate: |pattern: "{media}_{currency}_{fundType}" |segments: |- name: media |enum: [Toutiao, Kuaishou, Tencent] |- name: currency |enum: [CNY, USD] |- name: fundType |enum: [CASH, GRANT, REBATE] |splitRules: |- source: USER_DEPOSIT |targets: |- account: "{media}_{currency}_AVAILABLE" |ratio: 1.0 Specifically, the step S3 comprises: S31, calculating the current available credit of the account path by a dynamic credit view based on differential privacy through an eBPF probe in the ZTB module; S32, if the current available credit is greater than the current recharge amount, constructing a DAG model of the current recharge transaction by the CMD module, and performing strong connected component detection on the DAG model by the Tarjan algorithm; S33, splitting the current recharge transaction into several sub-transactions according to the recharge information; S34, after mapping each sub-transaction and the node in the passed DAG model, determining the execution order of each sub-transaction according to the topological sorting of the passed DAG model.

[0024] For example, an eBPF (Extended Berkeley Packet Filter) probe is implanted in the execution path of the current recharge transaction, Pre-Commit sandbox calculation is performed for each account, if Δ≥ recharge amount, the process is allowed to continue; if Δ< recharge amount, risk interception is triggered, such as triggering a WASM-based policy engine to complete decision-making and roll back the transaction within 50 ms, and synchronously pushing an alarm to the event bus; returning an error code "AD_OVER_RECHARGE", and alarming the business through Dingding robots within 50 ms. The problem that abnormal situations such as over-recharge and overdraft are not discovered until T+1, and post-risk control cannot meet the financial-level zero-risk requirement, is solved. The CMD module is used to construct a directed acyclic graph (DAG) of the current recharge transaction with Vector Clock as the node (node=sub-account) and the amount flow direction as the edge, to ensure the causality between sub-transactions; the Tarjan algorithm is used to perform strong connected component detection on the DAG model to exclude circular dependency problems such as freezing after transferring, to ensure no circular dependency; the recharge application form is parsed into a MultiVertex list, and the TopologicalSort is used to determine the account order of each sub-transaction; based on the two-phase commit of the Saga mode, phase one: performing Try operation on each sub-account and writing undo-log; phase two: performing Commit if the global verification passes, otherwise performing Compensate (compensation) and rolling back in the same order as the inverse order of Vector Clock. It is ensured that the same recharge may trigger four sub-transactions of freezing, account splitting, compensation and rebate, and global causal consistency.

[0025] Specifically, the TTE module includes a freezing sub-engine, a delay balance difference sub-engine, and a dual-mode execution accounting engine.

[0026] For example, the RiskFrozenEngine-AD uses optimistic locking and row-level version numbers to achieve pre-freeze-partial-thaw semantics, avoiding global lock bottlenecks; the RiskNettingEngine-AD uses Kafka Streams' Exactly-Once semantics to aggregate media API stream account data by (channel, date) partitioning; based on Little's Law, dynamically adjust to improve CPU utilization; the Dual-ModeExecution Kernel uses eBPF + io_uring as the foundation, establishing a zero-copy ring buffer between user mode and kernel mode, abstracting accounting instructions into two types of observable events, Real-Time Event (RTE) mode requiring linear consistency; Deferred Event (DE) mode allowing eventual consistency. The engine performs on-the-fly instruction rerouting to complete mode switching at the nanosecond level without the need for restarts or downtime to complete real-time accounting.

[0027] Specifically, the step S5 comprises: S51, using an OLS module to perform link tracking on the entire process of the current recharge according to the dynamic account transaction result and the transaction identifier; S52, storing the tracked data in a time-series ledger based on LSM-Tree to generate full-link traceability data for the current recharge; S53, using the RTL module to update the transaction status of the current recharge to a completed state, and synchronously updating the transaction status in the distributed log based on the Paxos distributed log replication protocol, and notifying the result.

[0028] For example, link tracking: Trace-ID uses OpenTelemetry 128-bit Trace-Context, custom Trace-ID, and runs through the entire process of CRM (application initiation) → media → risk control → fund channel → ERP; time-series ledger storage based on LSM-Tree supports consistent reconstruction of any time slice; provides Merkle Tree checksum, and chain associates the hash value of each log, if any log is tampered with, the checksum will not match, ensuring that the audit log is tamper-proof; through Trace-ID, full-link logs can be retrieved with one key, without the need for manual checking of multiple system data. The RTL module updates the transaction status of the current recharge from TRANSFER (in transfer) to COMPLETE (complete), and synchronously updates the status in the distributed log; sends an email / sms to the recharge customer, informing them that the advertising recharge has been credited and the account balance.

[0029] The recharging transaction state management method disclosed by the embodiment of the application comprises the following steps: when a recharging application is received, a transaction identifier of the current recharging is generated by using an RTL module according to recharging information carried by the recharging application; if there is no same transaction identifier, account information of several dimensions of the current recharging is constructed by using an HCAA module according to the recharging information, so as to determine an account path of the current recharging; the account path is subjected to fund risk verification by using a ZTB module; if the verification is passed, the transaction of the current recharging is split into several sub-transactions by using a CMD module, and the execution order of each sub-transaction is determined; the account transaction of each sub-transaction is executed in layers by using a TTE module according to the execution order of each sub-transaction, so as to obtain the account transaction result of the current recharging; full-link traceability data of the current recharging is generated by using an OLS module according to the account transaction result and the transaction identifier; the transaction state of the current recharging is updated to a completed state by using the RTL module, and a result notification is performed. The collaborative work of the RTL, HCAA, ZTB, CMD, TTE and OLS modules can improve the account expansion efficiency, realize real-time risk control interception, improve the audit traceability efficiency, and improve the fund utilization rate.

[0030] Referring to Figure 2 , Figure 2 is a structural schematic diagram of a recharging transaction state management device 10 provided by the embodiment of the application. The recharging transaction state management device 10 comprises: a transaction identifier generation module 11, configured to, when a recharging application is received, generate a transaction identifier of the current recharging by using an RTL module according to recharging information carried by the recharging application; an account information construction module 12, configured to, if there is no same transaction identifier, construct account information of several dimensions of the current recharging by using an HCAA module according to the recharging information, so as to determine an account path of the current recharging; a recharging transaction splitting module 13, configured to, by using a ZTB module, perform fund risk verification on the account path; if the verification is passed, split the transaction of the current recharging into several sub-transactions by using a CMD module, and determine the execution order of each sub-transaction; an account transaction execution module 14, configured to, by using a TTE module, execute the account transaction of each sub-transaction in layers according to the execution order of each sub-transaction, so as to obtain the account transaction result of the current recharging; a transaction state updating module 15, configured to, by using an OLS module, generate full-link traceability data of the current recharging according to the account transaction result and the transaction identifier; update the transaction state of the current recharging to a completed state by using the RTL module, and perform a result notification.

[0031] The recharging transaction state management device 10 provided by the embodiment of the present application can implement all processes of the recharging transaction state management method of the above embodiment, and the functions of each module in the device and the technical effects achieved are the same as the functions of the recharging transaction state management method of the above embodiment and the technical effects achieved, which will not be repeated here.

[0032] Referring to Figure 3 , Figure 3 is a structural schematic diagram of a recharging transaction state management device 20 provided by the embodiment of the present application. The recharging transaction state management device 20 of the embodiment comprises a processor 21, a memory 22, and a computer program stored in the memory 22 and capable of running on the processor 21. The processor 21 implements the steps in the above recharging transaction state management method embodiment when executing the computer program. Alternatively, the processor 21 implements the functions of each module in the above recharging transaction state management device embodiment when executing the computer program.

[0033] For example, the computer program can be divided into one or more modules, which are stored in the memory 22 and executed by the processor 21 to complete the present application. The one or more modules can be a series of computer program instruction segments capable of completing a specific function, which are used to describe the execution process of the computer program in the recharging transaction state management device 20.

[0034] The recharging transaction state management device 20 can be a desktop computer, a notebook computer, a palm computer, a cloud server, and other computing devices. The recharging transaction state management device 20 can include, but is not limited to, the processor 21 and the memory 22. Those skilled in the art can understand that the schematic diagram is only an example of the recharging transaction state management device 20, and does not limit the recharging transaction state management device 20, which can include more or fewer components than the diagram, or combine certain components, or different components, for example, the recharging transaction state management device 20 can also include an input / output device, a network access device, a bus, etc.

[0035] The processor 21 can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field-programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic components, discrete hardware components, etc. The general-purpose processor can be a microprocessor or can also be any conventional processor. The processor 21 is a control center of the recharge transaction status management device 20, and is connected with various parts of the recharge transaction status management device 20 through various interfaces and lines.

[0036] The memory 22 can be used to store computer programs and / or modules. The processor 21 realizes various functions of the recharge transaction status management device 20 by running or executing the computer programs and / or modules stored in the memory 22, and calling data stored in the memory 22. The memory 22 can mainly include a program storage area and a data storage area. The program storage area can store an operating system, at least one application program required for a function (such as a sound playing function, an image playing function, etc.), etc. The data storage area can store data created according to the use of the mobile phone (such as audio data, a phone book, etc.), etc. In addition, the memory 22 can include a high-speed random access memory, and can also include a non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, at least one disk storage device, a flash memory device, or other volatile solid-state memory devices.

[0037] The modules integrated in the recharging transaction state management device 20, if implemented in the form of software functional units and sold or used as independent products, can be stored in a computer readable storage medium. Based on such understanding, all or part of the processes in the above-mentioned embodiment methods can also be completed by a computer program instructing related hardware, and the computer program can be stored in a computer readable storage medium. When the computer program is executed by the processor 21, the steps of the above-mentioned various method embodiments can be implemented. The computer program includes computer program code, which can be in the form of source code, object code, executable files or some intermediate forms, etc. The computer readable medium can include any entity or device capable of carrying the computer program code, recording medium, U disk, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content included in the computer readable medium can be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction, for example, in some jurisdictions, according to legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunication signals.

[0038] It should be noted that the above-described device embodiments are only schematic, and the units described as separate components can or can not be physically separated, and the components shown as units can or can not be physical units, that is, they can be located in one place, or distributed on multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment scheme. In addition, the connection relationship between the modules in the device embodiment provided by the present application indicates that there is a communication connection between them, which can be implemented as one or more communication buses or signal lines. Those skilled in the art can understand and implement it without creative labor.

[0039] The embodiment of the present application also provides a computer readable storage medium, which includes a stored computer program, wherein the computer program controls the device where the computer readable storage medium is located to execute the recharging transaction state management method of the above-mentioned embodiment when the computer program is running.

[0040] In addition, the embodiment of the present application also provides a computer program product stored in a storage medium, and the program product is executed by at least one processor to implement the steps of the recharging transaction state management method of the above-mentioned embodiment.

[0041] The above is the preferred embodiment of the present application, it should be pointed out that, for those skilled in the art, without departing from the principles of the present application, can also make a number of improvements and refinements, these improvements and refinements are also considered to be within the scope of the present application.

Claims

1. A method for managing the status of recharge transactions, characterized in that, include: When a recharge request is received, the RTL module is used to generate a transaction identifier for the current recharge based on the recharge information carried in the recharge request. If no identical transaction identifier exists, the HCAA module is used to construct account information for the current recharge based on the recharge information to determine the account path for the current recharge. The ZTB module is used to verify the fund risk of the account path. If the verification passes, the CMD module is used to split the current recharge transaction into several sub-transactions and determine the execution order of each sub-transaction. The TTE module is used to execute the transaction of each sub-transaction in layers according to the execution order of each sub-transaction, so as to obtain the transaction result of the current recharge. Based on the transaction results and the transaction identifier, the OLS module is used to generate full-chain traceability data for the current recharge. The RTL module is used to update the current recharge transaction status to complete and to send a result notification.

2. The recharge transaction status management method as described in claim 1, characterized in that, When a recharge request is received, the process of generating a transaction identifier for the current recharge using the RTL module based on the recharge information carried in the recharge request includes: When a recharge request is received, the RTL module is used to obtain the recharge request number and channel ID of the current recharge from the recharge information carried in the recharge request; Generate a global idempotent key for the current recharge by combining the recharge request number and the channel ID; The global idempotent key and the current recharge transaction status are written to the distributed log using the Paxos-based distributed log replication protocol to obtain the transaction identifier of the current recharge.

3. The recharge transaction status management method as described in claim 1, characterized in that, If no identical transaction identifier exists, the HCAA module is used to construct account information for the current recharge based on the recharge information to determine the account path for the current recharge, including: If no identical transaction identifier exists, the HCAA module is used to map the recharge information to Morton Code using a Z-Order curve to construct account information for the current recharge in several dimensions. The account path for the current recharge is generated based on the account information using the YAML configuration template of the HCAA module.

4. The recharge transaction status management method as described in claim 1, characterized in that, The ZTB module is used to verify the fund risk of the account path. If the verification passes, the CMD module is used to split the current recharge transaction into several sub-transactions, and the execution order of each sub-transaction is determined, including: The eBPF probe in the ZTB module is used to calculate the current available credit limit for the account path through a dynamic credit limit view based on differential privacy; If the current available amount is greater than the current recharge amount, the CMD module is used to construct the DAG model of the current recharge transaction, and the Tarjan algorithm is used to detect strongly connected components in the DAG model. Based on the recharge information, the current recharge transaction is divided into several sub-transactions; After mapping each sub-transaction to a node in the passed DAG model, the execution order of each sub-transaction is determined according to the topological sorting of the passed DAG model.

5. The recharge transaction status management method as described in claim 4, characterized in that, The TTE module includes a freeze sub-engine, a delay netting sub-engine, and a dual-mode execution accounting engine.

6. The recharge transaction status management method as described in claim 1, characterized in that, The OLS module is used to generate full-chain traceability data for the current recharge based on the transaction results and the transaction identifier. The RTL module is used to update the current recharge transaction status to a completed status and to send a result notification, including: Based on the transaction results and the transaction identifier, the OLS module is used to perform link tracking of the entire current recharge process. Based on the LSM-Tree, the time-series ledger stores the tracked data and generates full-chain traceability data for the current recharge; The RTL module is used to update the current recharge transaction status to a completed status, and the transaction status in the distributed log is synchronously updated based on the Paxos distributed log replication protocol, and the result is notified.

7. A recharge transaction status management device, characterized in that, include: The transaction identifier generation module is used to generate a transaction identifier for the current recharge based on the recharge information carried in the recharge request when a recharge request is received, using the RTL module. The account information construction module is used to construct account information of several dimensions for the current recharge based on the recharge information using the HCAA module if no identical transaction identifier exists, so as to determine the account path for the current recharge. The recharge transaction splitting module is used to perform fund risk verification on the account path using the ZTB module; If the verification passes, the CMD module is used to split the current recharge transaction into several sub-transactions and determine the execution order of each sub-transaction. The transaction execution module is used to execute the transaction of each sub-transaction in layers according to the execution order of each sub-transaction, and obtain the transaction result of the current recharge. The transaction status update module is used to generate full-link traceability data of the current recharge using the OLS module based on the transaction results and the transaction identifier. The RTL module is used to update the current recharge transaction status to complete and to send a result notification.

8. A recharge transaction status management device, characterized in that, It includes a processor, a memory, and a computer program stored in the memory and configured to be executed by the processor, wherein the processor executes the computer program to implement the recharge transaction status management method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored computer program, wherein, when the computer program is executed, it controls the device where the computer-readable storage medium is located to perform the recharge transaction status management method as described in any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product is stored in a storage medium, and the program product is executed by at least one processor to implement the steps of the recharge transaction state management method as described in any one of claims 1-6.

Images