Data processing method and device, equipment, storage medium and product

Abstract

The invention discloses a data processing method and device, equipment, a storage medium and a product, and relates to the technical field of data processing, and the method comprises the steps: recognizing a payment traffic scene of a target system through a preset traffic detection algorithm; if the payment flow scene is a high-concurrency scene, asynchronous queue accumulation is carried out on payment transaction limit information of the payment flow scene according to a debit limit asynchronous processing strategy and a pre-generated asynchronous queue, and an asynchronous queue accumulation result is obtained; based on the asynchronous queue accumulation result and a preset asynchronous summarizing strategy, payment transaction limit information summarizing of the payment flow scene is carried out, the payment flow scene of the target merchant system is identified through the scheme, then asynchronous queue accumulation is carried out on payment transaction data in a high-concurrency scene, and the payment transaction limit information summarizing efficiency is improved. The timeliness is far better than that of a timed task polling mode, and the occupied database resources are smaller, so that the merchant payment limit data processing efficiency in a high-concurrency scene is remarkably improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a data processing method, device, equipment, storage medium and product. Background Art

[0002] In the field of acquiring payment, fund settlement usually adopts the netting settlement method, that is, the merchant's transaction on T day must wait until T+1 day to settle the funds to the merchant, rather than real-time entry of each transaction. In order to ensure the safety of funds settled by the bank at the end of the day and avoid the risk of short payment, it is necessary to ensure that the merchant's daily debit limit (collection limit) is greater than the credit limit (payment limit). The current common practice is to accumulate the merchant's debit limit online after the payment is successful.

[0003] However, with the rapid development of mobile payments, especially during promotional activities, the number of concurrent payments faced by a single merchant has increased dramatically. In this high-concurrency payment environment, the practice of online accumulation of merchant debit limits will lead to database hot spots, that is, a large number of requests are concentrated on the same data point, causing performance bottlenecks. To solve this problem, the industry usually adopts two solutions: one is to use caching technologies such as Redis, and the other is to split sub-accounts. However, both solutions have obvious defects. Although using Redis can increase processing speed, data consistency is difficult to ensure; and the solution of splitting sub-accounts requires the system to add additional sub-control records and regularly summarize these records, which not only leads to poor timeliness of main limit accumulation, but also actual concurrent performance is limited by the number of configured sub-control records, lacking flexibility. These defects limit the efficiency and reliability of existing technologies in handling high-concurrency payment scenarios.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of this application is to provide a data processing method, device, equipment, storage medium and computer program product, aiming to improve the efficiency of merchant payment amount data processing in high concurrency scenarios.

[0006] To achieve the above purpose, the present application proposes a data processing method, which includes:

[0007] Identify the payment traffic scenario of the target system through the preset traffic detection algorithm;

[0008] If the payment traffic scenario is a high-concurrency scenario, then according to the debit limit asynchronous processing strategy and the pre-generated asynchronous queue, the payment transaction limit information of the payment traffic scenario is asynchronously queued and accumulated to obtain an asynchronous queue accumulation result;

[0009] Based on the asynchronous queue accumulation results and the preset asynchronous aggregation strategy, the payment transaction amount information of the payment traffic scenario is aggregated.

[0010] In one embodiment, the step of identifying the payment traffic scenario of the target system by using a preset traffic detection algorithm includes:

[0011] Acquire preset sampling period information, wherein the sampling period information includes a time period slice;

[0012] Acquire the number of periodic payment requests of several target merchant systems according to the time period slice;

[0013] generating a merchant historical traffic baseline based on the number of payment requests in the period;

[0014] The payment traffic scenario of the target merchant system is identified according to the merchant historical traffic baseline.

[0015] In one embodiment, if the payment traffic scenario is a high-concurrency scenario, the payment transaction amount information of the payment traffic scenario is asynchronously queued and accumulated according to the debit limit asynchronous processing strategy and the pre-generated asynchronous queue, and the step of obtaining the asynchronous queue accumulation result includes:

[0016] If the payment traffic scenario is a high-concurrency scenario, an asynchronous cumulative quota instruction is generated;

[0017] In response to the asynchronous cumulative limit instruction, obtaining payment transaction limit information of the target merchant;

[0018] The payment transaction amount information is synchronized to a pre-generated asynchronous queue for asynchronous queue accumulation to obtain an asynchronous queue accumulation result.

[0019] In one embodiment, the step of aggregating the payment transaction amount information of the payment traffic scenario based on the asynchronous queue accumulation result and the preset asynchronous aggregation strategy includes:

[0020] In response to the asynchronous cumulative quota instruction, determining whether the standby time of the asynchronous queue exceeds a preset processing interval; and / or,

