CN118134491A - Method and system for managing public credit - Google Patents

Method and system for managing public credit Download PDF

Info

Publication number
CN118134491A
CN118134491A CN202410157678.4A CN202410157678A CN118134491A CN 118134491 A CN118134491 A CN 118134491A CN 202410157678 A CN202410157678 A CN 202410157678A CN 118134491 A CN118134491 A CN 118134491A
Authority
CN
China
Prior art keywords
transaction
deduction
fund pool
balanceamt
pool variable
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
CN202410157678.4A
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.)
Digital China Financial Software Co ltd
Original Assignee
Digital China Financial Software 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 Digital China Financial Software Co ltd filed Critical Digital China Financial Software Co ltd
Priority to CN202410157678.4A priority Critical patent/CN118134491A/en
Publication of CN118134491A publication Critical patent/CN118134491A/en
Pending legal-status Critical Current

Links

Landscapes

  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The invention discloses a method for managing public credit, belonging to the technical field of financial business systems; the method comprises the following steps: obtaining a balance fund pool variable CAPITALAMT and a consumption fund pool variable BalanceAmt; acquiring a deduction request transaction; front-end business processing is carried out on the deduction request transaction; generating transaction record running water according to the deduction request transaction after the front-end service processing; obtaining a deduction amount from the transaction record running water, and accumulating the deduction amount into a consumption fund pool variable BalanceAmt; judging whether the transaction is successful or not according to the balance fund pool variable CAPITALAMT and the consumption fund pool variable BalanceAmt; the high-concurrency deduction module adopts a new design concept, and can ensure the lock-free processing of the whole-process business and the relative safety of data in high-concurrency deduction or similar business scenes in some specific environments. Meanwhile, a transaction flow backtracking mechanism is utilized, and a reconstruction and protection mechanism is realized when the service crashes.

Description

