Transaction request processing method, electronic device, medium and computer program product

Abstract

The invention provides a transaction request processing method, electronic equipment, a medium and a computer program product, and relates to the technical field of data processing. The method comprises the steps of obtaining a first memory utilization rate of a service to which a payment transaction platform belongs in a previous historical time period of a current moment; if the first memory usage rate is greater than a preset memory threshold within the preset time, determining a corresponding memory reduction target amplitude based on the first memory usage rate; the memory reduction target amplitude represents the memory utilization rate required to be reduced by the service to which the payment transaction platform belongs; and generating a request rejection strategy based on the memory reduction target amplitude, and performing rejection processing on the transaction request received in the first time period in the future from the current moment by using the request rejection strategy. According to the application, the request rejection strategy is generated based on the memory for reducing the target amplitude to reject the request received in a period of time in the future, so that the stability of a payment transaction platform is improved, and the stability of transaction request processing is improved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a transaction request processing method, electronic equipment, medium and computer program product. Background Art

[0002] With the development of Internet technology, various payment methods have emerged. In payment scenarios, payment platform services usually connect to multiple payment channels, such as WeChat, Alipay, and Cloud QuickPass. Since the resources used by payment platform services are limited, if one of the payment channels has a problem, it will continue to occupy the resources of the payment platform service, affecting the use of other payment channels, thereby affecting the use of the entire payment transaction platform, resulting in low stability in transaction request processing. Summary of the invention

[0003] The purpose of the embodiments of the present application is to provide a transaction request processing method, electronic device, medium and computer program product, which are used to generate a request rejection strategy based on the memory usage rate of the service where the payment transaction platform is located, and after the memory usage rate reaches a certain threshold, reject the requests received in a future period of time, so as to improve the stability of the payment transaction platform, thereby improving the stability of transaction request processing.

[0004] In a first aspect, an embodiment of the present application provides a transaction request processing method, the method comprising: obtaining a first memory usage rate of a service to which a payment transaction platform belongs within a previous historical time period at a current moment; if the first memory usage rate is greater than a preset memory threshold within a preset time, determining a corresponding memory reduction target amplitude based on the first memory usage rate; the memory reduction target amplitude indicates a memory usage rate that needs to be reduced by the service to which the payment transaction platform belongs; generating a request rejection strategy based on the memory reduction target amplitude, so as to use the request rejection strategy to reject transaction requests received in the first future time period from the current moment.

[0005] The embodiment of the present application determines a target memory reduction amplitude according to the memory usage rate in a historical time period, and generates a request rejection strategy based on the target memory reduction amplitude, so as to reject transaction requests in a future period of time according to the request rejection strategy, thereby improving the stability of the payment transaction platform and thus improving the stability of transaction request processing.

[0006] In some embodiments, generating a request rejection strategy based on a memory reduction target amplitude includes: determining the amount of threads to be released based on the memory reduction target amplitude; the amount of threads refers to the number of threads that have been occupied in a time period; determining the amount of threads to be used in the first future time period from the current moment based on the number of transaction requests in the previous historical time period and the average processing time of the transaction requests in the previous historical time period; generating a request rejection strategy based on the amount of threads to be released and the amount of threads to be used.

[0007] In the embodiment of the present application, since the amount of threads to be used is determined based on the number of transaction requests in the previous historical time period and the average processing time of the transaction requests, the amount of threads to be used indicates how many threads are required to work continuously in the first time period in the future to process the same number of transaction requests as in the previous historical time period. Based on this, the request rejection policy generated by combining the amount of threads to be released and the amount of threads to be used can more accurately control the requests for service, improve the stability of the payment transaction platform, and thus improve the stability of transaction request processing.

[0008] In some embodiments, determining the amount of threads to be released based on a memory reduction target amplitude includes: obtaining an initial memory usage rate and an initial number of active threads of a service to which a payment transaction platform belongs, as well as a second memory usage rate and a number of active threads of the service to which the payment transaction platform belongs at a current moment; calculating an average memory occupancy of each active thread based on the initial memory usage rate, the initial number of active threads, the second memory usage rate and the number of active threads; and determining the amount of threads to be released based on a maximum memory amount of the service to which the payment transaction platform belongs, an average memory occupancy of each active thread and a memory reduction target amplitude.

[0009] When calculating the average memory usage of each active thread, the embodiment of the present application takes into account the initial memory usage rate and the initial number of active threads when the service to which the payment transaction platform belongs is just started, thereby reducing the calculation error caused by the basic service thread and improving the calculation accuracy of the average memory usage of each active thread. On this basis, the accuracy of the final determined number of threads to be released is improved, thereby improving the stability of transaction request processing.

[0010] In some embodiments, a request rejection policy is generated based on the amount of threads to be released and the amount of threads to be used, including: determining the priority of each transaction request based on a preset transaction request priority configuration table; and generating a request rejection policy based on the priority of the transaction request, the amount of threads to be released, and the amount of threads to be used.

[0011] The embodiment of the present application takes into account that different types of transaction requests have different priorities, and avoids situations where indiscriminate rejection results in important requests not being processed. When generating a request rejection strategy, the priority of the transaction request is considered to reject transaction requests for a period of time in the future, thereby reducing the impact on high-priority transaction requests, thereby improving the stability of transaction request processing.