[0021] In response to the asynchronous cumulative quota instruction, determining whether the queue capacity of the asynchronous queue exceeds a preset queue specification;

[0022] If the standby time of the asynchronous queue exceeds the processing interval, or the queue capacity of the asynchronous queue exceeds the queue specification, the accumulated results of the asynchronous queue are batch-written into a preset amount accumulation anti-duplicate table, and the debit amount information corresponding to the target merchant is updated.

[0023] In one embodiment, after the step of identifying the payment traffic scenario of the target system by using a preset traffic detection algorithm, the step further includes:

[0024] If the payment traffic scenario is a non-high-concurrency scenario, obtaining the payment transaction amount information of the target merchant;

[0025] Based on the payment transaction limit information, the debit limit information of the target merchant is updated in real time.

[0026] In one embodiment, the sampling period information further includes a real-time sampling period, and the step of identifying the payment traffic scenario of the target merchant system according to the merchant historical traffic baseline includes:

[0027] Obtaining the number of real-time periodic payment requests of the target merchant systems within the real-time sampling period;

[0028] Calculate the payment request change rate of the target merchant systems within the real-time sampling period according to the number of payment requests in the real-time period;

[0029] If the number of payment requests in the real-time period is greater than a preset payment request number threshold, a high concurrency scenario is identified; or,

[0030] If the payment request change rate is greater than a preset change rate threshold, a high concurrency scenario is identified.

[0031] In addition, to achieve the above-mentioned purpose, the present application also proposes a data processing device, the data processing device comprising:

[0032] An identification module, used to identify the payment traffic scenario of the target system through a preset traffic detection algorithm;

[0033] An accumulation module, for performing asynchronous queue accumulation on the payment transaction amount information of the payment flow scenario according to the debit limit asynchronous processing strategy and the pre-generated asynchronous queue if the payment flow scenario is a high-concurrency scenario, to obtain an asynchronous queue accumulation result;

[0034] The aggregation module is used to aggregate the payment transaction amount information of the payment traffic scenario based on the asynchronous queue accumulation result and the preset asynchronous aggregation strategy.

[0035] In addition, to achieve the above objectives, the present application also proposes a data processing device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the data processing method described above.

[0036] In addition, to achieve the above objectives, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the data processing method described above are implemented.

[0037] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the data processing method described above are implemented.

[0038] One or more technical solutions proposed in the present application identify the payment traffic scenario of the target system through a preset traffic detection algorithm; if the payment traffic scenario is a high-concurrency scenario, then according to the debit limit asynchronous processing strategy and the pre-generated asynchronous queue, the payment transaction limit information of the payment traffic scenario is asynchronously queued and accumulated to obtain an asynchronous queue accumulation result; based on the asynchronous queue accumulation result and the preset asynchronous aggregation strategy, the payment transaction limit information of the payment traffic scenario is aggregated, and the payment traffic scenario of the target merchant system is identified through the above-mentioned solution, and then the payment transaction data in the high-concurrency scenario is asynchronously queued and accumulated. Through asynchronous tasks, the limit accumulation is completed directly in the memory in quasi-real time, and the timeliness is much better than the scheduled task polling method, and the database resources are also smaller, thereby significantly improving the merchant payment limit data processing efficiency in high-concurrency scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0040] In order to more clearly illustrate the embodiments of the present application 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. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0041] Figure 1 A flowchart of the first embodiment of the data processing method of the present application is provided;

[0042] Figure 2 This is a schematic diagram of asynchronous processing in high-concurrency scenarios for the data processing method of this application;

[0043] Figure 3 A flowchart of the second embodiment of the data processing method of this application is provided;

[0044] Figure 4 This is a schematic diagram of the asynchronous aggregation of accumulated quota flow for this application data processing method;

[0045] Figure 5 This is a schematic diagram of the module structure of the data processing device according to an embodiment of the present application;

[0046] Figure 6 Schematic diagram of the device structure of the hardware operating environment involved in the data processing method in the embodiment of the present application.

[0047] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0048] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0049] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0050] The main solution of the embodiment of the present application is to propose an asynchronous quasi-real-time merchant debit limit accumulation scheme based on application instances and databases. The scheme monitors and predicts the concurrent payment of merchants in real time through the application layer traffic algorithm, and avoids the occurrence of database hotspot contention in advance. At the same time, the lock mechanism of the database layer is used as a bottom-up means to perceive high-concurrency payment scenarios and form double protection. The scheme supports active switching of the limit accumulation strategy in high-concurrency scenarios, effectively solving the database hotspot problem of merchant debit limit accumulation. In non-high-concurrency payment scenarios, the system will immediately accumulate the debit limit online to ensure the timeliness of the limit change. In high-concurrency scenarios, the system will adopt an asynchronous processing strategy to quickly batch accumulate merchant debit limits through hotspot-free asynchronous queues in memory, thereby ensuring the stability of the system and solving the database hotspot problem. The asynchronous task on the server side will determine whether to perform the summary accumulation immediately based on the configured processing interval and queue size. After the total amount of batch records is accumulated in memory, the asynchronous task will write the processed records in batches to the amount accumulation anti-duplicate table in the same database transaction, and actually accumulate the merchant's debit amount to ensure data consistency. Finally, the asynchronous accumulation results are notified to the caller in batches through the message queue. This method avoids additional sub-control record configuration, reduces database resource usage, improves concurrency performance, and maintains data consistency and processing efficiency.