Method and system for managing public credit
Technical Field
The invention relates to the technical field of financial business systems, in particular to a method and a system for managing public credit.
Background
Deduction is a common business scenario in banking financial business, particularly credit. In a typical financial transaction, a bank or online financial institution will have a pool of funds, and a Request for deduction will be sent by a customer to a server via a Request, which will deduct the amount of funds from the pool and update the available amount of the pool, recording the relevant transaction sequence. When the amount of the fund pool is insufficient, deduction failure is performed to prevent excessive deduction of the fund pool.
In the conventional financial deduction process, the following steps are generally performed:
1. and receiving a deduction request of the amount of money of the customer.
2. Inquiring the current fund pool amount, comparing the deducted request amount, and judging whether the deducted amount is satisfied.
3. If the limit is satisfied, the current request limit is deducted from the fund pool and the relevant running water is saved.
4. If the limit is not satisfied, rejecting the current request and saving the current request flow.
5. And returning a client deduction result.
Deduction of the amount is a relatively sensitive business request in financial business, and therefore a relatively cautious attitude is maintained for processing. It is reasonable to employ the above steps inside a conventional banking system, but as the customer volume increases and the request volume increases, the following may result in a concurrent environment:
1. the existing fund pool is set up in 1000 yuan, the A customer initiates the request deduction 500 yuan, and the B customer initiates the request deduction 800 yuan at the same time.
And 2. The A client thread inquires the fund pool, and inquires that the existing limit is 1000 yuan at the moment, meets the deduction request and prepares to execute the deduction operation.
And 3, the client thread also executes inquiry operation at the moment, the existing limit of the inquiring client is 1000 yuan, the deduction request is also met, and the deduction operation is ready to be executed.
And 4. The deduction is executed in A, and the fund pool limit is reduced from 1000 yuan to 500 yuan.
And B, deduction is carried out, and the fund pool is deducted from 500 yuan to 300 yuan. At this point, the deduction amount overflows.
Therefore, the following three schemes are adopted in the conventional technology:
A. Serialization mode: in the financial deduction operation described above, the three steps 2,3,4 require a locking operation to serialize the step into one atomic operation. When the A requests to carry out the three steps of inquiring, comparing and deducting, the thread B is in a blocking state because the thread B cannot take the lock, so that after the execution of the A is finished, the thread B can continue inquiring, and the condition that the thread B inquires dirty data is avoided.
B. database line lock processing: adding transactions using a database as a row lock
Cas optimistic lock processing. And adding a version number to the database table, checking whether the version numbers are consistent or not when each modification is performed, and if the version numbers are inconsistent, re-searching the comparison processing.
The above problems can be solved to some extent in the case of a concurrent deduction service scenario. However, with the increase of traffic and the gradual complexity of technical systems, bottleneck problems occur more and more:
In the scheme a, locking processing needs to be performed on a plurality of IO operations, and when the concurrency is extremely large, the locking processing becomes a system bottleneck. Especially when the service runs as a micro-service with multiple copies, it is imperative to have distributed locks, and the problem of blocking of distributed locks is particularly pronounced in high concurrency traffic scenarios, thus slowing down the whole traffic.
In the scheme B, a storage process is used, or a larger operand is placed on a data source end, so that strong dependence on a database is formed, besides the limit performance load of the data source end is increased, if the database is switched to mongdb or is subjected to library splitting and table splitting, the scheme is not available, and the limitation is larger.
Scheme C is limited to a scene with lower concurrency, when the concurrency is extremely high, data can be frequently modified, so that a modification program can continuously acquire the version number again, the calculation amount of a CPU is increased, the IO amount is increased, and the method is not lost in the scene with extremely high concurrency.
The existing technical architecture scheme tends to rapidly cope with changing and increasing service adaptation scenes, multiple services can be processed online when the data architecture of the rear end is possible, and different services can also call deduction requests or inquire the residual amount at the same time.
Disclosure of Invention
The invention aims to provide an efficient public credit management method.
In order to solve the technical problems, the invention provides a method for managing public credit, which comprises the following steps:
obtaining a balance fund pool variable CAPITALAMT and a consumption fund pool variable BalanceAmt;
Acquiring a deduction request transaction;
Front-end business processing is carried out on the deduction request transaction;
Generating transaction record running water according to the deduction request transaction after the front-end service processing;
obtaining a deduction amount from the transaction record running water, and accumulating the deduction amount into a consumption fund pool variable BalanceAmt;
judging whether the transaction is successful or not according to the balance fund pool variable CAPITALAMT and the consumption fund pool variable BalanceAmt;
if the transaction is successful, deducting money and generating a corresponding transaction flow log TradeRecord;
If the transaction fails, a withdraw deduction request transaction is performed and the corresponding deduction amount is removed from the consumed funds pool variable BalanceAmt.
Preferably, the method further comprises the following steps:
judging whether a database summarizing operation needs to be executed or not according to the transaction flow log and a preset transaction number threshold;
If the database summarizing operation is required to be executed, locking operation is carried out;
and synchronizing the database with the Redis cache, and performing unlocking operation.
Preferably, the distributed locking and unlocking operations are implemented according to RLock of Redisson.
Preferably, the database is synchronized with the Redis cache, and specifically comprises the following steps:
Storing the transaction flow log into a database;
The balance fund pool variable CAPITALAMT is updated based on the transaction flow log in the database.
Preferably, the method further comprises the following steps:
The transaction record flow is stored and warehoused through the MQ.
Preferably, the pre-service processing includes user verification.
Preferably, the balance fund pool variable CAPITALAMT, the consumption fund pool variable BalanceAmt, and the transaction record flowing water are all maintained in a Redis cache.
Preferably, the transaction record pipeline is stored in a Redis cache in a List mode.
Preferably, the initial value of the consumed funds pool variable BalanceAmt is 0 or a preset amount of funds already consumed.
The invention also provides a public credit management system, comprising:
an acquisition module for acquiring a balance fund pool variable CAPITALAMT and a consumption fund pool variable BalanceAmt;
the transaction module is used for acquiring a deduction request transaction;
the front-end service processing module is used for carrying out front-end service processing on the deduction request transaction;
The transaction record running water generating module is used for generating transaction record running water according to the deduction request transaction after the front-end service processing;
the deduction module is used for obtaining deduction amount from the transaction record running water and accumulating the deduction amount into the consumption fund pool variable BalanceAmt;
The judging module is used for judging whether the transaction is successful or not according to the balance fund pool variable CAPITALAMT and the consumption fund pool variable BalanceAmt;
The deduction module is used for performing deduction operation and generating a corresponding transaction flow log TradeRecord;
and a withdrawal module for performing a withdrawal request transaction and removing the corresponding deduction amount from the consumption funds pool variable BalanceAmt.
Compared with the prior art, the invention has the beneficial effects that:
the invention makes profound researches on the high concurrency deduction and similar business scenes, and aims at the age that all the business scenes can be informationized, how to process the special high concurrency business scenes is a subject which needs to be solved. The high-concurrency deduction module adopts a new design concept, and can ensure the lock-free processing of the whole-process business and the relative safety of data in high-concurrency deduction or similar business scenes in some specific environments. Meanwhile, a transaction flow backtracking mechanism is utilized, and a reconstruction and protection mechanism is realized when the service crashes.
Drawings
The following describes the embodiments of the present invention in further detail with reference to the accompanying drawings.
FIG. 1 is a flow chart of a method of credit management in accordance with the present invention.
Detailed Description
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention may be embodied in many other forms than those herein described, and those skilled in the art will readily appreciate that the present invention may be similarly embodied without departing from the spirit or essential characteristics thereof, and therefore the present invention is not limited to the specific embodiments disclosed below.
The terminology used in the one or more embodiments of the specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of the specification. As used in this specification, one or more embodiments and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used in one or more embodiments of the present specification refers to and encompasses any or all possible combinations of one or more of the associated listed items.
It should be understood that, although the terms first, second, etc. may be used in one or more embodiments of this specification to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, a first may also be referred to as a second, and similarly, a second may also be referred to as a first, without departing from the scope of one or more embodiments of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "in response to a determination" depending on the context.
The invention is described in further detail below with reference to the attached drawing figures:
The invention provides a public credit management method, which comprises the following steps:
obtaining a balance fund pool variable CAPITALAMT and a consumption fund pool variable BalanceAmt;
Acquiring a deduction request transaction;
Front-end business processing is carried out on the deduction request transaction;
Generating transaction record running water according to the deduction request transaction after the front-end service processing;
obtaining a deduction amount from the transaction record running water, and accumulating the deduction amount into a consumption fund pool variable BalanceAmt;
judging whether the transaction is successful or not according to the balance fund pool variable CAPITALAMT and the consumption fund pool variable BalanceAmt;
if the transaction is successful, deducting money and generating a corresponding transaction flow log TradeRecord;
If the transaction fails, a withdraw deduction request transaction is performed and the corresponding deduction amount is removed from the consumed funds pool variable BalanceAmt.
Preferably, the method further comprises the following steps:
judging whether a database summarizing operation needs to be executed or not according to the transaction flow log and a preset transaction number threshold;
If the database summarizing operation is required to be executed, locking operation is carried out;
and synchronizing the database with the Redis cache, and performing unlocking operation.
Preferably, the distributed locking and unlocking operations are implemented according to RLock of Redisson.
Preferably, the database is synchronized with the Redis cache, and specifically comprises the following steps:
Storing the transaction flow log into a database;
The balance fund pool variable CAPITALAMT is updated based on the transaction flow log in the database.
Preferably, the method further comprises the following steps:
The transaction record flow is stored and warehoused through the MQ.
Preferably, the pre-service processing includes user verification.
Preferably, the balance fund pool variable CAPITALAMT, the consumption fund pool variable BalanceAmt, and the transaction record flowing water are all maintained in a Redis cache.
Preferably, the transaction record pipeline is stored in a Redis cache in a List mode.
Preferably, the initial value of the consumed funds pool variable BalanceAmt is 0 or a preset amount of funds already consumed.
The invention also provides a public credit management system, comprising:
an acquisition module for acquiring a balance fund pool variable CAPITALAMT and a consumption fund pool variable BalanceAmt;
the transaction module is used for acquiring a deduction request transaction;
the front-end service processing module is used for carrying out front-end service processing on the deduction request transaction;
The transaction record running water generating module is used for generating transaction record running water according to the deduction request transaction after the front-end service processing;
the deduction module is used for obtaining deduction amount from the transaction record running water and accumulating the deduction amount into the consumption fund pool variable BalanceAmt;
The judging module is used for judging whether the transaction is successful or not according to the balance fund pool variable CAPITALAMT and the consumption fund pool variable BalanceAmt;
The deduction module is used for performing deduction operation and generating a corresponding transaction flow log TradeRecord;
and a withdrawal module for performing a withdrawal request transaction and removing the corresponding deduction amount from the consumption funds pool variable BalanceAmt.
In order to better illustrate the technical effects of the present invention, the present invention provides the following specific embodiments to illustrate the above technical flow:
Embodiment 1, the high concurrency amount deduction service component of the present invention realizes the principle:
The high concurrency amount deduction component (sm@nblncc) mainly utilizes some characteristics in the deduction scene to operate:
1. Under normal business conditions, the amount in the balance fund pool is far greater than the deduction amount requested by the user, except that the user may have a real demand for acquiring the balance amount in real time.
2. Because the balance amount changes from time to time in a high concurrency scenario, the user's requirement for consistency in obtaining the balance amount does not need to be as accurate as possible,
3. The deduction result of the amount is based on the final result of the database, so that the final consistency of the service needs to be ensured.
Therefore, the practical demand targets of the business scenes are utilized, and if the final consistency of the amount data is ensured, and the business data can be traced and inquired, the practical demands of customers and systems can be met.
The component technically mainly uses the distributed cache technology of Redis to realize global data consistency and business processing. Mainly, the characteristics of Redis, such as high performance, distributed support and thread security, are utilized to accomplish the desired functions. The implementation principle and the technical scheme of the component can be explained as follows:
The business flow of the deduction component is shown in the following chart, the business execution flow is shown in fig. 1, and the business execution flow comprises the following steps:
1. When the system is initialized, a balance fund pool variable is generated in the Redis cache according to service requirements and recorded as CAPITALAMT for all service nodes to use. And generating a consumption fund pool variable for storing the deduction request amount applied by the summarized user, marking as BalanceAmt, initializing as 0, or presetting a consumed fund amount.
2. The user initiates a deduction request transaction, and the server receives the request and performs pre-business processing (e.g., user verification, etc. of other business services).
3. Generating transaction record running water according to transaction information initiated by a user, storing the transaction record running water in a Redis, and recording in a List mode.
4. The deduction amount in the transaction information is obtained and accumulated into our BalanceAmt variable.
5. The current BalanceAmt and CAPITALAMT variables are compared. When BalanceAmt total is less than CAPITALAMT, the transaction is considered successful. And otherwise, the transaction fails.
6. And updating the transaction log stream according to the judgment result of the last step. If the transaction is successful, the result is directly returned, and the post-processing of the transaction is performed. If the transaction fails, a transaction withdrawal operation needs to be performed, and the deduction balance of the transaction needs to be deducted from BalanceAmt.
7. The transaction pipeline is stored in warehouse via the MQ or other means.
The above is the business deduction flow. From the flow, the deduction process is a whole-course locking-free operation,
And the key business data and the comparison operation are saved in a mode of minimizing the performance consumption by utilizing the characteristics of Redis, and the related flow of the database IO basically does not exist. Because in normal business, the situation that the fund pool is larger than the deduction amount accounts for the majority, a large number of useless query-comparison-modification operations are avoided, and the load cost of the server is reduced.
However, we just complete the deduction flow, and the data persistence work needs to be completed. In the component, the data persistence supports timing disk brushing or realizes database-Redis synchronization according to two forms of threshold summarization.
The timing brushing disc needs to be supported by a distributed scheduling system, and data existing in a cache is collected for each period of time (500 milliseconds or 1 second and the like) by using a timing operation mode, so that the database is updated and synchronized with the cached data. The maximum transaction number is set in advance according to the total number threshold, and when the transaction number recorded in Redis exceeds the maximum transaction number, the system executes the same brushing process.
We will show this persistence operation by way of example of a quantity threshold summary. Redis is utilized to make a distributed lock to ensure data consistency of each service node. The Redis framework is implemented by adopting Redisson as a technology, and the following operations are performed by the program:
1. Performing deduction operation of the user according to the deduction flow, and generating a corresponding transaction flow log: tradeRecord.
2. When the transaction flow log exceeds the threshold (1000 in this example) we set, a database summary operation is performed.
3. Distributed locking operations are implemented with RLock of Redisson.
4. After the secondary confirmation transaction record is still larger than the threshold value, the synchronous operation of the database and the cache is realized by executing a capitalPoolservice. AsyncAmtPool () method. With the help of the Redis lock, this operation is an atomic operation at one time.
5. After the operation is completed, the lock is released.
The specific implementation of the capitalPoolservice. AsyncAmtPool method comprises the following steps:
1. The batch is stored in warehouse according to the acquired transaction records, and the available balance data is updated (in the case of large concurrency and large performance pressure, the asynchronous processing can be realized by using the MQ).
2. And obtaining the latest balance data (the consumption amount summarized by the transaction records is deducted) in the database and updating the latest balance data into the cache.
3. The data in the consumption fund pool deducts the consumption amount which is already summarized.
Wherein, the balance change source in the above operation should be limited to the user deduction transaction condition involved in the service. If other sources of variation are involved, the protection scheme for the balance margin in the synchronization process time difference needs to be considered.
High concurrency limit deduction component (Sm@NBLNCC) feature arrangement:
1) The component is applicable to certain specific service scenes: the fund pool is free or less free of change requests from other sources; the fund pool is far greater than the deduction amount for most of the time; the concurrency is extremely large, and the service allows the final consistency of data;
2) The deduction flow is lock-free in the whole process, no blockage exists in a high concurrency scene, and the Redis characteristic is utilized to ensure thread safety, data reading speed and global data consistency.
3) In most of the scenes, no deduction overflow exists, so that the business process is simplified in practice.
4) Transaction running water can be refreshed at any time or periodically, so that business post accounting or traceability operation is facilitated. When the system crashes or is down, the service can be helped to reconstruct data.
5) The database dependence is reduced, the persistent layer technology is decoupled, the bottom layer is convenient to design according to the technical architecture model, and the persistent design can be carried out according to the actual situation of the database splitting table or NOSQL storage technology.
6) Different business scenes can be specifically designed according to actual business conditions, such as different scenes of transaction large-screen real-time tracking, data abstraction evolution and the like.
7) Further optimizations may be made based on business characteristics, e.g., the pipelining of transactions is an immutable object, and Reative responsive interaction mode may be implemented using Redisson framework to further increase business throughput.
8) In practical project development, in order to prevent the deduction compensation from repeatedly occurring after the balance is too low, a switch can be set for the balance fund pool, and when the fund pool limit is lower than the threshold value, the conventional inquiry-comparison-modification mode is switched.
The test result is a test result under the specific resource environment and service scene of the local machine, and the actual deployment is different.
The test scene simulates actual business occurrence, a user requests to call and initiate a deduction request through an API, and each request is different in 1000-10000. The process includes receiving service request, recording transaction flow, front-end service operation, back-end service operation, etc. The system will count the time it takes after all the services are completed.
In practical application, the upper layer of the transaction is also used for realizing responsive development WebFlux, and the business throughput of the background is also increased to a certain extent.
The traditional mode is the three-section type of query-comparison-modification, and the writing mode after the modification is the writing mode after using components and other supporting facilities.
It can be seen that the throughput and throughput improvement of traffic is very significant. Moreover, due to the increase of the concurrent traffic amount, the traditional mode has obvious time-consuming extension due to resource blockage, and the modified component is not affected by the time-consuming extension, so that if the data synchronization operation frequency is reduced, the data synchronization operation frequency can be further improved.
And the end result is consistent.
In the several embodiments provided by the present invention, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the above-described apparatus embodiments are merely illustrative, and the division of modules, or units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units, modules, or components may be combined or integrated into another apparatus, or some features may be omitted, or not performed.
The units may or may not be physically separate, and the components shown as units may be one physical unit or a plurality of physical units, may be located in one place, or may be distributed in a plurality of different places. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.
In addition, each functional unit in the embodiments of the present invention may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.
In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flowcharts. In such embodiments, the computer program may be downloaded and installed from a network via a communication portion, and/or installed from a removable medium. The above-described functions defined in the method of the present invention are performed when the computer program is executed by a Central Processing Unit (CPU). The computer readable medium of the present invention may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the above.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The foregoing is merely illustrative of specific embodiments of the present invention, and the scope of the present invention is not limited thereto, but any changes or substitutions within the technical scope of the present invention should be covered by the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims (10)

