Processing method, device and equipment for allocating resources to account

Abstract

The invention provides a processing method, device and equipment for allocating resources to an account, the method is suitable for a transaction system comprising at least one account, and the method comprises the following steps: aiming at any interface in the transaction system; according to the historical calling condition corresponding to the interface in the at least one historical time interval and the recent calling condition of the interface in the first time interval, the predicted calling condition of the interface in the second time interval is obtained; wherein the date to which the first time interval belongs is later than the date to which any historical time interval belongs, the date to which the first time interval belongs is the same as the date to which the second time interval belongs, and the ending moment of the first time interval is earlier than the starting moment of the second time interval; the second time interval is a sub-time interval of any historical time interval; and in the second time interval, if any account initiates a transaction through the interface, carrying out resource allocation on the transaction according to the predicted calling condition of the interface. The method can improve the transaction success rate.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, and device for allocating resources to an account. Background Technology

[0002] When a hot account appears in a payment system, it can trigger a series of technical and security challenges. For example, if the payment system does not take special measures to deal with hot accounts, it may cause problems such as database connection pool exhaustion and CPU load spikes. Hot accounts can also cause downstream systems such as risk control systems and accounting systems to generate a large number of duplicate or dense logs, which may lead to message queue backlog. A hot account is a specific account that is accessed or transacted frequently in a short period of time.

[0003] Currently, the identification of hot accounts mainly relies on real-time monitoring of the access frequency of various accounts within the payment system. However, the access behavior of hot accounts is highly dependent on the specific business context. Their suddenness, persistence, and resource consumption characteristics are influenced by various factors such as transaction scenarios, marketing strategies, user writing patterns, and external market events. The same account may appear as an ordinary account or an extremely hot account at different times. Real-time monitoring of the access frequency of various accounts within the payment system is a coarse-grained identification scheme, which is insufficient to accurately identify hot accounts within the payment system. Summary of the Invention

[0004] This application provides a processing method, apparatus, and device for allocating resources to an account, thereby improving the transaction success rate of the account.

[0005] In a first aspect, this application provides a method for allocating resources to an account, applicable to a trading system including at least one account, the method comprising: For any interface in the trading system, based on the historical call data of the interface in at least one historical time interval and the most recent call data of the interface in the first time interval, the predicted call data of the interface in the second time interval is obtained; wherein, the date of the first time interval is later than the date of any historical time interval, the date of the first time interval is the same as the date of the second time interval, and the end time of the first time interval is earlier than the start time of the second time interval; the second time interval is a sub-time interval of any historical time interval; During the second time interval, if any one of the at least one accounts initiates a transaction through the interface, the transaction system's resources are allocated for the transaction based on the predicted call status of the interface.

[0006] For any interface in the trading system, this application predicts its future call patterns based on the interface's historical and recent call patterns, thereby improving the accuracy of the prediction. Furthermore, when an account calls the interface to initiate a transaction in the future, resources can be allocated to the transaction based on the predicted call patterns, improving the foresight and rationality of transaction resource allocation, and also increasing the transaction success rate.

[0007] In one possible design, before allocating resources of the transaction system for the transaction based on the predicted call patterns of the interface, the following steps are also included: The transaction activity of the account is determined based on the transaction initiation status of the account within the third time interval; the start time of the third time interval is midnight of the date to which the second time interval belongs, and the end time of the third time interval is the start time of the second time interval. Determine the business importance corresponding to the business category to which the transaction belongs; Based on the predicted call status of the interface, the transaction system allocates resources for the transaction, including: Based on the predicted call status of the interface, the transaction activity of the account, and the importance of the business, the transaction system allocates resources for the transaction.

[0008] This application does not only allocate resources for transactions based on the single dimension of predicted API call activity, but also considers the transaction activity of the account and the business importance of the transaction, thus conducting a multi-dimensional comprehensive evaluation and improving the rationality and accuracy of resource allocation.

[0009] In one possible design, before obtaining the predicted call status of the interface, the following steps are also included: Based on the most recent call data of the interface within the first time interval, at least one historical time interval is filtered to obtain K historical time intervals; K is a positive integer. Based on the historical call data of the interface in at least one historical time interval and the most recent call data of the interface in the first time interval, the predicted call data of the interface in the second time interval is obtained, including: The historical call information corresponding to the K historical time intervals, the recent call information of the interface in the first time interval, the second time interval, and the interface information of the interface are input into a preset model to obtain the predicted call information of the interface in the second time interval.

[0010] This application uses a pre-trained model to obtain the predicted call status of the interface, thereby improving the efficiency and accuracy of obtaining the predicted call status.

[0011] In one possible design, the call data includes the number of API calls and the average response time of the API. Filtering the at least one historical time interval based on the most recent calls to the interface within the first time interval includes: For any one of the at least one historical time intervals, calculate the first mean square error between the number of interface calls corresponding to the historical time interval and the number of interface calls included in the recent call situation, and the second mean square error between the average response time of the interface corresponding to the historical time interval and the average response time of the interface included in the recent call situation, and calculate the mean square error between the historical time interval and the first time interval based on the first mean square error and the second mean square error. The K historical time intervals with the smallest mean square error between the at least one historical time interval and the first time interval are selected as the K historical time intervals.