[0051] In the prior art, in a high-concurrency payment environment, the practice of online accumulation of merchant debit limits will lead to database hot spots, that is, a large number of requests are concentrated on the same data point, causing performance bottlenecks. In order to solve this problem, the industry usually adopts two solutions: one is to use caching technology such as Redis, and the other is to split sub-accounts. However, both solutions have obvious defects. Although the use of Redis can increase the processing speed, data consistency is difficult to ensure; and the solution of splitting sub-accounts requires the system to add additional sub-control records and regularly summarize these records, which not only leads to poor timeliness of the main limit accumulation, but also the actual concurrent performance is limited by the number of configured sub-control records, lacking flexibility. These defects limit the efficiency and reliability of the prior art in handling high-concurrency payment scenarios.

[0052] The present application provides a solution, which identifies the payment traffic scenario of the target system through a preset traffic detection algorithm; if the payment traffic scenario is a high-concurrency scenario, then according to the debit limit asynchronous processing strategy and the pre-generated asynchronous queue, the payment transaction limit information of the payment traffic scenario is asynchronously queued and accumulated to obtain an asynchronous queue accumulation result; based on the asynchronous queue accumulation result and the preset asynchronous aggregation strategy, the payment transaction limit information of the payment traffic scenario is aggregated, and the payment traffic scenario of the target merchant system is identified through the above scheme, and then the payment transaction data in the high-concurrency scenario is asynchronously queued and accumulated, which has much better timeliness than the scheduled task polling method, and occupies less database resources, thereby significantly improving the merchant payment limit data processing efficiency in the high-concurrency scenario.

[0053] It should be noted that the execution subject of this embodiment may be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a data processing system, etc. The following takes a data processing system as an example to illustrate this embodiment and the following embodiments.

[0054] Based on this, the present application embodiment provides a data processing method, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the data processing method of the present application.

[0055] In this embodiment, the data processing method includes steps S1000 to S4000:

[0056] Step S1000: Identify the payment traffic scenario of the target system through a preset traffic detection algorithm;

[0057] It should be noted that in this embodiment, in order to solve the database hotspot problem of accumulating merchant debit limits in the case of high concurrent payments, a data processing method is proposed in this embodiment, which can be referred to Figure 2 , Figure 2 This is a schematic diagram of asynchronous processing in high-concurrency scenarios for the data processing method of this application. Overall, the application layer uses a traffic monitoring algorithm to identify or predict whether the merchant is in a high-concurrency payment state. If the application layer does not perceive that the merchant is in a high-concurrency state, the database layer will use the nowait lock competition to protect the high-concurrency scenario. Once confirmed, the system will execute the asynchronous memory summary cumulative debit limit strategy to improve processing efficiency and system stability. The entire process is protected by both the application layer and the database layer, which achieves effective control of high-concurrency payment scenarios and ensures fund security and system performance. If it is not a high-concurrency payment state, the system will execute an online cumulative debit limit strategy, write a single anti-duplicate record in the transaction processing, and update the merchant's debit limit to ensure timeliness.

[0058] Specifically, first, this embodiment identifies the payment traffic scenario of the target system through a preset traffic detection algorithm, and this step is the basis of the entire solution. The system first obtains the preset sampling period information, which includes a time period slice, which is the time interval for counting merchant payment requests. In each time period slice, the system collects and counts the number of payment requests from each target merchant system. These data are then used to generate a merchant's historical traffic baseline, which is a benchmark established based on past data for comparing the current payment request volume. Based on the historical traffic baseline, the system can identify the current payment traffic scenario and determine whether it is a high-concurrency scenario. The purpose of this step is to monitor the merchant's payment request volume in real time and compare it with historical data, so as to predict possible high-concurrency situations.

[0059] In addition, it should be noted that the purpose of this step is to monitor the merchant's payment request volume in real time and compare it with historical data, so as to predict possible high concurrency situations. In this way, the system can react in advance and adopt corresponding processing strategies to avoid the occurrence of database hot spots.