1. A method of managing credit to a public, comprising the steps of:
obtaining a balance fund pool variable CAPITALAMT and a consumption fund pool variable BalanceAmt;
Acquiring a deduction request transaction;
Front-end business processing is carried out on the deduction request transaction;
Generating transaction record running water according to the deduction request transaction after the front-end service processing;
obtaining a deduction amount from the transaction record running water, and accumulating the deduction amount into a consumption fund pool variable BalanceAmt;
judging whether the transaction is successful or not according to the balance fund pool variable CAPITALAMT and the consumption fund pool variable BalanceAmt;
if the transaction is successful, deducting money and generating a corresponding transaction flow log TradeRecord;
If the transaction fails, a withdraw deduction request transaction is performed and the corresponding deduction amount is removed from the consumed funds pool variable BalanceAmt.
2. The method for managing public credit according to claim 1, further comprising the steps of:
judging whether a database summarizing operation needs to be executed or not according to the transaction flow log and a preset transaction number threshold;
If the database summarizing operation is required to be executed, locking operation is carried out;
and synchronizing the database with the Redis cache, and performing unlocking operation.
3. The method for public credit management according to claim 2, wherein:
the distributed locking and unlocking operations are implemented according to RLock of Redisson.
4. A method of managing credit to public as set forth in claim 3 wherein the database is synchronized with the dis cache, comprising the steps of:
Storing the transaction flow log into a database;
The balance fund pool variable CAPITALAMT is updated based on the transaction flow log in the database.
5. The method for managing public credit according to claim 1, further comprising the steps of:
The transaction record flow is stored and warehoused through the MQ.
6. The method for public credit management according to claim 1, wherein:
The pre-service processing includes user verification.
7. The method for public credit management according to claim 1, wherein:
The balance fund pool variable CAPITALAMT, the consumption fund pool variable BalanceAmt, and the transaction record flowing water are all stored in the Redis cache.
8. The method for public credit management according to claim 1, wherein:
The transaction record pipelining is stored in a Redis cache in a List mode.
9. The method for public credit management according to claim 1, wherein:
the initial value of the consumption fund pool variable BalanceAmt is 0 or a preset fund limit which is already consumed.
10. A pair of credit management systems for implementing the pair of credit management methods of any of claims 1-9, comprising:
an acquisition module for acquiring a balance fund pool variable CAPITALAMT and a consumption fund pool variable BalanceAmt;
the transaction module is used for acquiring a deduction request transaction;
the front-end service processing module is used for carrying out front-end service processing on the deduction request transaction;
The transaction record running water generating module is used for generating transaction record running water according to the deduction request transaction after the front-end service processing;
the deduction module is used for obtaining deduction amount from the transaction record running water and accumulating the deduction amount into the consumption fund pool variable BalanceAmt;
The judging module is used for judging whether the transaction is successful or not according to the balance fund pool variable CAPITALAMT and the consumption fund pool variable BalanceAmt;
The deduction module is used for performing deduction operation and generating a corresponding transaction flow log TradeRecord;
and a withdrawal module for performing a withdrawal request transaction and removing the corresponding deduction amount from the consumption funds pool variable BalanceAmt.
CN202410157678.4A 2024-02-04 2024-02-04 Method and system for managing public credit Pending CN118134491A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202410157678.4A CN118134491A (en) 2024-02-04 2024-02-04 Method and system for managing public credit

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202410157678.4A CN118134491A (en) 2024-02-04 2024-02-04 Method and system for managing public credit