[0012] By calculating the mean squared error, at least one historical time interval can be removed from the historical time interval where the historical call situation differs significantly from the recent call situation. This avoids interfering with the prediction of the interface's call situation in the second time interval, thereby improving the accuracy of the interface's call situation prediction.

[0013] In one possible design, the transaction activity of the account is determined based on the account's transaction initiation activities within a third time interval, including: The total transaction activity of the trading system in the third time interval is determined based on the average number of transactions and average transaction processing time corresponding to the at least one account in the third time interval. The transaction activity of an account is determined based on the total transaction activity of the transaction system during the third time interval, as well as the average number of transactions and average transaction processing time of the account during the third time interval.

[0014] In one possible design, resource allocation of the transaction system is performed for the transaction based on the predicted call patterns of the interface, the transaction activity of the account, and the importance of the business, including: A first weight value is determined based on the transaction activity of the account; the first weight value is positively correlated with the transaction activity of the account. The second weight value is determined based on the account's transaction activity and the predicted call status of the interface; A third weight value is determined based on the importance of the business; the third weight value is positively correlated with the importance of the business. The first weight value, the second weight value, and the third weight value are weighted and summed. If the weighted summation result meets the first preset condition, resources are added to the transaction.

[0015] In one possible design, a second weight value is determined based on the account's transaction activity and the predicted call patterns of the interface, including: If the transaction activity level of the account meets the second preset condition, the second weight value is determined based on the interface call volume and average interface response time included in the predicted call situation; the second weight value is positively correlated with the interface call volume and average interface response time included in the predicted call situation. Otherwise, the preset value will be used as the second weight value.

[0016] The higher the transaction activity of an account, or the greater the number of interface calls included in the predicted call situation, or the longer the average response time of the interface included in the predicted call situation, or the higher the importance of the business, the greater the probability that the weighted sum of the first weight, the second weight, and the third weight will satisfy the first preset condition, and the greater the probability of increasing resources for the transaction. This realizes the allocation of resources to high-value and high-activity accounts, maximizing the business success rate while ensuring the stability of the transaction system.

[0017] In one possible design, any one of the at least one historical time intervals has the same date as the second time interval, and the year of the historical time interval is earlier than the year of the second time interval; or, the historical time interval has the same year as the second time interval, and the date of the historical time interval is earlier than the date of the second time interval.

[0018] If the second time interval to which the account initiates the transaction involves a promotional event, such as November 11th (Double Eleven) or December 12th (Double Twelve), then any historical time interval should have the same date as the second time interval, and the year of the historical time interval should be earlier than the year of the second time interval. This is because historical call data from dates other than November 11th is not very helpful in predicting API call data from November 11th. For example, if the second time interval is November 11th and the year is 2025, then any historical time interval should have November 11th, and the year could be 2024, 2023, 2022, or any other year earlier than 2025. If there is no promotional activity on the date of the second time interval to which the account initiates the transaction, then the historical time interval should be the same as the year of the second time interval, and the date of the historical time interval should be earlier than the date of the second time interval. For example, if the date of the second time interval is November 3 and the year is 2025, then the year of any historical time interval should be 2025, and the date can be November 2, November 1, October 31, etc., which are earlier than November 3.

[0019] Secondly, this application also provides a processing apparatus for allocating resources to an account, the apparatus being deployed in a transaction system including at least one account; the apparatus includes a prediction unit and an allocation unit; The prediction unit is configured to, for any interface in the trading system, obtain the predicted call situation of the interface in a second time interval based on the historical call situation of the interface in at least one historical time interval and the recent call situation of the interface in a first time interval; wherein, the date of the first time interval is later than the date of any historical time interval, the date of the first time interval is the same as the date of the second time interval, and the end time of the first time interval is earlier than the start time of the second time interval; the second time interval is a sub-time interval of any historical time interval; The allocation unit is used to allocate resources of the transaction system for the transaction based on the predicted call status of the interface when any one of the at least one accounts initiates a transaction through the interface during the second time interval.

[0020] In one possible design, before allocating resources of the transaction system for the transaction based on the predicted call situation of the interface, the allocation unit is further configured to: The transaction activity of the account is determined based on the transaction initiation status of the account within the third time interval; the start time of the third time interval is midnight of the date to which the second time interval belongs, and the end time of the third time interval is the start time of the second time interval. Determine the business importance corresponding to the business category to which the transaction belongs; The allocation unit, when allocating resources of the transaction system for the transaction based on the predicted call status of the interface, is specifically used for: Based on the predicted call status of the interface, the transaction activity of the account, and the importance of the business, the transaction system allocates resources for the transaction.