[0060] For example, in a specific implementation, the system may set a 5-minute time period and count the number of payment requests from merchants in each period. If the number of payment requests from a merchant exceeds the historical average in several consecutive periods, the system will identify it as a high-concurrency scenario and prepare to adopt a corresponding asynchronous processing strategy.

[0061] Step S2000: If the payment traffic scenario is a high-concurrency scenario, asynchronous queue accumulation is performed on the payment transaction amount information of the payment traffic scenario according to the debit limit asynchronous processing strategy and the pre-generated asynchronous queue to obtain an asynchronous queue accumulation result;

[0062] It should be noted that if the payment traffic scenario is identified as a high-concurrency scenario, the system will perform asynchronous queue accumulation of payment transaction limit information based on the debit limit asynchronous processing strategy and the pre-generated asynchronous queue. The key to this step is to generate an asynchronous cumulative limit instruction, which triggers the system to obtain the payment transaction limit information of the target merchant and synchronize it to the pre-generated asynchronous queue. In the asynchronous queue, these payment transaction limit information will be accumulated to obtain the asynchronous queue accumulation result. The purpose of this step is to reduce the real-time processing pressure of the database and improve the system's processing power and efficiency through asynchronous processing.

[0063] In addition, it should be noted that asynchronous queue accumulation is an effective method to process a large amount of payment transaction information without affecting the online transaction response time. This method temporarily stores data in a queue in memory and processes it in batches at the appropriate time, thereby reducing the number of direct accesses to the database and reducing the database load.

[0064] For example, in a specific implementation, when the system identifies a sudden surge in the number of payment requests from a merchant, it will immediately initiate an asynchronous cumulative limit instruction. At this time, all relevant payment transaction limit information will be collected and placed in a pre-set asynchronous queue, which will be accumulated according to the set rules (such as time interval or queue size).

[0065] Step S3000: Based on the asynchronous queue accumulation result and the preset asynchronous aggregation strategy, the payment transaction amount information of the payment traffic scenario is aggregated.

[0066] It should be noted that based on the asynchronous queue accumulation results and the preset asynchronous aggregation strategy, the system will summarize the payment transaction limit information. This step involves responding to the asynchronous cumulative limit instruction and determining whether the standby time of the asynchronous queue exceeds the preset processing interval, or whether the queue capacity exceeds the preset queue specification. Once these conditions are met, the system will batch write the asynchronous queue accumulation results into the preset limit accumulation anti-duplicate table and update the corresponding debit limit information of the target merchant. The purpose of this step is to ensure that in high-concurrency scenarios, the merchant's debit limit information can be updated in a timely and accurate manner while ensuring data consistency.

[0067] In addition, it should be noted that in this way, the system can ensure the accuracy and consistency of data while ensuring efficiency. This method avoids frequent direct access to the database under high concurrency conditions, thereby reducing the burden on the database and improving the stability and reliability of the overall system.

[0068] For example, in a specific implementation, the system may set a 2-second processing interval and a queue size of 100. When the number of records in the asynchronous queue reaches 100, or the queue standby time exceeds 2 seconds, the system will perform a summary operation. This includes writing the accumulated results to the credit limit accumulation anti-duplicate table and updating the merchant's debit limit information, thereby completing the entire asynchronous processing flow.

[0069] In a feasible implementation manner, step S1000 may include steps S1100 to S1300:

[0070] Step S1100: obtaining preset sampling period information, wherein the sampling period information includes a time period slice;

[0071] Step S1200: obtaining the number of periodic payment requests of several target merchant systems according to the time period slice;

[0072] Step S1300: generating a merchant historical traffic baseline based on the number of periodic payment requests;

[0073] Step S1400: Identify the payment traffic scenario of the target merchant system according to the merchant historical traffic baseline.

[0074] It should be noted that in this embodiment, by obtaining preset sampling period information, which includes time period slices, the periodic statistics of payment requests of the target merchant system are realized. In each time period slice, the system collects and counts the number of payment requests of each target merchant, and these data are then used to generate the merchant's historical traffic baseline. The historical traffic baseline is a reference standard established based on past payment data to identify whether the current payment traffic meets the characteristics of a high-concurrency scenario.

[0075] In addition, it should be noted that by comparing the number of payment requests in the current cycle with the historical traffic baseline, the system can determine whether the target merchant is in a high-concurrency payment scenario. This judgment is based on the comparison of the absolute value of the number of payment requests or its rate of change with the preset threshold. If the current number of payment requests or its rate of change exceeds the preset threshold, the system will identify a high-concurrency scenario and adopt corresponding processing strategies accordingly.