[0012] In some embodiments, a request rejection strategy is generated based on the priority of the transaction request, the amount of threads to be released, and the amount of threads to be used, including: calculating the rejection ratio of each type of transaction request based on the amount of threads to be released and the amount of threads to be used in order from low to high priority; and rejecting the transaction request based on the rejection ratio.

[0013] The embodiment of the present application further reduces the impact on high-priority transaction requests by calculating the rejection ratio of each type of transaction request in order of priority from low to high, thereby improving the stability of transaction request processing.

[0014] In some embodiments, the method further includes: determining a target rejection object based on the transaction request processing status in a previous historical time period before the current moment; accordingly, using a request rejection strategy to reject transaction requests received in the first future time period from the current moment, including: using a request rejection strategy to reject transaction requests received in the first future time period from the current moment of the target rejection object.

[0015] The embodiments of the present application also take into account that the reason for the increase in memory usage of the payment transaction platform may be due to an increase in the transaction volume of a certain transaction channel in the payment transaction platform, or it may be due to an increase in the transaction volume of the entire payment transaction platform. Therefore, when using a request rejection strategy to reject a transaction request, it is necessary to determine whether to reject the transaction request of a certain transaction channel or the transaction request of the entire payment transaction platform. Therefore, the target rejection object is determined by the transaction request processing situation in the previous historical time period at the current moment, thereby improving the stability of transaction request processing.

[0016] In some embodiments, the target rejection object is determined based on the transaction request processing status in the previous historical time period at the current moment, including: obtaining the number of active threads of each transaction channel in the payment transaction platform at the current moment, the average processing time of transaction requests in the previous historical time period at the current moment, and the average processing time of transaction requests in the preset time period before the previous historical time period; if there is a transaction channel with a current number of active threads greater than a first preset thread number threshold, the transaction channel is taken as a target rejection object; if the total number of active threads of each transaction channel at the current moment is not less than a second preset thread number threshold, and the average processing time is neither less than the first preset time threshold nor less than a preset multiple of the average processing time of transaction requests in the preset time period before the previous historical time period, the service to which the payment transaction platform belongs is taken as a target rejection object.

[0017] The embodiment of the present application determines the target rejection object based on the historical data in the previous historical time period before the current moment to more accurately predict future development trends and potential problems, thereby making more informed decisions and improving the stability of transaction request processing.

[0018] In a second aspect, an embodiment of the present application provides a transaction request processing device, which includes: an acquisition module, used to obtain a first memory usage rate of a service to a payment transaction platform in a previous historical time period before the current moment; a determination module, used to determine a corresponding memory reduction target amplitude based on the first memory usage rate if the first memory usage rate is greater than a preset memory threshold within a preset time; the memory reduction target amplitude indicates the memory usage rate that needs to be reduced by the service to the payment transaction platform; a generation module, used to generate a request rejection strategy based on the memory reduction target amplitude, so as to use the request rejection strategy to reject transaction requests received in the first time period in the future from the current moment.

[0019] In a third aspect, an embodiment of the present application provides an electronic device, comprising: a processor, a memory, a storage medium and a bus, wherein the processor and the memory communicate with each other through the bus; the memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute the method steps of the first aspect.

[0020] In a fourth aspect, an embodiment of the present application provides a non-transitory computer-readable storage medium, comprising: the computer-readable storage medium stores computer instructions, and the computer instructions enable the computer to execute the method steps of the first aspect.

[0021] In a fifth aspect, an embodiment of the present application provides a computer program product, including: a computer program, which executes the method steps of the first aspect when executed by a processor.

[0022] Other features and advantages of the present application will be described in the subsequent description, and in part will become apparent from the description, or will be understood by implementing the embodiments of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0024] Figure 1 A flowchart of a transaction request processing method provided in an embodiment of the present application;

[0025] Figure 2 A schematic diagram of the structure of a transaction request processing device provided in an embodiment of the present application;

[0026] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0027] The following embodiments of the technical solution of the present application are described in detail in conjunction with the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present application, and are therefore only used as examples, and cannot be used to limit the scope of protection of the present application.

[0028] It should be noted that all technical and scientific terms used in this document have the same meanings as those generally understood by technicians in the technical field to which this application belongs; the terms used in this document are only for the purpose of describing specific embodiments and are not intended to limit this application; the terms "including" and "having" in the specification and claims of this application and the above-mentioned figure descriptions and any variations thereof are intended to cover non-exclusive inclusions.

[0029] In the description of the embodiments of the present application, the technical terms "first", "second", etc. are only used to distinguish different objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number, specific order or primary and secondary relationship of the indicated technical features. In the description of the embodiments of the present application, the meaning of "multiple" is more than two, unless otherwise clearly and specifically defined.

[0030] With the development of Internet technology, various payment methods have emerged. In payment scenarios, payment transaction platform services usually connect to multiple transaction channels, and each transaction channel connects to a payment service, such as WeChat, Alipay, and Cloud QuickPass. Due to the limited resources used by payment platform services, the payment transaction platform may have a high memory usage rate for a short period of time, which affects the use of the entire payment transaction platform and leads to low stability in transaction request processing.