[0021] In one possible design, before obtaining the predicted call status of the interface, the prediction unit is further configured to: Based on the most recent call data of the interface within the first time interval, at least one historical time interval is filtered to obtain K historical time intervals; K is a positive integer. The prediction unit, when obtaining the predicted call situation of the interface in the second time interval based on the historical call situation of the interface in at least one historical time interval and the recent call situation of the interface in the first time interval, is specifically used for: The historical call information corresponding to the K historical time intervals, the recent call information of the interface in the first time interval, the second time interval, and the interface information of the interface are input into a preset model to obtain the predicted call information of the interface in the second time interval.

[0022] In one possible design, the call data includes the number of API calls and the average response time of the API. The prediction unit, when filtering the at least one historical time interval based on the recent call information of the interface within the first time interval, is specifically used for: For any one of the at least one historical time intervals, calculate the first mean square error between the number of interface calls corresponding to the historical time interval and the number of interface calls included in the recent call situation, and the second mean square error between the average response time of the interface corresponding to the historical time interval and the average response time of the interface included in the recent call situation, and calculate the mean square error between the historical time interval and the first time interval based on the first mean square error and the second mean square error. The K historical time intervals with the smallest mean square error between the at least one historical time interval and the first time interval are selected as the K historical time intervals.

[0023] In one possible design, the allocation unit, when determining the transaction activity of the account based on the account's transaction initiation status within a third time interval, specifically performs the following functions: The total transaction activity of the trading system in the third time interval is determined based on the average number of transactions and average transaction processing time corresponding to the at least one account in the third time interval. The transaction activity of an account is determined based on the total transaction activity of the transaction system during the third time interval, as well as the average number of transactions and average transaction processing time of the account during the third time interval.

[0024] In one possible design, the allocation unit, when allocating resources of the transaction system for the transaction based on the predicted call status of the interface, the transaction activity of the account, and the importance of the business, is specifically used for: A first weight value is determined based on the transaction activity of the account; the first weight value is positively correlated with the transaction activity of the account. The second weight value is determined based on the account's transaction activity and the predicted call status of the interface; A third weight value is determined based on the importance of the business; the third weight value is positively correlated with the importance of the business. The first weight value, the second weight value, and the third weight value are weighted and summed. If the weighted summation result meets the first preset condition, resources are added to the transaction.

[0025] In one possible design, the allocation unit, when determining the second weight value based on the account's transaction activity and the predicted call patterns of the interface, specifically performs the following: If the transaction activity level of the account meets the second preset condition, the second weight value is determined based on the interface call volume and average interface response time included in the predicted call situation; the second weight value is positively correlated with the interface call volume and average interface response time included in the predicted call situation. Otherwise, the preset value will be used as the second weight value.

[0026] In one possible design, any one of the at least one historical time intervals has the same date as the second time interval, and the year of the historical time interval is earlier than the year of the second time interval; or, the historical time interval has the same year as the second time interval, and the date of the historical time interval is earlier than the date of the second time interval.

[0027] Thirdly, this application also provides a processing device for allocating resources to an account, the device comprising: a processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method described in the first aspect above.

[0028] Fourthly, this application also provides a computer-readable storage medium comprising a program that, when executed on a device, causes the device to perform the method as described in any one of the first aspects above.

[0029] Fifthly, this application also provides a computer program product, the computer program product comprising a computer program that, when executed by a processor, implements the method described in the first aspect above. Attached Figure Description

[0030] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0031] Figure 1 A schematic diagram of an existing hot account identification scheme; Figure 2 A schematic flowchart illustrating the method for allocating resources to an account, provided in an embodiment of this application; Figure 3 A detailed flowchart of the method for allocating resources to an account, provided in an embodiment of this application; Figure 4 A schematic diagram of the processing device for allocating resources to an account provided in this application embodiment. Figure 1 ; Figure 5 A schematic diagram of the processing device for allocating resources to an account provided in this application embodiment. Figure 2 . Detailed Implementation

[0032] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0033] The application scenarios described in this application are for the purpose of more clearly illustrating the technical solutions of this application, and do not constitute a limitation on the technical solutions provided in this application. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided in this application are also applicable to similar technical problems. In the description of this application, unless otherwise stated, "multiple" means two or more.

[0034] Currently, common solutions for dealing with hot accounts include: Figure 1 As shown, the health status of the application server is monitored, hot accounts are automatically identified, and their core data is loaded into the local cache or distributed cache to reduce direct impact on the database and avoid cache breakdown. However, this solution struggles to balance transaction data consistency and system performance. Transaction data has high consistency requirements, and caching solutions are prone to inconsistencies between the cache and the database under high-concurrency write scenarios, leading to issues such as duplicate deductions and incorrect balances. Furthermore, the distributed locks or transaction mechanisms introduced to ensure consistency significantly reduce the throughput of the transaction system, thus defeating the purpose of cache optimization.