[0076] For example, in a feasible implementation, the system may set a time cycle of 5 minutes and collect the merchant's payment request data in each cycle. By analyzing these data and comparing them with the historical traffic baseline, the system can monitor the merchant's concurrent payment in real time and trigger the asynchronous processing strategy when a high-concurrency scenario is detected. This strategy includes generating an asynchronous cumulative limit instruction, which prompts the system to obtain the payment transaction limit information of the target merchant and synchronize this information to a pre-generated asynchronous queue for cumulative processing. In a high-concurrency scenario, this asynchronous queue accumulation method can effectively reduce the database's real-time processing pressure and improve the system's efficiency and stability in handling a large number of payment transactions. At the same time, the system will also directly update the merchant's debit limit information online in non-high-concurrency scenarios to ensure the timeliness of the limit change. In this way, the system can flexibly respond to different payment traffic scenarios while ensuring data consistency, and achieve performance optimization of merchant limit management.

[0077] In a feasible implementation manner, the sampling period information further includes a real-time sampling period, and step S1400 may include steps S1410 to S1440:

[0078] Step S1410: obtaining the number of real-time periodic payment requests of the target merchant systems within the real-time sampling period;

[0079] Step S1420: Calculating the payment request change rate of the target merchant systems within the real-time sampling period according to the number of payment requests in the real-time period;

[0080] Step S1430: If the number of payment requests in the real-time period is greater than a preset payment request number threshold, a high concurrency scenario is identified; or,

[0081] Step S1440: If the payment request change rate is greater than a preset change rate threshold, a high concurrency scenario is identified.

[0082] It should be noted that in this embodiment, the system will obtain preset sampling cycle information, including not only fixed time period slices, but also real-time sampling cycles. The real-time sampling cycle allows the system to collect payment request data of target merchants in a very short time, so as to more accurately monitor the real-time changes in payment traffic. During the real-time sampling cycle, the system will count the number of payment requests of each target merchant and calculate the rate of change of payment requests based on these data. The results of these statistics and calculations will be used to generate the merchant's historical traffic baseline, which is a key reference for identifying high-concurrency scenarios.

[0083] In addition, it should be noted that the merchant's historical traffic baseline is obtained through the analysis of past payment data, which provides the system with a benchmark for judging whether the current payment traffic is abnormal. When the number of payment requests in the real-time cycle or the rate of change of payment requests exceeds the preset threshold, the system will identify a high-concurrency scenario. This real-time monitoring and prediction mechanism enables the system to adopt corresponding processing strategies before or at the beginning of a high-concurrency scenario, thereby effectively avoiding database hot spots and ensuring system stability and processing efficiency.

[0084] For example, in one feasible implementation, the system sets 1 minute as the real-time sampling period and collects payment request data from merchants during this period. Through real-time analysis of these data, the system can quickly determine whether a high-concurrency scenario has occurred. If the system detects that the number of payment requests from a merchant has suddenly increased sharply, or the rate of change of payment requests has increased abnormally, the system will immediately initiate an asynchronous processing strategy. This includes generating asynchronous cumulative limit instructions, synchronizing payment transaction limit information to asynchronous queues, and performing batch processing at appropriate times. In this way, the system can flexibly respond to different payment traffic scenarios while ensuring data consistency, thereby optimizing the performance of merchant limit management.

[0085] This embodiment provides a data processing method, which identifies the payment traffic scenario of the target system through a preset traffic detection algorithm; if the payment traffic scenario is a high-concurrency scenario, then according to the debit limit asynchronous processing strategy and the pre-generated asynchronous queue, the payment transaction limit information of the payment traffic scenario is asynchronously queued and accumulated to obtain an asynchronous queue accumulation result; based on the asynchronous queue accumulation result and the preset asynchronous aggregation strategy, the payment transaction limit information of the payment traffic scenario is aggregated, and the payment traffic scenario of the target merchant system is identified through the above scheme, and then the payment transaction data in the high-concurrency scenario is asynchronously queued and accumulated. Through asynchronous tasks, the limit accumulation is completed directly in the memory in quasi-real time, and the timeliness is much better than the scheduled task polling method, and the database resources are also smaller, thereby significantly improving the merchant payment limit data processing efficiency in high-concurrency scenarios.

[0086] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 3 , step S2000 of the data processing method further includes steps S2100 to S2300:

[0087] Step S2100: if the payment traffic scenario is a high-concurrency scenario, an asynchronous cumulative quota instruction is generated;

[0088] Step S2200: Responding to the asynchronous cumulative limit instruction, obtaining payment transaction limit information of the target merchant;

[0089] Step S2300: Synchronize the payment transaction amount information to a pre-generated asynchronous queue for asynchronous queue accumulation to obtain an asynchronous queue accumulation result.