[0031] The reasons for the above problems include the following:

[0032] 1. Payment trading platforms usually connect to multiple trading channels. If a service provider system of a trading channel has problems, it will cause the transaction to be unresponsive or respond too slowly for a long time. At this time, the request of the trading channel will be blocked on the payment trading platform, waiting for the service of the trading channel to respond. In this process, since each transaction request in the payment trading platform will occupy a thread to process, the thread will not be released for the next transaction request until the transaction request is processed. The number of threads in the payment trading platform is fixed, so the request blocking will cause a large number of threads to be blocked and wait, causing thread resources and memory resources to be exhausted, thus affecting the transaction processing of other trading channels.

[0033] 2. The upstream of the payment transaction platform initiates a large number of requests, making it impossible for the payment transaction platform to process them in a timely manner.

[0034] Based on the above problems, the present application provides a transaction request processing method, which is used to start from the memory usage rate of the service where the payment transaction platform is located. After the memory usage rate reaches a certain threshold, a request rejection strategy is generated to reject requests received in a future period of time, so as to improve the stability of the payment transaction platform and thus improve the stability of transaction request processing.

[0035] Figure 1 A flowchart of a transaction request processing method provided in an embodiment of the present application. It is understandable that the method can be applied to a terminal device (also referred to as an electronic device) and a server; wherein the terminal device can specifically be a smart phone, a tablet computer, a computer, a personal digital assistant (PDA), etc.; the server can specifically be an application server or a Web server. To facilitate understanding of the technical solution provided in the embodiment of the present application, the application scenario of the transaction request processing method provided in the embodiment of the present application is introduced below, taking the server as the execution subject as an example.

[0036] like Figure 1 As shown, the method includes:

[0037] Step S101: The server obtains a first memory usage rate of a service to which a payment transaction platform belongs in a previous historical time period at a current moment.

[0038] The length of a time period is a preset value, such as: every 15 minutes is a time period, or every 20 minutes is a time period. The length of a specific time period can be set according to actual conditions.

[0039] The previous historical time period before the current moment refers to the first historical time period starting from the current moment. For example, if 15 minutes is a time period and the current moment is 14:00, then 13:45-14:00 is the previous historical time period before the current moment.

[0040] The first memory usage rate=(used memory / maximum available memory)*100%, wherein the maximum available memory refers to the maximum available memory of the service to which the payment transaction platform belongs, and the used memory refers to the real-time memory usage of the service to which the payment transaction platform belongs. The first memory utility rate is determined by the used memory and the maximum available memory.

[0041] The server obtains the memory usage of the payment transaction platform service in real time, and calculates the memory usage rate in real time based on the maximum available memory of the payment transaction platform service, and stores it. When you need to obtain the memory usage rate for a certain period of time, you can use java.lang.management.MemoryMXBean and java.lang.management.MemoryUsage to obtain it.

[0042] The first memory usage rate is a memory usage rate for a time period, which includes multiple values. The multiple values ​​refer to the memory usage rate corresponding to each time point in a time period. The division of time points is specifically set according to actual conditions, such as: every minute in a time period is a time point, or every second in a time period is a time point.

[0043] Step S102, if the first memory usage is greater than the preset memory threshold within the preset time, the server determines the corresponding memory reduction target amplitude based on the first memory usage; the memory reduction target amplitude represents the memory usage that needs to be reduced by the service of the payment transaction platform.

[0044] Step S103, the server generates a request rejection strategy based on the memory reduction target amplitude, so as to use the request rejection strategy to reject the transaction request received in the first time period in the future from the current moment.

[0045] For example, if each 15 minutes is a time period and the current time is 14:00, then 14:00-14:15 is the first time period in the future from the current time.

[0046] During the execution process, the server determines whether it is necessary to generate a request rejection policy through a memory usage degradation decision table, where the memory usage degradation decision table is pre-designed for developers and the table logic is integrated into the code.

[0047] In order to prevent instantaneous traffic from frequently triggering the generation of request rejection policies, set "duration" to determine whether the trigger condition is met. That is, if the first memory usage rate is greater than the preset memory threshold within the preset time, the server determines the corresponding memory reduction target amplitude based on the first memory usage rate, and generates a request rejection policy based on the memory reduction target amplitude.

[0048] The preset time is a preset value configured in the memory usage degradation decision table. The preset memory threshold is also a preset value configured in the memory usage degradation decision table.