[0035] Another common approach is to merge or serialize concurrent write requests for the same frequently accessed account, using memory queues or asynchronous task scheduling mechanisms to achieve "queue first, process later," thus smoothing out instantaneous traffic spikes. However, in core transaction scenarios such as payments and transfers, which are highly sensitive to latency, queuing or merging requests for frequently accessed accounts can significantly increase user response time, or even cause failures due to timeouts. This not only harms the user experience but may also directly lead to lost transactions, severely impacting business conversion rates.

[0036] To address the problems existing in the above-mentioned solutions, this application proposes the following... Figure 2 The method shown is applicable to trading systems that include at least one account. The execution entity of this method can be a server, a chip within the server, or a functional module within the server; this application does not limit this. The following explanation uses a server as the execution entity. Figure 2 The method shown specifically includes: Step 201: For any interface in the trading system, based on the historical call data of the interface in at least one historical time interval and the recent call data of the interface in the first time interval, obtain the predicted call data of the interface in the second time interval.

[0037] The first time interval has a date later than any historical time interval, the first time interval has the same date as the second time interval, and the end time of the first time interval is earlier than the start time of the second time interval. The second time interval is a sub-time interval of any historical time interval. For example, if the second time interval is 09:00~10:00, then the end time of the first time interval should be earlier than 09:00. Any historical time interval should include 09:00~10:00. For example, the historical time interval can be 09:00~10:00, 08:00~10:00, or 08:00~11:00.

[0038] It should be noted that this application determines the date and year of the historical time interval based on the date to which the second time interval belongs. Specifically, if there is a promotional activity on the date to which the second time interval belongs, then the historical time interval is the same as the date to which the second time interval belongs, and the year to which the historical time interval belongs is earlier than the year to which the second time interval belongs. For example, assuming the date to which the second time interval belongs is November 11 (Double Eleven) and the year to which it belongs is 2025, if historical time intervals are selected from dates such as November 10 and November 9, the interface call data corresponding to these historical time intervals are not very meaningful for predicting the interface call data within the second time interval. Therefore, the date to which the historical time interval belongs should be the same as the date to which the second time interval belongs, and the year should be earlier than the year to which the second time interval belongs. For example, historical time intervals can be selected from dates such as November 11, 2024, November 11, 2023, and November 11, 2022. Alternatively, if the second time interval falls on a loan repayment date, then the historical time interval must have the same date as the second time interval, but the month of the historical time interval must be earlier than the month of the second time interval. For example, if the loan repayment date is the 1st of each month, and the second time interval falls on the 1st in December, then the historical time interval must also fall on the 1st, and the month could be November, October, September, or August, which are earlier than December. If the second time interval falls on neither a loan repayment date nor a promotional event, then the historical time interval must fall on the same year as the second time interval, and the historical time interval must have an earlier date than the second time interval. For example, if the second time interval falls on December 5th in 2025, then the second time interval must also fall in 2025, and the date could be December 4th, December 3rd, or December 2nd, which are earlier than December 5th.

[0039] The transaction system records the call activity of each interface at different time intervals. Recording can be done at one-hour or two-hour intervals; this application does not specify a time limit. For example, if recording is done at one-hour intervals, the daily record of interface calls would include calls from 00:00 to 01:00, calls from 01:00 to 02:00, and so on, from 23:00 to 24:00. The historical call activity records for each interface constitute the interface historical behavior database.

[0040] The API call data includes the API call volume and the average response time. The API call volume refers to the number of times the API is called within a given time interval. The average response time is equal to the sum of the times each API call takes within the time interval divided by the API call volume. For example, taking a money transfer API as an example, suppose the money transfer API was called three times between 04:00 and 05:00 on December 10, 2025. The response times for these three calls were 1ms, 0.5ms, and 0.6ms respectively. Then, the sum of the times each API call takes between 04:00 and 05:00 is 1ms + 0.5ms + 0.6ms = 2.1ms. Therefore, the average response time for the money transfer API between 04:00 and 05:00 is 2.1ms / 3 = 0.7ms.

[0041] At least one historical time interval can be determined based on the second time interval. After determining at least one historical time interval, the historical call information corresponding to the interface in each historical time interval can be obtained from the interface historical behavior database. After obtaining the historical call information corresponding to each of the at least one historical time intervals, it is necessary to filter the at least one historical time interval based on the recent call information of the interface in the first time interval to obtain K historical time intervals, where K is a positive integer. Specifically, for any historical time interval, the first mean square error between the interface call volume corresponding to the historical time interval and the interface call volume included in the recent call information is calculated, as well as the second mean square error between the average response time of the interface corresponding to the historical time interval and the average response time of the interface included in the recent call information is calculated. The mean square error between the historical time interval and the first time interval is then calculated based on the first and second mean square errors. Finally, the K historical time intervals with the smallest mean square error between the at least one historical time interval and the first time interval are selected as the K historical time intervals. Calculated using the following formula:

[0042] in, This indicates the number of API calls within a historical time interval. This indicates the number of API calls included in the recent call statistics. This represents the first mean square error between the number of API calls within a historical time interval and the number of API calls included in the most recent call situation. This indicates the average response time of the interface corresponding to the historical time interval. This indicates the average response time of the interfaces included in recent call data. The second mean square error represents the average response time of interfaces corresponding to historical time intervals compared to the average response time of interfaces included in recent call scenarios. and For preset weighting coefficients, ;For example, and Both are 0.5, or, It is 0.6. It is 0.4.

[0043] Assuming that ten historical time intervals are determined based on the second time interval, the above calculation formula can be used to calculate the mean square error between each historical time interval and the first time interval. The mean square error corresponding to each historical time interval is sorted in ascending order. If K equals 3, the top 3 historical time intervals are retained.

[0044] Furthermore, after obtaining K historical time intervals, the historical call information corresponding to the K historical time intervals, the recent call information of the interface in the first time interval, the second time interval, and the interface information of the interface are input into the preset model to obtain the predicted call information of the interface in the second time interval, that is, to obtain the predicted results of the interface call volume and the average response time of the interface in the second time interval; wherein, the interface information may include the interface name, interface path, interface function description, etc.

[0045] Step 202: During the second time interval, if any one of the at least one accounts initiates a transaction through the interface, the transaction system's resources are allocated for the transaction based on the predicted call status of the interface.

[0046] For example, before allocating transaction system resources for transactions based on predicted API call activity, it is also necessary to determine the account's transaction activity level and the business importance corresponding to the transaction's business category based on the account's transaction initiation activity within the third time interval. The third time interval begins at midnight on the date corresponding to the second time interval, and ends at the beginning of the second time interval. For instance, if the second time interval is 09:00-10:00 and the date is December 20th, then the third time interval is 00:00-09:00, and the date is also December 20th.

[0047] The following explains the process for determining an account's trading activity level: First, based on the average number of transactions and average transaction processing time for at least one account within the third time interval, the total trading activity of the trading system within the third time interval is determined. The calculation can be performed using the following formula:

[0048] in, The number of at least one account, For the first The average number of transactions per account in the third time interval For the first Average transaction processing time for an account in the third time interval This represents the duration of the third time interval.

[0049] Then, based on the total trading activity of the trading system within the third time interval, and the account's average number of transactions and average transaction processing time within the third time interval, the account's trading activity is determined. The account's trading activity can be calculated using the following formula:

[0050] in, This represents the average number of transactions for the account during the third time interval. This represents the average transaction processing time for the account within the third time interval. The duration of the third time interval. This represents the total trading activity of the trading system within the third time interval.

[0051] For example, suppose there are four accounts in the trading system, denoted as A1, A2, A3, and A4. The average number of transactions and average transaction processing time for these four accounts in the third time interval are shown in Table 1:

[0052] Table 1

[0053] Assuming the third time interval is 15 hours, then the total trading activity of the trading system within the third time interval = 50 × 80 × 15 + 30 × 120 × 15 + 100 × 50 × 15 + 20 × 100 × 15 = 219000, and the trading activity of account A1 = =0.274, the trading activity level of account A2 = =0.247, the trading activity level of account A3 = =0.342, the trading activity level of account A4 = =0.137.

[0054] The following explains the process for determining the importance of business tasks: Table 2 shows the business categories involved in the transaction system and the corresponding business importance levels for each category. When an account initiates a transaction, the business category to which the transaction belongs is first determined, and then the business importance level corresponding to the transaction is determined according to Table 2.

[0055] Table 2

[0056] The importance of a transaction is positively correlated with the importance levels in Table 2; that is, the higher the importance level, the greater the transaction importance. For example, the importance level of a marketing campaign is higher than that of a regular payment. It should be noted that if a transaction corresponds to multiple transaction categories, and none of these categories include high-risk operations, the transaction category with the highest importance level can be identified. If multiple categories include high-risk operations, the transaction category should be identified as a high-risk operation category. For example, if a transaction corresponds to both marketing campaigns and high-risk operations, then it should be classified as a high-risk operation, and its importance level should be the same as that of a high-risk operation. Similarly, if a transaction corresponds to both high-priority financial transactions and marketing campaigns, then it should be classified as a high-priority financial transaction, and its importance level should be the same as that of a high-priority financial transaction.

[0057] After obtaining the account's transaction activity and business importance, the system can allocate transaction system resources based on the predicted API call data, account transaction activity, and business importance. Specifically, a first weight value is determined based on the account's transaction activity; this first weight value is positively correlated with the account's transaction activity. A second weight value is determined based on the account's transaction activity and the predicted API call data. A third weight value is determined based on the business importance; this third weight value is also positively correlated with the business importance. The first, second, and third weight values ​​are then weighted and summed. If the weighted sum meets a first preset condition, resources are added to the transaction. The first preset condition is, for example, that the weighted sum ranks in the top 50% or top 30% of all accounts. Specifically, the allocation of transaction system resources is based on the account's transaction activity and the predicted API call data. When determining the second weight value based on the call situation, if the account's transaction activity level meets the second preset condition, the second weight value is determined based on the interface call volume and average interface response time included in the predicted call situation. The second weight value is positively correlated with the interface call volume and average interface response time included in the predicted call situation. Otherwise, a preset value is used as the second weight value. The preset value is usually a very small value, such as 0.01. The second preset condition is, for example, that the account's transaction activity level ranks in the top 50% or top 30% of all accounts. The second preset condition can be the same as or different from the first preset condition.