[0090] It should be noted that when the system identifies a high-concurrency payment scenario through a traffic detection algorithm, an asynchronous cumulative limit instruction will be generated. This instruction is the key to triggering the subsequent processing flow. It instructs the system to enter asynchronous processing mode to cope with a large number of payment transactions under high concurrency. In response to the asynchronous cumulative limit instruction, the system will obtain the payment transaction limit information of the target merchant, which includes but is not limited to key data such as transaction amount and transaction time. Subsequently, the system synchronizes these payment transaction limit information to the pre-generated asynchronous queue for asynchronous queue accumulation. This process is performed in memory, avoiding frequent direct access to the database, thereby reducing the database load and potential lock contention problems.

[0091] In addition, it should be noted that the accumulated results of the asynchronous queue will be used for subsequent payment transaction limit information aggregation. The system will determine whether the standby time or queue capacity of the asynchronous queue has reached the preset threshold based on the preset asynchronous aggregation strategy. Once these conditions are met, the system will perform an aggregation operation, write the accumulated results in the asynchronous queue into the limit accumulation anti-duplicate table in batches, and update the debit limit information of the target merchant. This strategy ensures that in high-concurrency scenarios, the system can efficiently and accurately process the merchant's debit limit updates while maintaining data consistency and system stability.

[0092] For example, in one feasible implementation, the system sets specific thresholds to identify high-concurrency scenarios, such as a sudden increase in the number of payment requests or an abnormally high rate of change. When these situations are detected, the system immediately generates an asynchronous cumulative limit instruction, starts collecting payment transaction limit information from relevant merchants, and puts it into an asynchronous queue for cumulative processing. In this way, the system can effectively manage high-concurrency payment scenarios, ensure the smooth progress of payment transactions, and avoid excessive consumption of database resources. This asynchronous processing mechanism not only improves the system's processing capabilities, but also improves the user experience, because users can complete payment operations faster without having to worry about system delays or failures due to high concurrency.

[0093] In a feasible implementation manner, step S3000 may include steps S3100 to S3300:

[0094] Step S3100: In response to the asynchronous cumulative quota instruction, determining whether the standby time of the asynchronous queue exceeds a preset processing interval; and / or,

[0095] Step S3200: In response to the asynchronous cumulative quota instruction, determining whether the queue capacity of the asynchronous queue exceeds a preset queue specification;

[0096] Step S3300: If the standby time of the asynchronous queue exceeds the processing interval, or the queue capacity of the asynchronous queue exceeds the queue specification, the accumulated results of the asynchronous queue are batch-written into a preset credit limit accumulation anti-duplicate table, and the debit limit information corresponding to the target merchant is updated.

[0097] It should be noted that in this solution, in order to ensure that the system can effectively manage and update the merchant's debit limit information in a high-concurrency scenario, the system will respond to the asynchronous cumulative limit instruction and monitor the standby time and queue capacity of the asynchronous queue. These two parameters are preset to determine when to perform the aggregation operation. The standby time refers to the length of time the data in the asynchronous queue waits for processing, while the queue capacity refers to the amount of data that can be stored in the queue. When the standby time of the asynchronous queue exceeds the preset processing interval, or the queue capacity exceeds the preset specification, the system will batch write the accumulated results in the asynchronous queue into the preset quota accumulation anti-duplicate table, and update the corresponding debit limit information of the target merchant. This process not only improves the efficiency of data processing, but also ensures the consistency and accuracy of the data through the anti-duplicate table.

[0098] In addition, it should be noted that the credit amount accumulation anti-duplicate table is a special database table used to record the credit amount accumulation information that has been processed to prevent duplicate processing and potential data errors. In this way, the system can improve processing speed and system performance while ensuring data accuracy. This design avoids the hot data contention problem that may occur in traditional methods, and also reduces the occupation of database resources.

[0099] Reference Figure 4 , Figure 4 This is a schematic diagram of the asynchronous summary and accumulation of credit limit flow of the data processing method of this application. After receiving the asynchronous accumulation credit limit instruction, the server-side asynchronous task in this embodiment will judge whether to perform the summary and accumulation immediately based on the processing interval (configurable) and the queue size (configurable). For example, if the configuration parameters are 2 seconds and 100 items, then when the asynchronous queue standby time exceeds 2 seconds or the capacity exceeds 100 items, the asynchronous task will take out the data in the queue, first accumulate the total amount of batch records in the memory, and write the processed records in batches to the credit limit accumulation anti-duplicate table in the same transaction (reuse the online credit limit accumulation anti-duplicate table to realize the idempotent processing function, not introduced separately), and actually accumulate the merchant's debit limit at the same time to ensure transaction consistency. Finally, the asynchronous accumulation results are notified to the caller in batches through the message queue.