[0049] Table 1 is a memory usage degradation decision table provided by an embodiment of the present application. As shown in Table 1, if the first memory usage in the previous historical time period of the current moment is always [0%-70%), the memory reduction target amplitude is 0; if the first memory usage in the previous historical time period of the current moment is [70%-80%), and the duration is 15 minutes, the memory reduction target amplitude is 5%, that is, the first memory usage in the first time period in the future from the current moment is [65%-75%); if the first memory usage in the previous historical time period of the current moment is [80%-90%), and the duration is 5 minutes, The target amplitude of memory reduction is 20%, that is, the first memory usage rate of the first time period in the future from the current moment is [60%-70%); if the first memory usage rate in the previous historical time period of the current moment is [90%-95%), and the duration is 1 minute, the target amplitude of memory reduction is 30%, that is, the first memory usage rate of the first time period in the future from the current moment is [60%-65%); if the first memory usage rate in the previous historical time period of the current moment is greater than or equal to 95%, it means that the service is already seriously overloaded, and there is no need to judge its duration, and the target amplitude of memory reduction is 30%. Therefore, as the memory usage rate increases, the duration gradually shortens. This method can prevent the problem of service crash caused by memory overflow to a certain extent.

[0050] Table 1

[0051] Memory usage Duration Memory reduction target amplitude 0％-70％ none 0 70％-80％ 15min 5％ 80％-90％ 5min 20％ 90％-95％ 1min 30％ 95％-100％ none 30％

[0052] It should be noted that the data shown in Table 1 is pre-set by combining the historical memory usage of the services of the payment transaction platform, and is continuously optimized and refined according to the subsequent service operation conditions.

[0053] The embodiment of the present application determines a target memory reduction amplitude according to the memory usage rate in a historical time period, and generates a request rejection strategy based on the target memory reduction amplitude, so as to reject transaction requests in a future period of time according to the request rejection strategy, thereby improving the stability of the payment transaction platform and thus improving the stability of transaction request processing.

[0054] In some embodiments, the server generates a request rejection strategy based on a memory reduction target amplitude, including: the server determines the amount of threads to be released based on the memory reduction target amplitude; the server determines the amount of threads to be used in the first future time period from the current moment based on the number of transaction requests in the previous historical time period and the average processing time of the transaction requests in the previous historical time period; the server generates a request rejection strategy based on the amount of threads to be released and the amount of threads to be used.

[0055] The thread volume refers to the number of threads that are always occupied in a time period.

[0056] Therefore, the amount of threads to be released refers to the number of threads that have been in an idle state in the first time period in the future from the current moment of the service to which the payment transaction platform belongs, if the reduced memory usage rate is to reach the target memory reduction amplitude.

[0057] Since the memory reduction target amplitude indicates the memory usage rate that needs to be reduced by the services of the payment transaction platform, and processing requests through threads will increase the memory usage rate, the amount of threads to be released is determined by the memory reduction target amplitude. In this way, it can be known how many threads need to be idle in order to prevent the memory usage rate from being too high in the first time period in the future from the current moment, that is, these threads are not used to process requests.

[0058] For example, if the first memory usage rate in the previous historical time period at the current moment is [70%-80%) and the duration is 15 minutes, the memory reduction target amplitude is determined to be 5%. At this time, the amount of threads to be released in the first future time period at the current moment is determined based on 5%.

[0059] In one implementation, a fixed amount of threads to be released is determined for each memory reduction target amplitude. When the server determines the amount of threads to be released based on the memory reduction target amplitude, it directly reads the corresponding amount of threads to be released based on the memory reduction target amplitude.

[0060] Optionally, the server determines the amount of threads to be released based on the memory reduction target amplitude, including: the server obtains the initial memory usage rate and the initial number of active threads of the service to which the payment transaction platform belongs, and the second memory usage rate and the number of active threads of the service to which the payment transaction platform belongs at the current moment; the server calculates the average memory occupancy of each active thread based on the initial memory usage rate, the initial number of active threads, the second memory usage rate and the number of active threads; the server determines the amount of threads to be released based on the maximum memory amount of the service to which the payment transaction platform belongs, the average memory usage of each active thread and the memory reduction target amplitude.

[0061] The initial memory usage rate refers to the memory usage rate of the payment transaction platform service when it is just started.

[0062] The number of initial active threads refers to the number of threads used when the payment transaction platform service is just started. Active threads refer to threads that are currently being used.

[0063] The server calculates the average memory usage of each active thread based on the obtained initial memory usage, initial number of active threads, second memory usage, and number of active threads. The formula is as follows:

[0064]

[0065] Among them, M t Indicates the average memory usage of each active thread, M init represents the initial memory usage, T init Indicates the initial number of active threads, M cur Indicates the second memory usage, T cur Indicates the number of active threads at the current moment.

[0066] The average memory usage of each active thread is calculated by considering the initial memory usage rate and the initial number of active threads when the service to which the payment transaction platform belongs is just started, which reduces the calculation error caused by the basic service thread and improves the calculation accuracy of the average memory usage of each active thread.

[0067] Finally, the server determines the number of threads to be released based on the maximum memory of the service to which the payment transaction platform belongs, the average memory usage of each active thread, and the target amplitude of memory reduction. The formula is as follows:

[0068]

[0069] Among them, T sub Indicates the number of threads to be released, M max Indicates the maximum amount of memory, R m Indicates the target amplitude of memory reduction.

[0070] Since it is unclear how many transaction requests the payment transaction platform will receive in the first time period starting from the current moment, the number of transaction requests in the previous historical time period before the current moment is used as the number of transaction requests in the first time period in the future to predict the amount of threads required for the first time period in the future.