Publications (1)

Publication Number Publication Date
CN118134491A true CN118134491A (en) 2024-06-04

Family

ID=91236618

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202410157678.4A Pending CN118134491A (en) 2024-02-04 2024-02-04 Method and system for managing public credit

Country Status (1)

Country Link
CN (1) CN118134491A (en)

Similar Documents

Publication Publication Date Title
US9092475B2 (en) Database log parallelization
JP5660693B2 (en) Hybrid OLTP and OLAP high performance database system
US11386065B2 (en) Database concurrency control through hash-bucket latching
US8209699B2 (en) System and method for subunit operations in a database
US9069704B2 (en) Database log replay parallelization
US6446086B1 (en) System and method for logging transaction records in a computer system
US20150205850A1 (en) Eager replication of uncommitted transactions
US20110055151A1 (en) Processing Database Operation Requests
US20130117241A1 (en) Shadow Paging Based Log Segment Directory
CN101350022B (en) Changing process method based on database logical lock
US20200310925A1 (en) Test continuous log replay
US11144536B2 (en) Systems and methods for real-time analytics detection for a transaction utilizing synchronously updated statistical aggregation data
US10503752B2 (en) Delta replication
Dey et al. Scalable distributed transactions across heterogeneous stores
US11099960B2 (en) Dynamically adjusting statistics collection time in a database management system
US20090100434A1 (en) Transaction management
US9965355B2 (en) System and method for dynamic collection of system management data in a mainframe computing environment
US8719315B2 (en) Representation of business object in analytical application by combining replicated, analytical, and locally enriched data
US7412465B2 (en) Method for append mode insertion of rows into tables in database management systems
CN118134491A (en) Method and system for managing public credit
CN112035503B (en) Transaction data updating method and device
CN109447777B (en) Financial data processing method and device, electronic equipment and readable medium
CN113391933A (en) Method for processing fund
Fan et al. Scalable transaction processing using functors
JPH10232809A (en) Transaction processing system

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