[0058] Taking accounts A1 to A4 as examples, if accounts A1 to A4 initiate transactions through the interface within the second time interval, the process of resource allocation for each transaction initiated by accounts A1 to A4 is as follows: Figure 3 As shown, it specifically includes: First, determine the first weight value corresponding to accounts A1 to A4 respectively. The transaction activity values ​​corresponding to accounts A1 to A4 are 0.274, 0.247, 0.342 and 0.137 respectively. The result of sorting the transaction activity values ​​from high to low is: A3, A1, A2 and A4. Since the first weight value is positively correlated with the transaction activity value of the account, the first weight value corresponding to account A3 is the largest, followed by account A1, then account A2, and finally account A4. Next, determine the second weight values ​​for accounts A1 to A4. If the second preset condition is that the account's transaction activity ranks in the top 30% among all accounts, then only the account with the highest transaction activity among accounts A1 to A4 meets the second preset condition, i.e., only account A3 meets the second preset condition. The second weight values ​​for accounts A1, A2, and A4 should be set to preset values, assuming the preset value is 0.001, meaning the second weight values ​​for accounts A1, A2, and A4 are all 0.001. The second weight value for account A3 is positively correlated with the number of interface calls and the average response time of the interface included in the predicted call situation for account A3. Finally, determine the third weight values ​​for accounts A1 to A4. Determine the business category corresponding to the transactions initiated by accounts A1 to A4 in turn, and then determine the corresponding business importance level according to Table 2. The third weight values ​​corresponding to each business importance level are shown in Table 3. Further, the third weight values ​​for accounts A1 to A4 can be determined according to Table 3.

[0059]

[0060] Table 3

[0061] After determining the first, second, and third weight values ​​corresponding to accounts A1 to A4 respectively, the weighted sum of the first, second, and third weight values ​​for each account can be calculated using the following formula:

[0062] in, As the first weight value, As the second weight value, As the third weight value, , as well as For preset weighting coefficients, =1, for example, It is 0.4. It is 0.4. It is 0.2.

[0063] After obtaining the weighted summation results of accounts A1 to A4, it is determined whether each weighted summation result meets the first preset condition. If only the weighted summation result of account A3 meets the first preset condition, it indicates that account A3 is likely a high-value and high-activity account. Therefore, resources should be increased for transactions initiated by account A3 through the interface in the second time interval. That is, the resources allocated to account A3 are greater than the pre-configured resources, so as to maximize the business success rate while ensuring the stability of the transaction system. Transactions initiated by accounts A1, A2 and A4 in the second time interval can be allocated according to the pre-configured resources.

[0064] This application constructs a multi-dimensional dynamic evaluation model for hot accounts by integrating account transaction activity, interface prediction call status, and business importance. This avoids misjudgments caused by relying solely on instantaneous traffic, reduces resource idleness and overload through predictive scheduling, and enables resources to be tilted towards high-value, high-activity accounts, thereby maximizing business success rate while ensuring the stability of the transaction system.

[0065] Figure 4 and Figure 5 The diagram illustrates the possible structure of a processing apparatus for allocating resources to an account, as provided in embodiments of this application. These processing apparatuses for allocating resources to accounts can be used to implement the server functionality described in the method embodiments above, and thus also achieve the beneficial effects of the method embodiments described above.

[0066] like Figure 4 As shown, a resource allocation processing device 400 for accounts is deployed in a trading system including at least one account, and includes a prediction unit 410 and an allocation unit 420. The resource allocation processing device 400 for accounts is used to implement the above-described... Figure 2 The server functionality is illustrated in the method embodiment shown.

[0067] When the processing device 400 for allocating resources to an account is used to implement Figure 2 The server function in the method embodiment shown is as follows: The prediction unit 410 is configured to, for any interface in the trading system, obtain the predicted call situation of the interface in a second time interval based on the historical call situation of the interface in at least one historical time interval and the recent call situation of the interface in a first time interval; wherein, the date of the first time interval is later than the date of any historical time interval, the date of the first time interval is the same as the date of the second time interval, and the end time of the first time interval is earlier than the start time of the second time interval; the second time interval is a sub-time interval of any historical time interval; The allocation unit 420 is used to allocate resources of the transaction system for the transaction based on the predicted call status of the interface when any one of the at least one accounts initiates a transaction through the interface during the second time interval.