[0100] Database transactions are used to write anti-duplicate records and complete credit limit accumulation, ensuring the consistency of credit limit accumulation data; asynchronous tasks are accumulated in memory, and then the merchant debit limit is accumulated separately. Compared with the online accumulation of merchant debit limits one by one, it effectively reduces the row lock contention problem, and does not introduce additional sub-control records.

[0101] For example, in a feasible implementation, the system may set the standby time of the asynchronous queue to 2 seconds and the queue capacity to 100 records. When any condition is triggered, the system will perform a summary operation, write the accumulated results in the asynchronous queue to the credit limit cumulative anti-duplicate table, and update the merchant's debit limit. This setting enables the system to respond to demands in high-concurrency scenarios in a timely manner while maintaining efficient processing, ensuring performance optimization of merchant credit limit management. In this way, the system can better adapt to different payment traffic scenarios, and can ensure accurate and timely updates of merchant debit limits regardless of high or non-high concurrency.

[0102] In a feasible implementation manner, step S1000 further includes steps S1500 to S1600:

[0103] Step S1500: If the payment traffic scenario is a non-high-concurrency scenario, obtaining the payment transaction amount information of the target merchant;

[0104] Step S1600: Based on the payment transaction limit information, the debit limit information of the target merchant is updated in real time.

[0105] It should be noted that in this solution, the processing of non-high-concurrency scenarios is equally important, which ensures the flexibility and efficiency of the system under different traffic conditions. When the system determines that the payment traffic scenario is non-high-concurrency through the traffic detection algorithm, it will directly obtain the payment transaction limit information of the target merchant and update the merchant's debit limit in real time based on this information. The purpose of this step is to ensure that under normal or low traffic conditions, the system can respond quickly and update the limit information in a timely manner to support the normal operation and transaction processing of merchants.

[0106] In addition, it should be noted that real-time updating of debit limit information is essential to maintaining the smoothness of the system and user experience. In non-high-concurrency scenarios, since the number of requests is relatively low and system resources are sufficient, online update operations can be performed directly without the need for asynchronous processing strategies. This can reduce system latency, increase transaction processing speed, and avoid data consistency issues that may be caused by asynchronous processing.

[0107] For example, in one feasible implementation, the system may set specific thresholds to distinguish between high-concurrency and non-high-concurrency scenarios. When the number of payment requests or the rate of change detected is lower than these thresholds, the system will enter the non-high-concurrency processing flow. In this process, the system will immediately obtain the merchant's payment transaction limit information and update its debit limit in real time. This design enables the system to adapt to different transaction environments, and can ensure accurate control of merchant limits and smooth transactions regardless of whether it is during peak or trough trading periods. In this way, the system not only improves processing efficiency, but also enhances its adaptability to different transaction scenarios, thereby providing merchants with more stable and reliable services.

[0108] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the data processing method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0109] Please refer to Figure 5 The present application also provides a data processing device, the data processing device comprising:

[0110] An identification module 51, used to identify the payment traffic scenario of the target system through a preset traffic detection algorithm;

[0111] The accumulation module 52 is used for, if the payment flow scenario is a high-concurrency scenario, performing asynchronous queue accumulation on the payment transaction amount information of the payment flow scenario according to the debit limit asynchronous processing strategy and the pre-generated asynchronous queue to obtain the asynchronous queue accumulation result;

[0112] The aggregation module 53 is used to aggregate the payment transaction amount information of the payment traffic scenario based on the asynchronous queue accumulation result and the preset asynchronous aggregation strategy.

[0113] The data processing device provided by the present application adopts the data processing method in the above embodiment to solve the technical problem of data processing. Compared with the prior art, the beneficial effects of the data processing device provided by the present application are the same as the beneficial effects of the data processing method provided by the above embodiment, and other technical features in the data processing device are the same as the features disclosed in the above embodiment method, which will not be described in detail here.

[0114] The present application provides a data processing device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the data processing method in the above-mentioned embodiment 1.

[0115] Reference below Figure 6, which shows a schematic diagram of the structure of a data processing device suitable for implementing an embodiment of the present application. The data processing device in the embodiment of the present application may include, but is not limited to, mobile terminals such as mobile phones, laptop computers, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 6 The data processing device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0116] like Figure 6 As shown, the data processing device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the data processing device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the data processing device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows a data processing device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0117] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0118] The data processing device provided in the present application adopts the data processing method in the above-mentioned embodiment. Compared with the prior art, the beneficial effects of the data processing device provided in the present application are the same as the beneficial effects of the data processing method provided in the above-mentioned embodiment, and other technical features in the data processing device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0119] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0120] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0121] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, wherein the computer-readable program instructions are used to execute the data processing method in the above-mentioned embodiment.

[0122] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0123] The computer-readable storage medium may be included in a data processing device, or may exist independently without being incorporated into a data processing device.