[0071] Specifically, the server determines the number of threads to be used in the first future time period from the current moment according to the number of transaction requests in the previous historical time period and the average processing time of the transaction requests in the previous historical time period. The calculation formula is as follows:

[0072]

[0073] Among them, T use Indicates the number of threads to be used in the first time period from the current moment, C 一个时间周期 Indicates the number of transaction requests in the previous historical time period, D avg Indicates the average processing time of transaction requests in the previous historical time period (unit: milliseconds (ms)). 60000 means 60000 milliseconds, that is, 1 minute. If every 15 minutes is a time period, the length of a time period is 15 minutes. If every 20 minutes is a time period, the length of a time period is 20 minutes.

[0074] The amount of threads to be used refers to the number of threads required for the payment transaction platform service to continuously process the same number of transaction requests as in the previous historical time period before the current moment in the first time period in the future from the current moment.

[0075] For example, as shown in Table 2, for transaction requests for customer certificate information query, the number of transaction requests in the previous historical time period is 1500, the average processing time of transaction requests in the previous historical time period is 3000 milliseconds, and the length of a time period is 15 minutes. Therefore, according to the above formula, Therefore, the number of threads required in the first time period in the future from the current moment is 5, that is, 5 threads are required to process continuously in the first time period in the future from the current moment to complete the processing of 1500 transaction requests.

[0076] Table 2 is a transaction request parameter table provided in an embodiment of the present application. As shown in Table 2, the transaction name may also be referred to as the transaction request type. Different types of transaction requests have different priorities, and the transaction request processing conditions in the previous historical time period are also different, so that different types of transaction requests have different thread quantities to be used in the first time period in the future.

[0077] Table 2

[0078]

[0079]

[0080] After obtaining the amount of threads to be released and the amount of threads to be used, the server generates a request rejection policy based on the amount of threads to be released and the amount of threads to be used.

[0081] Generate a request rejection strategy based on the number of threads to be released and the number of threads to be used, including: randomly selecting a transaction request type as the target transaction request type, and calculating the rejection ratio of the target transaction request type. The calculation formula for the rejection ratio is: Where k represents the rejection ratio, T sub Indicates the number of threads to be released, T use Indicates the number of threads required for the target transaction request type in the first time period in the future from the current moment.

[0082] If T sub >T use , indicating that all target transaction requests need to be rejected in the first time period in the future. And the updated number of threads to be released is obtained by subtracting the number of threads required by the target transaction request type from the number of threads to be released, that is, T sub =T sub -T use .

[0083] Then randomly select the next transaction request type as the target transaction request type, and calculate the rejection ratio of the target transaction request type. If the number of threads required by the next target transaction request type in the first time period in the future from the current moment is still less than the updated number of threads to be released, then all target transaction requests need to be rejected in the first time period in the future, and the number of threads to be released will be updated again, and so on, until the updated number of threads to be released is 0, and the remaining other transaction requests are processed normally.

[0084] Optionally, the rejection ratio of the corresponding transaction request type can also be calculated based on the order of receiving transaction requests in the previous historical time period at the current moment. The calculation formula and calculation process of the rejection ratio can be found in the above embodiment and will not be repeated here.

[0085] In the embodiment of the present application, since the amount of threads to be used is determined based on the number of transaction requests in the previous historical time period and the average processing time of the transaction requests, the amount of threads to be used indicates how many threads are required to work continuously in the first time period in the future to process the same number of transaction requests as in the previous historical time period. Based on this, the request rejection policy generated by combining the amount of threads to be released and the amount of threads to be used can more accurately control the requests for service, improve the stability of the payment transaction platform, and thus improve the stability of transaction request processing.

[0086] In some embodiments, the server generates a request rejection policy based on the amount of threads to be released and the amount of threads to be used, including: the server determines the priority of each transaction request based on a preset transaction request priority configuration table; the server generates a request rejection policy based on the priority of the transaction request, the amount of threads to be released, and the amount of threads to be used.

[0087] During the execution process, some transaction requests are more important and need to be processed in a timely manner. Therefore, when rejecting transaction requests, they cannot be rejected indiscriminately.

[0088] Based on this, when generating a request rejection policy based on the amount of threads to be released and the amount of threads to be used, the priority of the transaction request also needs to be considered, that is, the server determines the priority of each transaction request based on a preset transaction request priority configuration table.

[0089] The transaction request priority configuration table is pre-set by the developer according to the characteristics of each type of transaction request. For details, please refer to the contents of the priority column shown in Table 2. As shown in Table 2, the transaction request type for customer certificate information query has a priority of 1, the transaction request type for transfer transaction has a priority of 8, the transaction request type for transfer transaction result query has a priority of 7, and the transaction request type for customer transaction record query has a priority of 1. The larger the value, the higher the priority.

[0090] Finally, the server generates a request rejection strategy based on the priority of the transaction request, the number of threads to be released, and the number of threads to be used, so that important transaction requests can be processed in a timely manner and only some unimportant transaction requests are rejected. This improves the stability of transaction request processing while also enhancing the user experience.