[0068] In one possible design, before allocating resources of the transaction system for the transaction based on the predicted call situation of the interface, the allocation unit 420 is further configured to: The transaction activity of the account is determined based on the transaction initiation status of the account within the third time interval; the start time of the third time interval is midnight of the date to which the second time interval belongs, and the end time of the third time interval is the start time of the second time interval. Determine the business importance corresponding to the business category to which the transaction belongs; The allocation unit 420, when allocating resources of the transaction system for the transaction based on the predicted call status of the interface, is specifically used for: Based on the predicted call status of the interface, the transaction activity of the account, and the importance of the business, the transaction system allocates resources for the transaction.

[0069] In one possible design, before obtaining the predicted call status of the interface, the prediction unit 410 is further configured to: Based on the most recent call data of the interface within the first time interval, at least one historical time interval is filtered to obtain K historical time intervals; K is a positive integer. The prediction unit 410, when obtaining the predicted call situation of the interface in the second time interval based on the historical call situation of the interface in at least one historical time interval and the recent call situation of the interface in the first time interval, is specifically used for: The historical call information corresponding to the K historical time intervals, the recent call information of the interface in the first time interval, the second time interval, and the interface information of the interface are input into a preset model to obtain the predicted call information of the interface in the second time interval.

[0070] In one possible design, the call data includes the number of API calls and the average response time of the API. The prediction unit 410, when filtering the at least one historical time interval based on the recent call information of the interface within the first time interval, is specifically used for: For any one of the at least one historical time intervals, calculate the first mean square error between the number of interface calls corresponding to the historical time interval and the number of interface calls included in the recent call situation, and the second mean square error between the average response time of the interface corresponding to the historical time interval and the average response time of the interface included in the recent call situation, and calculate the mean square error between the historical time interval and the first time interval based on the first mean square error and the second mean square error. The K historical time intervals with the smallest mean square error between the at least one historical time interval and the first time interval are selected as the K historical time intervals.

[0071] In one possible design, the allocation unit 420, when determining the transaction activity of the account based on the account's transaction initiation status within a third time interval, is specifically used for: The total transaction activity of the trading system in the third time interval is determined based on the average number of transactions and average transaction processing time corresponding to the at least one account in the third time interval. The transaction activity of an account is determined based on the total transaction activity of the transaction system during the third time interval, as well as the average number of transactions and average transaction processing time of the account during the third time interval.

[0072] In one possible design, the allocation unit 420, when allocating resources of the transaction system for the transaction based on the predicted call status of the interface, the transaction activity of the account, and the importance of the business, is specifically used for: A first weight value is determined based on the transaction activity of the account; the first weight value is positively correlated with the transaction activity of the account. The second weight value is determined based on the account's transaction activity and the predicted call status of the interface; A third weight value is determined based on the importance of the business; the third weight value is positively correlated with the importance of the business. The first weight value, the second weight value, and the third weight value are weighted and summed. If the weighted summation result meets the first preset condition, resources are added to the transaction.

[0073] In one possible design, the allocation unit 420, when determining the second weight value based on the account's transaction activity and the predicted call status of the interface, is specifically used for: If the transaction activity level of the account meets the second preset condition, the second weight value is determined based on the interface call volume and average interface response time included in the predicted call situation; the second weight value is positively correlated with the interface call volume and average interface response time included in the predicted call situation. Otherwise, the preset value will be used as the second weight value.

[0074] In one possible design, any one of the at least one historical time intervals has the same date as the second time interval, and the year of the historical time interval is earlier than the year of the second time interval; or, the historical time interval has the same year as the second time interval, and the date of the historical time interval is earlier than the date of the second time interval.

[0075] For a more detailed description of the prediction unit 410 and the allocation unit 420 mentioned above, please refer to [link / reference]. Figure 2 The relevant descriptions in the method embodiments shown are directly obtained and will not be repeated here.

[0076] like Figure 5 As shown, the processing apparatus 500 for allocating resources to an account includes a processor 510 and an interface circuit 520. The processor 510 and the interface circuit 520 are coupled to each other. It is understood that the interface circuit 520 can be a transceiver or an input / output interface. Optionally, the processing apparatus 500 for allocating resources to an account may also include a memory 530 for storing instructions executed by the processor 510, or storing input data required for the processor 510 to execute instructions, or storing data generated after the processor 510 executes instructions.

[0077] When the processing device 500 for allocating resources to an account is used to implement Figure 2 In the method shown, the processor 510 is used to implement the function of the prediction unit 410, and the interface circuit 520 is used to implement the function of the allocation unit 420.

[0078] The unit division in this embodiment is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this application can be integrated into a single processor, exist as separate physical units, or be integrated into a single unit. The integrated units described above can be implemented in hardware or as software functional units.

[0079] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0080] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A processing method for allocating resources to accounts, characterized in that, The method is suitable for a transaction system comprising at least one account, and comprises: For any one interface in the transaction system, obtaining a predicted calling condition of the interface in a second time interval according to a respective historical calling condition of the interface in at least one historical time interval and a recent calling condition of the interface in a first time interval; wherein the first time interval belongs to a date later than any one of the historical time intervals, the first time interval belongs to the same date as the second time interval, and an ending moment of the first time interval is earlier than a starting moment of the second time interval; the second time interval is a sub-time interval of any one of the historical time intervals; In the second time interval, if any one of the at least one account initiates a transaction through the interface, performing resource allocation of the transaction system for the transaction according to the predicted calling condition of the interface.