[0124] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0125] The flowcharts and block diagrams in the accompanying drawings illustrate the possible architecture, functions and operations of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of a code, and the module, a program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0126] The modules involved in the embodiments described in the present application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0127] The readable storage medium provided in the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned data processing method, and can solve the technical problems of data processing. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in the present application are the same as the beneficial effects of the data processing method provided in the above-mentioned embodiment, and will not be repeated here.

[0128] The present application also provides a computer program product, including a computer program, which implements the steps of the above-mentioned data processing method when executed by a processor.

[0129] The computer program product provided by this application can solve the technical problem of data processing. Compared with the prior art, the beneficial effects of the computer program product provided by this application are the same as the beneficial effects of the data processing method provided by the above embodiment, which will not be repeated here.

[0130] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A data processing method, characterized in that: The method comprises: Identify the payment traffic scenario of the target system through the preset traffic detection algorithm; If the payment traffic scenario is a high-concurrency scenario, then according to the debit limit asynchronous processing strategy and the pre-generated asynchronous queue, the payment transaction limit information of the payment traffic scenario is asynchronously queued and accumulated to obtain an asynchronous queue accumulation result; Based on the asynchronous queue accumulation results and the preset asynchronous aggregation strategy, the payment transaction amount information of the payment traffic scenario is aggregated.

2. The method according to claim 1, characterized in that The step of identifying the payment traffic scenario of the target system by using a preset traffic detection algorithm includes: Acquire preset sampling period information, wherein the sampling period information includes a time period slice; Acquire the number of periodic payment requests of several target merchant systems according to the time period slice; generating a merchant historical traffic baseline based on the number of payment requests in the period; The payment traffic scenario of the target merchant system is identified according to the merchant historical traffic baseline.

3. The method according to claim 1, characterized in that If the payment traffic scenario is a high-concurrency scenario, then according to the debit limit asynchronous processing strategy and the pre-generated asynchronous queue, the payment transaction limit information of the payment traffic scenario is asynchronously queued and accumulated to obtain the asynchronous queue accumulation result, the step includes: If the payment traffic scenario is a high-concurrency scenario, an asynchronous cumulative quota instruction is generated; In response to the asynchronous cumulative limit instruction, obtaining payment transaction limit information of the target merchant; The payment transaction amount information is synchronized to a pre-generated asynchronous queue for asynchronous queue accumulation to obtain an asynchronous queue accumulation result.

4. The method according to claim 3, characterized in that The step of aggregating the payment transaction amount information of the payment traffic scenario based on the asynchronous queue accumulation result and the preset asynchronous aggregation strategy includes: In response to the asynchronous cumulative quota instruction, determining whether the standby time of the asynchronous queue exceeds a preset processing interval; and / or, In response to the asynchronous cumulative quota instruction, determining whether the queue capacity of the asynchronous queue exceeds a preset queue specification; If the standby time of the asynchronous queue exceeds the processing interval, or the queue capacity of the asynchronous queue exceeds the queue specification, the accumulated results of the asynchronous queue are batch-written into a preset amount accumulation anti-duplicate table, and the debit amount information corresponding to the target merchant is updated.

5. The method according to claim 3, characterized in that After the step of identifying the payment traffic scenario of the target system by using a preset traffic detection algorithm, the method further includes: If the payment traffic scenario is a non-high-concurrency scenario, obtaining the payment transaction amount information of the target merchant; Based on the payment transaction limit information, the debit limit information of the target merchant is updated in real time.

6. The method according to claim 2, characterized in that The sampling period information also includes a real-time sampling period. The step of identifying the payment flow scenario of the target merchant system according to the merchant historical flow baseline includes: Obtaining the number of real-time periodic payment requests of the target merchant systems within the real-time sampling period; Calculate the payment request change rate of the target merchant systems within the real-time sampling period according to the number of payment requests in the real-time period; If the number of payment requests in the real-time period is greater than a preset payment request number threshold, a high concurrency scenario is identified; or, If the payment request change rate is greater than a preset change rate threshold, a high concurrency scenario is identified.

7. A data processing device, characterized in that: The device comprises: An identification module, used to identify the payment traffic scenario of the target system through a preset traffic detection algorithm; An accumulation module, for performing asynchronous queue accumulation on the payment transaction amount information of the payment flow scenario according to the debit limit asynchronous processing strategy and the pre-generated asynchronous queue if the payment flow scenario is a high-concurrency scenario, to obtain an asynchronous queue accumulation result; The aggregation module is used to aggregate the payment transaction amount information of the payment traffic scenario based on the asynchronous queue accumulation result and the preset asynchronous aggregation strategy.

8. A data processing device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the data processing method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the data processing method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the data processing method according to any one of claims 1 to 6 are implemented.

Images