[0091] In some embodiments, the server generates a request rejection strategy based on the priority of the transaction request, the amount of threads to be released, and the amount of threads to be used, including: the server calculates the rejection ratio of each type of transaction request in order of priority from low to high, based on the amount of threads to be released and the amount of threads to be used; the server rejects the transaction request based on the rejection ratio.

[0092] Table 3 is a rejection ratio schematic table provided in an embodiment of the present application. As shown in Table 3, the rejection ratio of each type of transaction request is calculated according to the number of threads to be released and the number of threads to be used, in order of the priority of the transaction request from low to high.

[0093] In this process, since the number of threads to be released will not change after the calculation is completed, when calculating the rejection ratio according to the priority of transaction requests from low to high, the number of threads to be released is updated after each rejection ratio of a type of transaction request is calculated, that is, T sub =T sub -T use The rejection ratio of the corresponding type of transaction requests is calculated by the updated amount of threads to be released and the amount of threads to be used.

[0094] The calculation formula of the rejection ratio can be found in the above embodiment and will not be repeated here.

[0095] For example, if the number of threads to be released is 15, that is, T sub =15, for transaction requests for customer ID information query, its T use =5, since 5<15, the rejection ratio Since 300%>100%, all transaction requests for customer ID information query in the first time period in the future will be rejected. At this time, the number of threads to be released for update is T sub =15-5=10, transaction request for customer transaction record query, T use =7.333, since 7.333<10, we reject the proportion Since 136%>100%, all transaction requests for customer transaction record inquiries in the first time period in the future will be rejected. At this time, the number of threads to be released for update is T sub =10-7.333=2.667, transaction request for querying transfer transaction results, T use =5, since 5>2.667, we reject the proportion Therefore, in the first time period in the future, only 53% of the transaction requests for querying the transfer transaction results need to be rejected, and the remaining transaction requests for querying the transfer transaction results and transaction requests with higher priorities are processed normally.

[0096] Table 3

[0097]

[0098] The embodiment of the present application further reduces the impact on high-priority transaction requests by calculating the rejection ratio of each type of transaction request in order of priority from low to high, thereby improving the stability of transaction request processing.

[0099] In some embodiments, the method further includes: the server determines a target rejection object based on the transaction request processing situation in a previous historical time period at the current moment.

[0100] During the specific implementation process, it is considered that the reason for the increase in memory usage of the payment transaction platform may be caused by an increase in transaction volume of a certain transaction channel in the payment transaction platform, or by an increase in transaction volume of the entire payment transaction platform.

[0101] Therefore, when using the request rejection strategy to reject a transaction request, it is necessary to determine whether to reject the transaction request of a certain transaction channel or the transaction request of the entire payment transaction platform. Based on this, the target rejection object is determined by the transaction request processing situation in the previous historical time period at the current moment.

[0102] A transaction channel refers to a channel that connects the payment transaction platform service with an external payment service, including at least one of the WeChat channel, Alipay channel, and Cloud QuickPass channel. Each transaction channel is connected to a corresponding external payment service.

[0103] Therefore, the increase in transaction volume of a certain transaction channel makes it impossible for the corresponding external payment service to quickly process all transaction requests, causing the transaction requests to remain on the payment transaction platform, occupying the memory of the payment transaction platform, thereby affecting the use of the entire payment transaction platform.

[0104] The server determines the target rejection object based on the transaction request processing status in the previous historical time period at the current moment, including: obtaining the number of active threads of each transaction channel in the payment transaction platform at the current moment, the average processing time of transaction requests in the previous historical time period at the current moment, and the average processing time of transaction requests in a preset time period before the previous historical time period; if there is a transaction channel whose number of active threads at the current moment is greater than the first preset thread number threshold, the transaction channel will be taken as the target rejection object.

[0105] The first preset thread number threshold is determined by the average number of threads occupied by each transaction channel and the number of all transaction channels connected to the payment transaction platform, and is specifically calculated by the following formula:

[0106]

[0107] Among them, T max represents the first preset thread number threshold, T avg Indicates the average number of threads occupied by each transaction channel, C c Indicates the number of all transaction channels connected to the payment transaction platform.

[0108] The average number of threads occupied by each transaction channel Tavg Obtained by the following formula:

[0109]

[0110] Among them, N c Indicates the maximum number of threads that can be used by the payment transaction platform service. 0.85 indicates the normal usage ratio of threads.

[0111] It should be noted that since the maximum number of threads that can be used by the payment transaction platform service is fixed, and the number of all transaction channels connected to the payment transaction platform is also fixed when the payment transaction platform is developed and does not need to be upgraded, the first preset thread number threshold calculated is also fixed.

[0112] If the number of active threads of a transaction channel at the current moment is greater than the first preset thread number threshold, it indicates that the transaction channel is the cause of the increased memory usage, and the transaction channel is then targeted for rejection.

[0113] It should also be noted that, since the maximum number of threads that can be used by the payment transaction platform service is fixed, there will not be a situation where the number of active threads of multiple transaction channels at the current moment is greater than the first preset thread number threshold.