2. The method of claim 1, wherein, Before performing resource allocation of the transaction system for the transaction according to the predicted calling condition of the interface, the method further comprises: determining a transaction activity of the account according to a transaction initiation condition of the account in a third time interval; the starting moment of the third time interval is zero point of the date to which the second time interval belongs, and the ending moment of the third time interval is the starting moment of the second time interval; determining a business importance corresponding to a business category of the transaction; performing resource allocation of the transaction system for the transaction according to the predicted calling condition of the interface, comprises: performing resource allocation of the transaction system for the transaction according to the predicted calling condition of the interface, the transaction activity of the account, and the business importance.

3. The method of claim 1, wherein, Before obtaining the predicted calling condition of the interface, the method further comprises: screening the at least one historical time interval according to the recent calling condition of the interface in the first time interval to obtain K historical time intervals; K is a positive integer; obtaining the predicted calling condition of the interface in the second time interval according to the respective historical calling condition of the interface in the at least one historical time interval and the recent calling condition of the interface in the first time interval, comprises: inputting the respective historical calling condition of the K historical time intervals, the recent calling condition of the interface in the first time interval, the second time interval, and interface information of the interface into a preset model to obtain the predicted calling condition of the interface in the second time interval.

4. The method of claim 3, wherein, The calling condition comprises an interface calling quantity and an interface average response time consumption; screening the at least one historical time interval according to the recent calling condition of the interface in the first time interval, comprises: For any one of the at least one historical time interval, a first mean square error between an interface call quantity corresponding to the historical time interval and an interface call quantity in the recent call condition, and a second mean square error between an interface average response time consumption corresponding to the historical time interval and an interface average response time consumption in the recent call condition are calculated, and a mean square error between the historical time interval and the first time interval is calculated according to the first mean square error and the second mean square error; K historical time intervals with minimum mean square errors between the K historical time intervals and the first time interval are selected as the K historical time intervals.

5. The method of claim 2, wherein, The transaction activity of the account is determined according to a transaction initiation condition of the account in a third time interval, including: The total transaction activity of the transaction system in the third time interval is determined according to the average transaction quantity and the average transaction processing time consumption corresponding to the at least one account in the third time interval; The transaction activity of the account is determined according to the total transaction activity of the transaction system in the third time interval and the average transaction quantity and the average transaction processing time consumption corresponding to the account in the third time interval.

6. The method of claim 4, wherein, The resource allocation of the transaction system for the transaction is performed according to the predicted call condition of the interface, the transaction activity of the account and the business importance, including: A first weight value is determined according to the transaction activity of the account; the first weight value is positively correlated with the transaction activity of the account; A second weight value is determined according to the transaction activity of the account and the predicted call condition of the interface; A third weight value is determined according to the business importance; the third weight value is positively correlated with the business importance; The first weight value, the second weight value and the third weight value are weighted and summed, and if the weighted sum result meets a first preset condition, the resource of the transaction is increased.

7. The method of claim 6, wherein, The second weight value is determined according to the transaction activity of the account and the predicted call condition of the interface, including: If the transaction activity of the account meets a second preset condition, the second weight value is determined according to the interface call quantity and the interface average response time consumption included in the predicted call condition; the second weight value is positively correlated with the interface call quantity and the interface average response time consumption included in the predicted call condition; Otherwise, a preset value is taken as the second weight value.

8. The method of any one of claims 1-7, wherein, Any one of the at least one historical time interval is the same as the date to which the second time interval belongs, and the year to which the historical time interval belongs is earlier than the year to which the second time interval belongs; or the year to which the historical time interval belongs is the same as the year to which the second time interval belongs, and the date to which the historical time interval belongs is earlier than the date to which the second time interval belongs.

9. A processing device for allocating resources to accounts, characterized by The device is deployed in a transaction system including at least one account; the device includes a prediction unit and an allocation unit; The prediction unit is configured to, for any one interface in the transaction system, obtain a predicted calling condition of the interface in a second time interval according to a historical calling condition of the interface in at least one historical time interval and a latest calling condition of the interface in a first time interval; the first time interval belongs to a date later than a date to which any one historical time interval belongs, the date to which the first time interval belongs is the same as a date to which the second time interval belongs, and an ending moment of the first time interval is earlier than a starting moment of the second time interval; and the second time interval is a sub time interval of any one historical time interval. The allocation unit is configured to, in the second time interval, perform resource allocation for a transaction of the transaction system according to the predicted calling condition of the interface, if any one account in the at least one account initiates the transaction through the interface.

10. A processing device for allocating resources to accounts, characterized by Comprise: A processor, and a memory connected with the processor in communication; The memory stores computer execution instructions; The processor executes the computer execution instructions stored in the memory to implement the method in any one of claims 1-8.

Images