[0114] If the total number of active threads in each transaction channel at the current moment is not less than the second preset thread number threshold, and the average processing time is neither less than the first preset time threshold, nor less than the preset multiple of the average processing time of transaction requests in the preset time period before the previous historical time period, it indicates that the number of transaction requests sent from the upstream to the payment transaction platform has increased. At this time, the service to which the payment transaction platform belongs will be targeted for rejection, regardless of which transaction channel the transaction request belongs to.

[0115] The calculation formula is as follows:

[0116]

[0117] Among them, T cur Indicates the total number of active threads in each transaction channel at the current moment, D avg Indicates the average processing time of transaction requests in the previous historical time period, N c Indicates the maximum line that the payment transaction platform service can use

[0118] Range, D before Indicates the average processing time of transaction requests in the preset time period before the previous historical time period, N c×0.85 represents the first preset threshold, n represents the preset multiple, which can be 1.5 or 2, etc., and can be set according to actual conditions. 2000 represents the average response time of normal processing of transaction requests, in milliseconds (ms).

[0119] To prevent the time period from being too short and causing D before There is a large local mutation, so the preset time period is preset to a larger value, such as 1 hour, or 1.5 hours. For example, the preset time period is set to 1 hour. If every 15 minutes is a time period, then the historical 15 minutes from the current moment is the previous historical time period from the current moment. For example, if the current moment is 14:00, then 13:45-14:00 is the previous historical time period from the current moment, and 12:45-13:45 is the preset time period before the previous historical time period. Then D before Indicates the average processing time of transaction requests between 12:45-13:45.

[0120] Accordingly, the server uses the request rejection strategy to reject the transaction request received in the first time period in the future from the current moment, including: the server uses the request rejection strategy to reject the transaction request received in the first time period in the future from the current moment of the target rejection object.

[0121] The embodiment of the present application determines the target rejection object based on the historical data in the previous historical time period before the current moment to more accurately predict future development trends and potential problems, thereby making more informed decisions and improving the stability of transaction request processing.

[0122] Figure 2 A schematic diagram of a transaction request processing device provided in an embodiment of the present application is shown in FIG. Figure 2 As shown, the device includes: an acquisition module 201, a determination module 202 and a generation module 203; wherein,

[0123] The acquisition module 201 is used to obtain the first memory usage rate of the service to which the payment transaction platform belongs in the previous historical time period before the current moment; the determination module 202 is used to determine the corresponding memory reduction target amplitude based on the first memory usage rate if the first memory usage rate is greater than the preset memory threshold within the preset time; the memory reduction target amplitude represents the memory usage rate that needs to be reduced by the service to which the payment transaction platform belongs; the generation module 203 is used to generate a request rejection strategy based on the memory reduction target amplitude, so as to use the request rejection strategy to reject the transaction request received in the first time period in the future from the current moment.

[0124] Based on the above embodiment, the generation module 203 is specifically used to: determine the amount of threads to be released based on the memory reduction target amplitude; the amount of threads refers to the number of threads that have been occupied in a time period; determine the amount of threads to be used in the first time period in the future from the current moment based on the number of transaction requests in the previous historical time period and the average processing time of the transaction requests in the previous historical time period; generate a request rejection policy based on the amount of threads to be released and the amount of threads to be used.

[0125] Based on the above embodiment, the generation module 203 is specifically used to: obtain the initial memory usage rate and the initial number of active threads of the service to which the payment transaction platform belongs, as well as the second memory usage rate and the number of active threads of the service to which the payment transaction platform belongs at the current moment; calculate the average memory occupancy of each active thread based on the initial memory usage rate, the initial number of active threads, the second memory usage rate and the number of active threads; determine the amount of threads to be released based on the maximum memory amount of the service to which the payment transaction platform belongs, the average memory usage of each active thread and the target memory reduction amplitude.

[0126] Based on the above embodiment, the generation module 203 is specifically used to: determine the priority of each transaction request based on a preset transaction request priority configuration table; and generate a request rejection strategy according to the priority of the transaction request, the amount of threads to be released, and the amount of threads to be used.

[0127] Based on the above embodiment, the generation module 203 is specifically used to: calculate the rejection ratio of each type of transaction request according to the number of threads to be released and the number of threads to be used in order of priority from low to high; and reject the transaction request according to the rejection ratio.

[0128] Based on the above embodiment, the device also includes an object determination module, which is used to determine the target rejection object based on the transaction request processing status in the previous historical time period before the current moment; accordingly, the transaction requests received in the first future time period from the current moment are rejected using the request rejection strategy, including: using the request rejection strategy to reject the transaction requests received in the first future time period from the current moment of the target rejection object.

[0129] On the basis of the above embodiment, the object determination module is specifically used to: obtain the number of active threads of each transaction channel in the payment transaction platform at the current moment, the average processing time of transaction requests in the previous historical time period at the current moment, and the average processing time of transaction requests in the preset time period before the previous historical time period; if the number of active threads of a transaction channel at the current moment is greater than the first preset thread number threshold, the transaction channel is taken as a target rejection object; if the total number of active threads of each transaction channel at the current moment is not less than the second preset thread number threshold, and the average processing time is neither less than the first preset time threshold nor less than a preset multiple of the average processing time of transaction requests in the preset time period before the previous historical time period, the service to which the payment transaction platform belongs is taken as a target rejection object.

[0130] It should be understood that the device corresponds to the above-mentioned transaction request processing method embodiment and can execute the various steps involved in the above-mentioned method embodiment. The specific functions of the device can be found in the above description. To avoid repetition, the detailed description is appropriately omitted here. The device includes at least one software function module that can be stored in a memory in the form of software or firmware or fixed in the operating system (OS) of the device.

[0131] Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application, such as Figure 3 As shown, the electronic device includes a processor 301 (processor), a memory 302 (memory) and a bus 303; wherein the processor 301 and the memory 302 communicate with each other through the bus 303. The processor 301 is used to call the program instructions in the memory 302 to execute the methods provided by the above-mentioned method embodiments.

[0132] The processor 301 can be an integrated circuit chip with signal processing capabilities. The above-mentioned processor 301 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. It can implement or execute various methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc.

[0133] The memory 302 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable red-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, disk or optical disk.

[0134] This embodiment discloses a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes program instructions. When the program instructions are executed by a computer, the computer can execute the methods provided by the above-mentioned method embodiments.

[0135] This embodiment provides a non-transitory computer-readable storage medium, which stores computer instructions, and the computer instructions enable the computer to execute the methods provided by the above-mentioned method embodiments.

[0136] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0137] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0138] Furthermore, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0139] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A transaction request processing method, characterized in that: The method comprises: Obtain the first memory usage rate of the service to which the payment transaction platform belongs in the previous historical time period at the current moment; If the first memory usage rate is greater than a preset memory threshold within a preset time, determining a corresponding memory reduction target amplitude based on the first memory usage rate; the memory reduction target amplitude represents the memory usage rate that needs to be reduced by the service to which the payment transaction platform belongs; A request rejection strategy is generated based on the memory reduction target amplitude, so as to use the request rejection strategy to reject the transaction request received in the first time period in the future from the current moment.

2. The method according to claim 1, characterized in that The generating a request rejection strategy based on the memory reduction target amplitude includes: Determining the amount of threads to be released based on the target amplitude of memory reduction; the amount of threads refers to the number of threads that have been occupied within a time period; Determine the amount of threads to be used in the first future time period from the current moment according to the number of transaction requests in the previous historical time period and the average processing time of the transaction requests in the previous historical time period; A request rejection policy is generated based on the amount of threads to be released and the amount of threads to be used.

3. The method according to claim 2, characterized in that The determining the amount of threads to be released based on the memory reduction target amplitude includes: Obtaining an initial memory usage rate and an initial number of active threads of the service to which the payment transaction platform belongs, as well as a second memory usage rate and a number of active threads of the service to which the payment transaction platform belongs at the current moment; Calculate the average memory usage of each active thread based on the initial memory usage, the initial number of active threads, the second memory usage and the number of active threads; The amount of threads to be released is determined according to the maximum memory amount of the service to which the payment transaction platform belongs, the average memory occupancy of each active thread, and the target amplitude of memory reduction.

4. The method according to claim 2, characterized in that: The generating a request rejection strategy based on the amount of threads to be released and the amount of threads to be used includes: Determine the priority of each transaction request based on a preset transaction request priority configuration table; A request rejection policy is generated according to the priority of the transaction request, the amount of threads to be released, and the amount of threads to be used.

5. The method according to claim 4, characterized in that The generating of the request rejection strategy according to the priority of the transaction request, the amount of threads to be released, and the amount of threads to be used includes: Calculate the rejection ratio of each type of transaction request according to the amount of threads to be released and the amount of threads to be used in order of priority from low to high; The transaction request is rejected according to the rejection ratio.

6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: Determine the target rejection object based on the transaction request processing status in the previous historical time period of the current moment; Accordingly, the use of the request rejection strategy to reject the transaction request received in the first time period after the current moment includes: The request rejection strategy is used to reject the transaction requests received within the first time period in the future from the current moment of the target rejection object.

7. The method according to claim 6, characterized in that The determining of the target rejection object based on the transaction request processing situation in the previous historical time period of the current moment includes: Obtaining the number of active threads of each transaction channel in the payment transaction platform at the current moment, the average processing time of transaction requests in a previous historical time period at the current moment, and the average processing time of transaction requests in a preset time period before the previous historical time period; If the number of active threads of a transaction channel at the current moment is greater than a first preset thread number threshold, the transaction channel is taken as a target rejection object; If the total number of active threads of each transaction channel at the current moment is not less than the second preset thread number threshold, and the average processing time is neither less than the first preset time threshold nor less than a preset multiple of the average processing time of transaction requests within the preset time period before the previous historical time period, the service to which the payment transaction platform belongs will be targeted for rejection.

8. An electronic device, characterized in that: include: A processor and a memory, wherein the memory stores machine-readable instructions executable by the processor, and when the machine-readable instructions are executed by the processor, the method according to any one of claims 1 to 7 is performed.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the method according to any one of claims 1 to 7 is executed.

10. A computer program product, characterized in that include: Computer program instructions, when executed by a processor, perform the method according to any one of claims 1 to 7.

Images