WO2022267395A1 - 代付请求处理方法及*** - Google Patents

代付请求处理方法及*** Download PDF

Info

Publication number
WO2022267395A1
WO2022267395A1 PCT/CN2021/139716 CN2021139716W WO2022267395A1 WO 2022267395 A1 WO2022267395 A1 WO 2022267395A1 CN 2021139716 W CN2021139716 W CN 2021139716W WO 2022267395 A1 WO2022267395 A1 WO 2022267395A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
merchant
plan
preset
tps
Prior art date
Application number
PCT/CN2021/139716
Other languages
English (en)
French (fr)
Inventor
毕坚
殷凇
罗子辉
Original Assignee
深圳前海微众银行股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 深圳前海微众银行股份有限公司 filed Critical 深圳前海微众银行股份有限公司
Publication of WO2022267395A1 publication Critical patent/WO2022267395A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/22—Payment schemes or models

Definitions

  • This application relates to the technical field of financial technology (Fintech), in particular to a method and system for processing payment requests.
  • banking institutions will first lock the resources of the account when performing bookkeeping processing, and automatically release the lock after the bookkeeping processing is completed.
  • accounts in the database often generate multiple concurrent operations in a short period of time, but in the actual payment processing process, only one thread can hold the resource lock of the current account, while other The thread must wait for the lock to be released before performing accounting processing one by one, so that the account is frequently locked and released, that is, the payment processing process such as deduction and account processing is performed frequently, which has become a hot spot in the payment request processing system account, which will seriously affect the processing speed of payment requests from other accounts, resulting in inefficient processing of payment requests.
  • the main purpose of this application is to propose a method and system for processing proxy payment requests, aiming at improving the processing efficiency of proxy payment requests, especially the processing efficiency corresponding to high concurrent proxy payment requests.
  • the present application provides a method for processing a payment request, the method includes the following steps:
  • the current payment plan is not a preset batch plan
  • the step of determining the plan switching direction of the merchant according to the comparison result includes:
  • the comparison result is that the TPS of the merchant is greater than the preset TPS threshold corresponding to the current payment scheme, then it is determined that the scheme switching direction of the merchant is to switch to a preset payment option with a larger preset TPS threshold;
  • the comparison result is that the merchant's TPS is less than or equal to the preset TPS threshold corresponding to the current payment plan, then it is determined that the merchant's plan switching direction is to switch to a preset payment option with a smaller preset TPS threshold.
  • the switching direction of the scheme is to switch to a preset optional payment scheme with a larger preset TPS threshold
  • the step of determining the target payment scheme of the merchant from the pending optional schemes include:
  • the preset TPS threshold value corresponding to each of the pending optional solutions sequentially acquire pending optional solutions with larger preset TPS thresholds, and determine whether the currently acquired pending optional solutions are preset batch solutions;
  • the currently obtained pending optional solution is not a preset batch solution, then compare the TPS of the merchant with the preset TPS threshold corresponding to the currently obtained pending optional solution;
  • the TPS of the merchant is less than or equal to the preset TPS threshold corresponding to the currently acquired pending alternative, determine whether the current payment plan of the merchant can be switched to the currently acquired pending alternative, if possible switch, then determine the currently acquired preset payment option as the target payment plan of the merchant;
  • the merchant's TPS When the merchant's TPS is greater than the preset TPS threshold corresponding to the currently acquired pending alternatives, or the merchant's current payment plan cannot be switched to the currently acquired pending alternatives, obtain the next preset For the option to be determined with a larger TPS threshold, repeat the above-mentioned steps of determining the target payment plan of the merchant.
  • the switching direction of the scheme is to switch to a preset optional payment scheme with a smaller preset TPS threshold
  • the step of determining the target payment scheme of the merchant from the pending optional schemes include:
  • the preset TPS thresholds corresponding to each of the pending options sequentially acquire pending options with smaller preset TPS thresholds, and determine whether the currently acquired pending options belong to the preset TPS total limit solution ;
  • the currently obtained pending optional scheme does not belong to the preset TPS total value limit scheme, then determine the currently acquired pending optional scheme as the merchant's target payment scheme.
  • the step of judging whether the currently acquired pending options belong to the preset TPS total value limit scheme it further includes:
  • the currently obtained pending alternatives belong to the preset TPS total value limit scheme, then according to the currently obtained TPS total value of the pending alternatives and the TPS of the merchant, it is judged whether The current payment plan is switched to the currently obtained pending optional plan;
  • the step of judging whether the current payment plan of the merchant is a preset batch plan it further includes:
  • the current payment plan is a preset batch plan, then obtain the merchant’s preset payment alternative plan, and filter out the default payment plan corresponding to the current payment plan from the merchant’s preset payment option plan A pending alternative with a smaller TPS threshold;
  • the payment request processing system includes a deposit core
  • the step of executing the target payment plan to complete the processing flow corresponding to the payment request includes:
  • the method also includes:
  • the payment records to be processed after the processing are completed are sent to the deposit core for the deposit core Perform payment processing on the pending payment flow after the processing is completed.
  • the target payment plan is a preset batch plan, and after the step of storing the payment flow in the preset database, it further includes:
  • the listening thread corresponding to the preset target message queue retrieves the batch payment flow from the preset database, and assembles the batch request corresponding to the batch flow and sends it to The deposit core is used for the deposit core to perform payment processing on the batch payment flow according to the batch request.
  • the present application also provides a payment request processing device, the payment request processing device includes:
  • the first judging module is used to determine the merchant corresponding to the payment request and the current payment plan of the merchant when receiving the payment request, and determine whether the current payment plan of the merchant is a preset batch plan;
  • the comparison and determination module is used to compare the TPS of the merchant with the preset TPS threshold corresponding to the current payment plan if the current payment plan is not a preset batch plan, and determine the plan switching direction of the merchant according to the comparison result , the TPS of the merchant is the number of payment requests of the merchant processed per unit time;
  • the second judging module is used to acquire the preset alternative payment schemes of the merchant, and judge whether there is a pending alternative matching the scheme switching direction among the preset alternative payment schemes;
  • a plan switching module configured to determine the merchant's target payment plan from the pending alternatives, and switch the merchant's current payment plan to the target payment plan;
  • the payment execution module is configured to execute the target payment plan, so as to complete the processing flow corresponding to the payment request.
  • the present application also provides a computer program product, including a computer program, and when the computer program is executed by a processor, the steps of the above-mentioned payment request processing method are realized.
  • the present application also provides a payment request processing system
  • the payment request processing system includes: a memory, a processor, and a proxy stored on the memory and operable on the processor.
  • a payment request processing program when the payment request processing program is executed by the processor, implements the steps of the above-mentioned payment request processing method.
  • the present application also provides a storage medium, on which a payment request processing program is stored, and when the payment request processing program is executed by a processor, the above-mentioned payment request processing is realized. method steps.
  • the payment request processing method proposed in this application when receiving a payment request, determines the corresponding merchant and the current payment plan, and judges whether the current payment plan is a batch plan; if it is not a batch plan, compare the merchant TPS with the current payment plan Compare the TPS threshold of the payment plan to determine the merchant’s plan switching direction; determine whether there is a pending alternative matching the plan switching direction among the merchant’s preset payment options; if it exists, determine the target payment plan , and switch the current payment plan to the target payment plan; execute the target payment plan to complete the corresponding payment process.
  • the merchant's current payment scheme is switched to the adapted target payment scheme, so as to process payment requests of different concurrency levels in a timely manner, and improve the processing efficiency of payment requests.
  • Fig. 1 is a schematic diagram of the system structure of the hardware operating environment involved in the example scheme of the present application
  • FIG. 2 is a schematic flowchart of the first embodiment of the method for processing a payment request in the present application
  • Fig. 3 is the merchant configuration table of the preferred embodiment of the payment request processing method of the present application.
  • Fig. 4 is the merchant attribute extension table of the preferred embodiment of the payment request processing method of the present application.
  • Fig. 5 is the payment process flowchart of the preferred embodiment (Scheme 1) of the payment request processing method of the present application;
  • Fig. 6 is the payment processing flowchart of the preferred embodiment (scheme 2) of the payment request processing method of the present application;
  • Fig. 7 is a flow chart of plan switching processing in a preferred embodiment of the payment request processing method of the present application.
  • Fig. 8 is a payment processing flowchart of a preferred embodiment (Scheme 3) of the payment request processing method of the present application;
  • FIG. 9 is a flow chart of concurrency control in a preferred embodiment (Scheme 3) of the method for processing payment requests on behalf of the present application;
  • Fig. 10 is the payment processing flowchart of the preferred embodiment (batch scheme) of the payment request processing method of the present application;
  • Fig. 11 is the concurrency control flowchart of the preferred embodiment (batch scheme) of the payment request processing method of the present application;
  • Fig. 12 is a schematic diagram of functional modules of a preferred embodiment of the method for processing a payment request in the present application.
  • FIG. 1 is a schematic diagram of the system structure of the hardware operating environment involved in the solution of the embodiment of the present application.
  • the system in this embodiment of the application may be a management server, a PC terminal, a mobile device, and the like.
  • the system may include: a processor 1001 , such as a CPU, a network interface 1004 , a user interface 1003 , a memory 1005 , and a communication bus 1002 .
  • the communication bus 1002 is used to realize connection and communication between these components.
  • the user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface.
  • the network interface 1004 may include a standard wired interface and a wireless interface (such as a WI-FI interface).
  • the memory 1005 can be a high-speed RAM memory, or a stable memory (non-volatile memory), such as a disk memory.
  • the memory 1005 may also be a storage device independent of the aforementioned processor 1001 .
  • FIG. 1 does not constitute a limitation to the system, and may include more or less components than shown in the figure, or combine some components, or arrange different components.
  • the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module, and a payment request processing program.
  • the operating system is a program that manages and controls the payment request processing system and software resources, and supports the operation of the network communication module, user interface module, payment request processing program, and other programs or software;
  • the network communication module is used to manage and control the network Interface 1002;
  • the user interface module is used to manage and control the user interface 1003.
  • the payment request processing system calls the payment request processing program stored in the memory 1005 through the processor 1001, and executes the following payment request processing methods in various embodiments operate.
  • Fig. 2 is a schematic flow chart of the first embodiment of the method for processing the payment request of the present application, and the method includes:
  • Step S10 when a payment request is received, determine the merchant corresponding to the payment request and the current payment plan of the merchant, and determine whether the current payment plan of the merchant is a preset batch plan;
  • the proxy payment request processing method of this embodiment is applied to the proxy payment request processing systems of major financial institutions.
  • the payment in this embodiment refers to the business of transferring funds from the bank's account to the designated bank card account.
  • banking institutions will first lock the resources of the account when performing bookkeeping processing, and automatically release the lock after the bookkeeping processing is completed.
  • a merchant configuration table can be configured in advance according to the initially estimated concurrency of payment requests provided by the cooperative merchants of the banking institution. As shown in Figure 3, the merchant number, merchant number, The payment scheme type, message queue topic, whether the payment scheme can be dynamically switched, etc. Different merchant IDs correspond to different merchants. For the convenience of description, if the merchants are sorted according to the ascending order of the concurrent amount of merchants, the types of payment schemes in this embodiment include scheme 1, scheme 2, scheme 3 and batch scheme are used as examples to illustrate, among which, scheme 1 and scheme 2 are used for Handle payment requests under low concurrency or normal concurrency situations, scheme three and batch schemes are used to handle payment requests under high concurrency situations.
  • the merchant corresponding to the payment request can be determined according to the merchant number carried in the payment request, and the payment plan type corresponding to the merchant can be checked in the merchant configuration table to determine the current payment plan corresponding to the merchant.
  • the payment plan of course, before the plan switching process for the merchant, it is necessary to query the merchant configuration table to determine whether the merchant can dynamically switch plans, that is, to determine whether the merchant has the plan switching authority.
  • the merchant whose merchant number is 0000001 can switch dynamically, which means that the merchant has the plan switching authority, and can switch the current payment plan of the merchant to another payment plan; and the merchant The merchant with the number 0000002 cannot be dynamically switched, which means that the merchant does not have the right to switch schemes. No matter how the merchant’s TPS changes, the current payment plan will be maintained. Therefore, only when it is found in the merchant configuration table that the merchant can dynamically switch plans, that is, when the merchant has the plan switching authority, can the plan switching process be performed on the merchant, so the plan switching process flow in this embodiment is mainly for plans It is proposed by the merchant who switched permissions.
  • the corresponding TPS thresholds can be set for plan 1, plan 2 and plan 3 respectively, because the batch plan (preset batch plan ) corresponds to the largest throughput, so the batch plan does not have a corresponding TPS threshold. Therefore, it is necessary to determine whether the current payment plan of the merchant is the default batch plan when switching the plan for the merchant, so that there is no need to use the
  • the batch scheme in which the merchant's TPS is compared with the TPS threshold corresponding to the current payment scheme is distinguished from other schemes (Scheme 1, Scheme 2, and Scheme 3).
  • Step S20 if the current payment plan is not a preset batch plan, compare the TPS of the merchant with the preset TPS threshold corresponding to the current payment plan, and determine the plan switching direction of the merchant according to the comparison result, the The TPS of the merchant is the number of payment requests of the said merchant processed per unit time;
  • the number of payment requests processed by merchants per unit time is the TPS (Transactions Per Second) of merchants.
  • the TPS of merchants can represent the current concurrent volume of merchants; the TPS threshold refers to the TPS upper limit. Since the current payment plan of the merchant is included in the default payment options, the merchant may have other preset payment options with larger and/or smaller throughput than the current payment plan. Therefore,
  • the plan switching direction corresponding to the merchant includes switching to a preset payment option with a larger throughput or switching to a preset payment option with a smaller throughput.
  • the merchant's current payment plan is not a batch plan, that is, the merchant's current payment plan is plan 1, plan 2, or plan 3, then compare the merchant's current TPS with the TPS threshold corresponding to the current payment plan , so as to determine the plan switching direction of the merchant according to the comparison result, so as to improve the processing efficiency of the payment request and improve the user experience.
  • step of determining the plan switching direction of the merchant according to the comparison result includes:
  • Step a1 if the comparison result is that the merchant’s TPS is greater than the preset TPS threshold corresponding to the current payment plan, then determine that the merchant’s plan switching direction is to switch to a preset payment option with a larger preset TPS threshold ;
  • Step a2 if the comparison result is that the merchant’s TPS is less than or equal to the preset TPS threshold corresponding to the current payment plan, then it is determined that the merchant’s plan switching direction is to a preset payment option with a smaller preset TPS threshold Scheme switching.
  • the merchant's TPS is greater than the preset TPS threshold corresponding to the current payment plan, it is determined that the merchant's plan switching direction is to switch to a preset payment option with a larger preset TPS threshold, that is, , switch the merchant’s current payment plan to a plan with a higher throughput; if the merchant’s TPS is less than or equal to the preset TPS threshold corresponding to the current payment plan, since it is necessary to switch the plan for the merchant, then determine the The merchant’s scheme switching direction is to switch to the preset alternative payment scheme with a smaller preset TPS threshold, that is, switch the merchant’s current payment scheme to a scheme with a smaller throughput to determine the most suitable for the merchant. matching payment plan.
  • the optional payment schemes configured by a merchant include scheme 1, scheme 2, scheme 3 and batch scheme, and the TPS threshold configured by the current merchant in scheme 1 is 100, and the TPS threshold configured in scheme 2 is 200.
  • the TPS threshold of the third configuration is 300.
  • the batch plan there is no need to configure the TPS threshold, because the batch plan has no TPS upper limit, and the merchant’s current payment plan is plan three, that is, the current merchant’s TPS is less than 300. If the merchant is detected If the TPS of the merchant has risen to 400, it will directly switch to the batch plan; if the TPS of the merchant drops to 280, the current payment plan will be switched to plan three, and so on.
  • the current payment plan can be directly switched to plan 1, or the merchant's current TPS can be gradually compared with the TPS threshold corresponding to the plan to be switched, so as to determine the merchant The current best fit solution.
  • Step S30 acquiring the merchant's preset alternative payment schemes, and judging whether there is a pending alternative matching the scheme switching direction among the preset alternative payment schemes;
  • the merchant's default payment option can be obtained from the pre-configured merchant attribute extension table, as shown in Figure 4 , the merchant attribute expansion table includes the default payment options corresponding to each preset merchant.
  • the default payment options include the merchant’s current payment plan, and then determine the default payment options Whether there is a pending alternative plan that matches the merchant’s plan switching direction.
  • the merchant’s plan switching direction is to switch to a preset alternative payment plan with a higher preset TPS threshold, then determine the merchant’s Whether there is a payment scheme with a higher throughput than the current payment scheme among the preset payment alternatives; if the merchant’s plan switching direction is to switch to the preset payment alternative with a smaller preset TPS threshold, then Judging whether there is a payment scheme with a smaller throughput than the current payment scheme among the merchant's preset payment schemes.
  • the merchant whose merchant number is 0000004 has the right to switch plans, and its corresponding default payment alternatives include plan 1, plan 2 and plan 3, because the throughput corresponding to plan 1, plan 2 and plan 3 It is getting bigger and bigger.
  • the merchant's current payment plan is plan two, when it is determined that the merchant needs to switch the plan, it can switch the direction according to the plan of the merchant, and use plan one or three as the corresponding plan of the merchant
  • plan two when it is determined that the merchant needs to switch the plan, it can switch the direction according to the plan of the merchant, and use plan one or three as the corresponding plan of the merchant
  • plan three For the target payment plan, if switching to a direction with a smaller throughput, use plan one as a pending option; if switching to a direction with a higher throughput, plan three can be used as a pending option.
  • Step S40 if it exists, determine the merchant's target payment plan from the pending alternatives, and switch the merchant's current payment plan to the target payment plan;
  • the pending optional scheme includes at least one payment scheme, therefore, the payment scheme to be switched by the merchant can be determined from the pending optional schemes, that is, the target payment scheme, and the current payment scheme of the merchant can be switched to the target payment scheme plan.
  • the payment scheme to be switched by the merchant can be determined from the pending optional schemes, that is, the target payment scheme, and the current payment scheme of the merchant can be switched to the target payment scheme plan.
  • they can dynamically switch to an adapted plan, which can ensure that merchants' payment requests with different concurrency are processed in a timely manner, thereby improving the processing efficiency of payment requests.
  • step of judging whether there is a pending alternative matching the scheme switching direction among the preset alternative payment schemes it further includes:
  • Step b if there is no pending alternative plan matching the plan switching direction, then maintain the current payment plan of the merchant and execute the current payment plan to complete the processing flow corresponding to the payment request.
  • Step S50 executing the target payment plan to complete the processing flow corresponding to the payment request.
  • the agent payment request processing system includes a deposit core, a unified payment platform, etc., wherein the deposit core is the bank's core accounting system; the unified payment platform specifically refers to the bank's internal unified payment platform system, which is used to Transfer the money in the payment request to the bank card of another bank.
  • the target payment plan can be one of the payment plans such as plan 1, plan 2, plan 3, and batch plan to deal with the concurrent volume of different merchants, as shown in Figure 5, which is a better processing method for payment requests in this application
  • the flow chart of payment processing in the embodiment Scheme 1.
  • the target payment plan is Plan 1
  • first verify the request data in the payment request such as verifying whether the merchant corresponding to the request data matches the merchant that sent the payment request , Whether the request data is empty, whether the data format conforms, etc., after the verification of the request data is passed, it is stored in the payment flow meter, and then the one-to-one transfer request data is assembled and sent to the deposit core; if the deposit core fails to process, That is, if the deduction of the money on the customer's account fails, the payment status of the payment request in the payment flow table will be updated to "failed", and the transaction failure message will be returned to the corresponding client; if the deposit core process is successful, That is, if the deduction of the money on the customer's account is successful, it will be judged whether the account to be transferred (payee) is an account opened by the bank (in-bank account); Transfer the money to the account to be transferred in, and return the transaction success message to the corresponding client; if the payee
  • Scheme 1 it is an asynchronous process for the unified payment platform to transfer the money from the internal account to the bank card of another bank designated by the customer. It can be seen that the biggest feature of Scheme 1 is to try to return the transaction results in the process of payment processing synchronously, which is generally used for normal personal account transfers, and the concurrency is not high, so the overall throughput of the payment processing system in Scheme 1 is low.
  • FIG. 6 is a flow chart of payment processing in a preferred embodiment (Scheme 2) of the method for processing a payment request in this application. Comparing Figure 5 and Figure 6, it can be seen that the payment processing process of Scheme 2 is similar to that of Scheme 1. The difference is that in the process of payment processing, Scheme 2 is processed by asynchronous thread transfer deposit core and unified payment platform, and the transaction result The requester initiates payment result query.
  • the second solution can well solve the problem of low system throughput, if one or more merchants have a very large amount of requests for corporate accounts, it will make the account of this high concurrent request merchant become a hotspot account, that is, the hotspot
  • the payment processing corresponding to the account will be relatively slow, which will affect the processing speed of payment requests corresponding to other merchants with low concurrent requests, making the processing efficiency of the payment request processing system low.
  • you can implement the third solution to handle the payment request under the high concurrency situation and use the batch solution to handle the payment request under the ultra-high concurrency situation. Executing the processing flow corresponding to the payment request according to the target payment plan can not only improve the processing efficiency of the payment request, but also improve the payment experience of merchants with different degrees of concurrency.
  • the payment request processing method of this embodiment when receiving the payment request, determines the corresponding merchant and the current payment plan, and judges whether the current payment plan is a batch plan; if it is not a batch plan, then compare the merchant TPS with the current payment plan. Compare the TPS threshold of the payment plan to determine the merchant’s plan switching direction; determine whether there is a pending alternative matching the plan switching direction among the merchant’s preset payment options; if it exists, determine the target payment plan , and switch the current payment plan to the target payment plan; execute the target payment plan to complete the corresponding payment process.
  • the merchant's current payment scheme is switched to the adapted target payment scheme, so as to process payment requests of different concurrency levels in a timely manner, and improve the processing efficiency of payment requests.
  • the difference between the second embodiment of the proxy payment request processing method and the first embodiment of the proxy payment request processing method is that the direction of the scheme switching is to switch to a preset alternative payment scheme with a larger preset TPS threshold, and the The step of determining the merchant's target payment plan from the pending options includes:
  • Step c1 according to the preset TPS thresholds corresponding to each of the pending options, sequentially acquire pending options with larger preset TPS thresholds, and determine whether the currently acquired pending options are preset batch solutions;
  • Step c2 if the currently acquired pending option is not a preset batch solution, then compare the TPS of the merchant with the preset TPS threshold corresponding to the currently acquired pending option;
  • Step c3 when the merchant's TPS is less than or equal to the preset TPS threshold corresponding to the currently acquired pending alternatives, determine whether the merchant's current payment plan can be switched to the currently acquired pending alternatives , if it can be switched, then determine the currently acquired preset payment option as the target payment plan of the merchant;
  • Step c4 when the TPS of the merchant is greater than the preset TPS threshold value corresponding to the currently acquired pending option, or the merchant's current payment plan cannot be switched to the currently acquired pending option, obtain the next A pending alternative that presets a larger TPS threshold and repeats the above steps of determining the merchant's target payment plan.
  • the scheme with a higher throughput than the current payment scheme is obtained one by one. judge.
  • the throughput corresponding to each preset payment option can be determined by pairwise comparison according to the TPS threshold corresponding to the preset payment options , generally speaking, the preset payment option with a relatively large TPS threshold has a larger corresponding throughput; then each preset payment option can be sorted in descending/ascending order according to the throughput Sort.
  • the optional payment schemes include scheme 1, scheme 2 and scheme 3. If the current payment scheme of merchant 1 is scheme 1, that is, the current payment scheme of merchant 1 is the payment scheme with the smallest throughput, not the batch scheme, then it can be determined The merchant can switch to Plan 2 or Plan 3 with higher throughput.
  • the first option to be obtained is Plan 2, not a batch plan, then compare the current TPS of Merchant 1 with the TPS threshold configured by Merchant 1 in Plan 2, if the comparison result is the TPS of Merchant 1 Less than or equal to the TPS threshold configured by Merchant 1 in Plan 2. Since Plan 2 will still be controlled by the overall TPS, it is necessary to further determine whether to switch to Plan 2. If you can switch to Plan 2, then determine that the currently obtained Plan 2 is determined to be the target payment plan for Merchant 1; if the comparison result is that the TPS of Merchant 1 is greater than the TPS threshold configured by Merchant 1 in Plan 2, or, in further judgment If it is determined whether to switch to Plan 2 or not, continue to obtain the next pending alternative with greater throughput, that is, Plan 3.
  • the preset alternative payment schemes of merchant 4 after sorting include scheme two, scheme three and batch schemes, if the current The payment scheme is scheme 2, that is, the current payment scheme of merchant 4 is the payment scheme with the smallest throughput, then it can be determined that the merchant can switch to scheme 3 or batch scheme with higher throughput.
  • whether to switch to plan 3 or batch plan depends on the current real-time TPS.
  • the undetermined option to be obtained is plan three, not a batch plan
  • the TPS of the merchant is less than or equal to the TPS threshold corresponding to which option to be determined, and the TPS of the merchant is closest to the TPS threshold corresponding to the solution to be switched, that is, to determine the TPS threshold corresponding to the TPS threshold
  • the default alternative payment scheme is the target payment scheme corresponding to the merchant.
  • the step of judging whether the currently acquired pending option is a preset batch plan it also includes:
  • Step d if the currently acquired pending option is the preset batch option, then determine the currently acquired pending option as the merchant's target payment plan, and switch the merchant's current payment plan Payment scheme for said goal.
  • the merchant's current payment plan is directly switched to a batch plan.
  • the current payment plan of Merchant 4 is Plan 3
  • it is determined to switch Merchant 4 to a payment plan with a higher throughput then, for Merchant 4, Firstly, the pending optional plan obtained must be a batch plan, and if it is not a batch plan, the current payment plan of the merchant 4 is directly switched to the batch plan, that is, the batch plan is determined as the target payment plan corresponding to the merchant 4.
  • the switching direction of the plan is to switch to a preset alternative payment option with a smaller preset TPS threshold
  • the step of determining the target payment option of the merchant from the pending alternatives includes:
  • Step e1 according to the preset TPS threshold corresponding to each of the pending alternatives, sequentially obtain pending alternatives with smaller preset TPS thresholds, and judge whether the currently acquired pending alternatives belong to the preset TPS total value limit scheme;
  • Step e2 if the currently obtained pending options do not belong to the preset TPS total value limit solution, then determine the currently obtained pending options as the merchant's target payment plan.
  • the scheme three and the batch scheme of this embodiment are suitable for handling payment request processing scenarios with high concurrency and ultra-high concurrency, and are not controlled by the total TPS, if the currently obtained optional scheme is not scheme one Or plan two, it can be determined that the merchant’s payment with money plan is a batch plan, and the currently obtained pending option is plan three, as shown in Figure 4, merchant 6 with the merchant number 0000006. If the TPS of Merchant 6 is less than or equal to the TPS threshold configured by Merchant 6 in Scheme 3, then Scheme 3 can be directly determined as the target payment scheme of Merchant 6, otherwise, the payment scheme of Merchant 6 will continue to be a batch scheme.
  • the step of judging whether the currently acquired pending options belong to the preset TPS total value limit scheme it also includes:
  • Step f1 if the currently obtained pending alternatives belong to the preset TPS total value limit scheme, then according to the currently acquired TPS total value of the pending alternatives and the TPS of the merchant, it is judged whether the The current payment plan of the above-mentioned merchant is switched to the currently obtained pending optional plan;
  • Step f2 if it can be switched, then determine the currently obtained pending alternative plan as the merchant's target payment plan;
  • Step f3 if the switch cannot be made, obtain the next pending option with a smaller preset TPS threshold and repeat the above-mentioned steps of determining the target payment plan of the merchant.
  • the currently obtained pending options belong to the preset TPS total value limit plan, that is, the currently obtained pending options are Plan 1 or Plan 2, it is necessary to further determine whether the merchant's current The payment plan is switched to the currently obtained pending optional plan. If it can be switched, the currently obtained pending optional plan will be determined as the merchant’s target payment plan. If it cannot be switched, continue to obtain the next smaller throughput. , and repeat the above switching judgment process.
  • the scheme switching process when the scheme switching process is performed on the merchant, it is sequentially judged whether to switch the current payment scheme of the merchant to each pending optional scheme, so as to switch the current payment scheme of the merchant to the matching scheme.
  • the optional preset payment alternative scheme ensures that the corresponding payment request of the merchant can be processed in time as much as possible, thereby improving the processing efficiency of the payment request processing system.
  • the difference between the third embodiment of the proxy payment request processing method and the first and second embodiments of the proxy payment request processing method is that after the step of judging whether the current proxy payment plan of the merchant is a preset batch plan, it also includes:
  • Step g1 if the current payment plan is a preset batch plan, then obtain the merchant’s preset payment options, and select from the merchant’s default payment options that are more corresponding to the current payment plan A pending option with a smaller preset TPS threshold;
  • Step g2 according to the preset TPS thresholds corresponding to each of the pending options, sequentially acquire the pending options with smaller preset TPS thresholds, and determine whether the merchant’s current payment plan can be switched to the currently acquired Arrived pending options;
  • Step g3 if it can be switched to the currently obtained pending optional plan, then determine the currently obtained optional payment plan as the target payment plan of the merchant;
  • Step g4 if it is not possible to switch to any of the pending alternatives, then maintain the current payment plan of the merchant.
  • the current merchant when performing scheme switching processing on a merchant, first determine whether the current merchant can dynamically switch schemes by querying the preset merchant configuration table; The payment plan remains unchanged; if the plan can be dynamically switched, it is judged whether the current payment plan of the current merchant is a batch plan. Since the batch plan does not have a corresponding TPS threshold, if the current payment plan of the current merchant is a batch plan, then determine the The merchant can only switch to a solution with a lower throughput. For the specific switching process, refer to the switching judgment process for mechanically switching to a solution with a smaller throughput in the second embodiment. Switch to any pending alternative with smaller throughput, then it is determined that the merchant's payment plan continues to be a batch plan.
  • the current payment scheme is not a batch scheme, then judge whether the merchant’s TPS exceeds the TPS upper threshold of the current payment scheme; if the current merchant’s TPS exceeds the TPS upper threshold of the current payment scheme, query the preset merchant attribute extension Table, to obtain the list of preset payment alternatives of the current merchant, and query whether there is a pending alternative that is greater than the TPS threshold of the current merchant; if not, it means that the current payment plan of the merchant is the one with the largest current throughput If there is a preset payment option, keep the current payment plan unchanged; if there is a preset payment option with a larger throughput than the current payment plan, get the next preset payment option with a larger throughput Optional solution A; since in this embodiment, the batch solution corresponds to the largest throughput, therefore, if A is a batch solution, you can directly switch the merchant’s current payment plan to a batch solution; if A is not a batch solution, It is necessary to evaluate whether the merchant’s current payment scheme can be switched to A,
  • the TPS of the current merchant does not exceed the TPS upper limit threshold of the current payment plan, then further check whether the TPS of the current merchant is less than or equal to the TPS threshold corresponding to the pending alternative with smaller throughput; if it is less than or equal to, then sort according to The final pending option obtains the next pending option C with a smaller throughput, and judges whether C is option 1 or option 2; if C is option 1 or option 2, it is necessary to evaluate whether the merchant’s current If the payment plan is switched to C, it is judged that if the current payment plan is switched to C, whether the current TPS will exceed the total TPS value corresponding to C; if the current TPS will not exceed the total TPS value corresponding to C, then the The merchant’s current payment plan is switched to C; if the current TPS exceeds the total TPS value corresponding to C, continue to obtain the next pending option D with a smaller throughput from the sorted pending options, based on the above similar In the evaluation process, it is determined whether the evaluation process
  • a polling detection mechanism can also be set, and when the preset polling time is reached, the Check whether the merchant can switch to the corresponding pending alternative plan. For example, it can be judged whether the time since the last pre-switched plan of the merchant but the actual failure to switch the plan has exceeded the preset plan switching interval. If it exceeds the preset If the scheme switching interval is set, execute the scheme switching process. Inquiring whether merchants can switch plans through the rotation training mechanism can improve the flexibility of the payment request processing system and further improve the processing efficiency of the payment request processing system.
  • the payment request processing method of this embodiment if the current payment plan of the merchant is a batch plan, then switch to a plan with a larger throughput to determine the most suitable payment plan for the merchant, and ensure that the payment request is processed While maintaining system stability, it can also improve the processing efficiency of payment requests.
  • step S50 Also includes:
  • Step h1 performing state initialization processing on the payment flow corresponding to the payment request, so as to initialize the current processing state of the payment flow to a preset initial processing state;
  • Step h2 storing the proxy payment flow in a preset database, and sending the request information corresponding to the proxy payment flow to the message queue corresponding to the merchant;
  • Step h3 take out the proxy payment flow from the preset database through the listening thread corresponding to the message queue, and send the proxy payment flow to the deposit core for the deposit core to use according to the target
  • the proxy payment scheme performs proxy payment processing on the proxy payment flow to complete the processing flow corresponding to the proxy payment request.
  • FIG. 8 is a flow chart of payment processing corresponding to a preferred embodiment (solution 3) of the method for processing a payment request in this application. Since a message queue will be configured for each merchant in Scheme 3, the message queue can include RocketMQ, ActiveMQ, RibbitMQ, etc.
  • the current processing status of the payment flow can be initialized to "I-to be processed".
  • the default database is preferably the payment flow table.
  • the The request message corresponding to the payment request is sent to the message queue corresponding to the merchant, wherein the request information may include information such as a unique identifier corresponding to the payment request, a message corresponding to the payment request, and the like.
  • the listening thread corresponding to the message queue receives the message of the message queue, it returns a successful response, and assembles the payment request and sends it to the deposit core, and the deposit core performs subsequent payment processing, and the deposit core performs the payment processing process It is similar to Scheme 1 and Scheme 2 and will not be repeated here.
  • the payment request processing system includes a preset task thread, after the step of storing the payment flow in the preset database, it also includes:
  • Step i1 judge whether there is a target payment flow in the preset database that exceeds the preset waiting processing time through the preset pocket task thread;
  • Step i2 if it exists, take out the target payment flow from the preset database through the preset pocket task thread, and send the target payment flow to the deposit core for the deposit core to The target agency payment flow is used for agency payment processing.
  • real-time or timing tasks can be used to ensure that the messages in the message queue will not be lost. It is understandable that since the message queue can be a special message middleware or a simple memory message queue, etc., however, these message queues cannot fully guarantee that messages will not be lost. Therefore, in order to ensure that messages in the message queue will not be lost, it is necessary to set up a pocket task thread to scan the preset database.
  • the pocket task is preferably a pocket timing task;
  • the preset database can be It is a payment flow meter or a one-to-one transfer flow meter.
  • the default database can be determined according to the degree of concurrency corresponding to the payment plan currently running by the merchant.
  • the proxy payment request is stored in the proxy payment flow table. Therefore, you can scan the proxy payment flow table through the pocket timing task thread to query the target proxy payment log that exceeds the preset waiting processing time; if the current target proxy payment
  • the plan is a batch plan.
  • the payment request is stored in the one-to-one transfer flow table in addition to the payment flow meter.
  • the subsequent assembly payment request is sent to the deposit core, it can be Obtain the agency payment flow directly from the one-to-one transfer flow table.
  • the pocket timing task thread can scan the one-to-one transfer flow table to query the target payment flow that exceeds the preset waiting processing time, and then pass The bottom-up task thread sends the withdrawn target payment flow to the deposit core, so that the deposit core can perform subsequent payment processing on the target payment flow. It is beneficial to improve the robustness of the system to cover the payment flow that exceeds the preset waiting processing time through the bottom-up task.
  • the method for processing payment requests in this embodiment can isolate high-concurrency payment requests by setting a corresponding message queue for each high-concurrency merchant, so as to ensure that other payment requests from non-high-concurrency merchants can be processed in a timely manner. Processing to improve the processing capacity of non-highly concurrent merchant payment requests; you can also query and process target payment requests in the preset database that exceed the preset waiting processing time through the preset task thread to ensure that messages in the message queue will not be lost , which is conducive to improving the robustness of the system.
  • the difference between the fifth embodiment of the payment request processing method and the first, second, third, and fourth embodiments of the payment request processing method is that the method further includes:
  • Step j1 extracting from the preset database the pending payment flow whose current processing state is the preset initial processing state, and performing payment processing on the pending payment flow to obtain the corresponding payment processing state;
  • Step j2 updating the current processing state of the pending payment flow to the processing state of the payment
  • Step j3 when the payment processing statuses corresponding to the payment journals in the preset database are all preset processing completion statuses, send the payment journals to be processed after the processing to the deposit core for all The deposit core performs payment processing on the pending payment flow after the processing is completed.
  • the payment transaction to be processed can be obtained according to the corresponding primary key of the payment transaction table, where the primary key is the primary key, and the payment transaction table can be uniquely determined according to the primary key A row of data in , that is, a payment transaction.
  • FIG. 9 is a flow chart of concurrency control in a preferred embodiment (Scheme 3) of the payment request processing method of the present application.
  • Scheme 3 When performing payment processing through Scheme 3, add a new field concurrent_status to the payment flow table to perform concurrency control.
  • one-to-one transfer records can be assembled by querying the list of agency payment records whose concurrent_status status is "I-pending”, and then extracting the corresponding agency payment records from the queried list of agency payment records in chronological order , and update the concurrent_status status of the currently processed payment flow to "P-processing"; after detecting that the concurrent_status status of the currently processed payment flow is successfully updated to "P-processing", the assembled one-to-one transfer Send the transaction to the deposit core, and then update the concurrent_status status of the payment transaction to "S-processed”; after the update is successful, check whether the currently processed payment transaction is the last one in the payment transaction list; if the current processing If the agency payment journal is the last one in the agency payment journal list, the concurrent control process of this agency payment journal will be ended; From the transaction list, take out the corresponding payment transactions in order of time to assemble the one-to
  • Payment processing status that is, when it is detected that the payment processing statuses corresponding to the payment journals in the preset database are all in the preset processing completion status, the processing status update process corresponding to the payment journals in the preset database can be ended, And send the completed payment flow to the deposit core, so that the deposit core can carry out subsequent payment processing on the completed payment flow.
  • FIG. 11 is a flow chart of concurrency control in a preferred embodiment (batch scheme) of the payment request processing method of this application.
  • the difference from Scheme 3 is that when the batch scheme is used for concurrency control, the one-to-one transfer flow list is queried.
  • the pair whose batch status is "02-marked” is queried according to the merchant number and batch number One-to-one transfer flow list, sequentially extract the payment flow from the queried one-to-one transfer flow list to assemble the one-to-one transfer flow, and then gradually change the batch status of the one-to-one transfer flow according to the queried one-to-one transfer flow Update to "03-Assembling"; after the update is successful, assemble the current one-to-one transfer flow data into the core batch request message, and then update the batch status of the currently processed payment flow to "04-Assembled ", according to the above-mentioned concurrency control process, process the payment transactions in the one-to-one transfer transaction list sequentially, until the payment processing status of the payment transactions in the one-to-one transfer transaction list is all updated, then the assembled This batch of payment records is sent to the deposit core, and then the batch status of this batch of one-to-one transfer records is updated to "05-processed", that is, when the
  • the proxy payment request processing method of this embodiment when processing highly concurrent proxy payment requests, performs concurrency control by updating the proxy payment processing status of the proxy payment flow, which can improve the stability of the proxy payment request processing system and ensure the system's proxy payment request processing efficiency.
  • the difference between the sixth embodiment of the payment request processing method and the first, second, third, fourth, and fifth embodiments of the payment request processing method is that the target payment plan is a preset batch plan, so After the step of storing the payment flow in the preset database, it also includes:
  • Step k1 querying the batch payment flow whose current processing state is the preset initial processing state from the preset database, and generating a unified batch number corresponding to the batch payment flow;
  • Step k2 obtaining the merchant number in the batch payment flow, and sending the unified batch number and the merchant number to a preset target message queue;
  • Step k3 through the monitoring thread corresponding to the preset target message queue, take out the batch payment flow from the preset database according to the unified batch number and the merchant number, and assemble the batch corresponding to the batch flow
  • the request is sent to the deposit core for the deposit core to perform payment processing on the batch payment flow according to the batch request.
  • FIG. 10 is a payment processing flow chart of a preferred embodiment (batch solution) of the method for processing a payment request in this application. Different from scheme three, all merchants in the batch scheme share the same message queue. If it is detected that the merchant’s current payment plan is a batch plan, after the verification of the payment request is successful, the payment request will be directly stored in the payment flow meter and the one-to-one transfer flow meter, and the one-to-one transfer flow meter sent to the deposit core will be initialized.
  • One-to-one transfer flow table to initialize the batch_status status in this batch of one-to-one transfer flow table to "01-to be marked”, and then scan the one-to-one transfer flow table through the pocket timing task to obtain the batch_status status as "to be marked” "marking" of the payment flow, you can also pre-set the number of flow records obtained each time, such as obtaining a maximum of 30 payment flow records each time, generate a unique processing number batch_no, and update the batch_status status of the payment flow It is "02-marked” to update the batch_no of this batch of one-to-one transfers to the same unique batch number, that is, the unified batch number, and then send the merchant number and batch_no to the message queue.
  • the thread listening to the message queue When the thread listening to the message queue receives a message from the message queue, it takes out the merchant number and batch_no in the message queue, queries the one-to-one transfer flow table according to the merchant number and batch_no, takes out this batch of one-to-one transfer flow, and assembles the batch request in a loop
  • the message is sent to the deposit core, and the corresponding processing result is obtained after the deposit core, or the deposit core and the unified payment platform are processed, and then the one-to-one transfer flow is processed cyclically based on the above-mentioned processing flow, thereby completing the one-to-one transfer flow in batches payment processing flow.
  • the payment processing process of the deposit core is similar to the above, and will not be repeated here.
  • the payment request processing method in this embodiment assembles batch payment requests from the dimension of merchants through the batch scheme, and one or more merchants in the batch scheme share the same Isolating the payment request can also improve the processing speed of the payment request group of ultra-high concurrent merchants.
  • the payment request processing device of this application includes:
  • the first judging module 10 is used to determine the merchant corresponding to the payment request and the current payment plan of the merchant when receiving the payment request, and determine whether the current payment plan of the merchant is preset batch plan;
  • the comparison and determination module 20 is used to compare the TPS of the merchant with the preset TPS threshold corresponding to the current payment plan if the current payment plan is not a preset batch plan, and determine the plan switch of the merchant according to the comparison result Direction, the TPS of the merchant is the number of payment requests processed by the merchant within a unit time;
  • the second judging module 30 is used to acquire the preset alternative payment alternatives of the merchant, and determine whether there is a pending alternative matching the scheme switching direction among the preset alternative payment alternatives;
  • the scheme switching module 40 is configured to determine the target payment scheme of the merchant from the pending alternative schemes, if it exists, and switch the current payment scheme of the merchant to the target payment scheme;
  • the payment execution module 50 is configured to execute the target payment plan, so as to complete the processing flow corresponding to the payment request.
  • the comparison determination module is also used for:
  • the comparison result is that the TPS of the merchant is greater than the preset TPS threshold corresponding to the current payment scheme, then it is determined that the scheme switching direction of the merchant is to switch to a preset payment option with a larger preset TPS threshold;
  • the comparison result is that the merchant's TPS is less than or equal to the preset TPS threshold corresponding to the current payment plan, then it is determined that the merchant's plan switching direction is to switch to a preset payment option with a smaller preset TPS threshold.
  • the scheme switching module is also used for:
  • the preset TPS threshold value corresponding to each of the pending optional solutions sequentially acquire pending optional solutions with larger preset TPS thresholds, and determine whether the currently acquired pending optional solutions are preset batch solutions;
  • the currently obtained pending optional solution is not a preset batch solution, then compare the TPS of the merchant with the preset TPS threshold corresponding to the currently obtained pending optional solution;
  • the TPS of the merchant is less than or equal to the preset TPS threshold corresponding to the currently acquired pending alternative, determine whether the current payment plan of the merchant can be switched to the currently acquired pending alternative, if possible switch, then determine the currently acquired preset payment option as the target payment plan of the merchant;
  • the merchant's TPS When the merchant's TPS is greater than the preset TPS threshold corresponding to the currently acquired pending alternatives, or the merchant's current payment plan cannot be switched to the currently acquired pending alternatives, obtain the next preset For the option to be determined with a larger TPS threshold, repeat the above-mentioned steps of determining the target payment plan of the merchant.
  • the scheme switching module is also used for:
  • the preset TPS thresholds corresponding to each of the pending options sequentially acquire pending options with smaller preset TPS thresholds, and determine whether the currently acquired pending options belong to the preset TPS total limit solution ;
  • the currently obtained pending optional scheme does not belong to the preset TPS total value limit scheme, then determine the currently acquired pending optional scheme as the merchant's target payment scheme.
  • the scheme switching module further includes a total value judging unit, and the total value judging unit is used for:
  • the currently obtained pending alternatives belong to the preset TPS total value limit scheme, then according to the currently obtained TPS total value of the pending alternatives and the TPS of the merchant, it is judged whether The current payment plan is switched to the currently obtained pending optional plan;
  • the first judging module further includes a batch scheme judging unit, and the batch scheme judging is used for:
  • the current payment plan is a preset batch plan, then obtain the merchant’s preset payment alternative plan, and filter out the default payment plan corresponding to the current payment plan from the merchant’s preset payment option plan A pending alternative with a smaller TPS threshold;
  • the payment request processing device further includes a deposit core, and the payment execution module is used for:
  • the payment request processing device further includes a concurrency control module, and the concurrency control module is used for:
  • the payment records to be processed after the processing are completed are sent to the deposit core for the deposit core Perform payment processing on the pending payment flow after the processing is completed.
  • the payment execution module further includes a batch payment unit, and the batch payment unit is used for:
  • the listening thread corresponding to the preset target message queue retrieves the batch payment flow from the preset database, and assembles the batch request corresponding to the batch flow and sends it to The deposit core is used for the deposit core to perform payment processing on the batch payment flow according to the batch request.
  • the present application also provides a computer program product, including a computer program.
  • a computer program product including a computer program.
  • the computer program is executed by a processor, the steps of the above-mentioned payment request processing method are implemented.
  • the present application also provides a storage medium.
  • the payment request processing program is stored on the storage medium of the present application, and when the payment request processing program is executed by the processor, the steps of the above-mentioned payment request processing method are realized.
  • the various embodiments of the payment request processing system, the computer program product, and the storage medium of the present application can refer to the various embodiments of the payment request processing method of the present application, which will not be repeated here.
  • the methods of the above embodiments can be implemented by means of software plus a necessary general-purpose hardware platform, and of course also by hardware, but in many cases the former is better implementation.
  • the technical solution of the present application can be embodied in the form of a software product in essence or the part that contributes to the prior art, and the computer software product is stored in a storage medium as described above (such as ROM/RAM , magnetic disk, optical disk), including several instructions to make a terminal system (which can be a mobile phone, computer, server, air conditioner, or network system, etc.) execute the methods described in various embodiments of the present application.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

本申请涉及金融科技(Fintech)技术领域，公开了一种代付请求处理方法及***，当接收到代付请求时，确定对应的商户和当前代付方案，判断当前代付方案是否为批量方案；若不是批量方案，则将商户TPS与当前代付方案的TPS阈值进行比较，以确定商户的方案切换方向；判断商户的预设代付可选方案中是否存在与方案切换方向相匹配的待定可选方案；若存在，则确定目标代付方案，并将当前代付方案切换为目标代付方案；执行目标代付方案，以完成对应的代付处理流程。

Description

代付请求处理方法及***
优先权信息
本申请要求于2021年6月21日申请的、申请号为202110686622.4的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及金融科技(Fintech)技术领域，尤其涉及代付请求处理方法及***。
背景技术
随着计算机技术的发展，越来越多的技术(大数据、分布式、人工智能等)应用在金融领域，传统金融业正在逐步向金融科技(Fintech)转变，但由于金融行业的安全性、通用性要求，也对代付请求处理技术提出了更高的要求。
目前，为了保证代付请求处理过程中账户数据的准确性，银行机构在进行记账处理时，会先对账户的资源加锁，待记账处理完毕后自动释放锁。而随着处理业务量的增大，数据库中的账户常常会在短时间内产生多个并发操作，但在实际的代付处理过程中，只有一个线程能够持有当前账户的资源锁，而其他线程必须等待该锁被释放后再逐一进行记账处理，使得该账户被频繁加锁释放锁，即高频进行扣款、入账处理等代付处理流程，从而成为代付请求处理***中的热点账户，这会严重影响到其他账户代付请求的处理速度，导致代付请求的处理效率低下。
发明内容
本申请的主要目的在于提出一种代付请求处理方法及***，旨在提高代付请求的处理效率，尤其是高并发代付请求对应的处理效率。
为实现上述目的，本申请提供一种代付请求处理方法，所述方法包括如下步骤：
当接收到代付请求时，确定所述代付请求对应的商户，以及所述商户的当前代付方案，并判断所述商户的当前代付方案是否为预设批量方案；
若当前代付方案不是预设批量方案，则将所述商户的TPS与当前代付方案对应的预设TPS阈值进行比较，并根据比较结果确定所述商户的方案切换方向，所述商户的TPS为单位时间内处理的所述商户的代付请求数；
获取所述商户的预设代付可选方案，并判断所述预设代付可选方案中是否存在与所述方案切换方向相匹配的待定可选方案；
若存在，则从所述待定可选方案中确定所述商户的目标代付方案，并将所述商户的当前代付方案切换为所述目标代付方案；
执行所述目标代付方案，以完成所述代付请求对应的处理流程。
在一实施例中，所述根据比较结果确定所述商户的方案切换方向的步骤包括：
若比较结果为所述商户的TPS大于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更大的预设代付可选方案切换；
若比较结果为所述商户的TPS小于或等于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更小的预设代付可选方案切换。
在一实施例中，所述方案切换方向为向预设TPS阈值更大的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：
根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更大的待定可选方案，并判断当前获取到的待定可选方案是否为预设批量方案；
若当前获取到的待定可选方案不为预设批量方案，则将所述商户的TPS与当前获取到的待定可选方案对应的预设TPS阈值进行比较；
当所述商户的TPS小于或等于当前获取到的待定可选方案对应的预设TPS阈值时，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案，若能切换，则将当前获取到的预设代付可选方案确定为所述商户的目标代付方案；
当所述商户的TPS大于当前获取到的待定可选方案对应的预设TPS阈值，或者不能将所述商户的当前代付方案切换为当前获取到的待定可选方案时，获取下一个预设TPS阈值更大的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。
在一实施例中，所述方案切换方向为向预设TPS阈值更小的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：
根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案；
若当前获取到的待定可选方案不属于所述预设的TPS总值限制方案，则将当前获取到的待定可选方案确定为所述商户的目标代付方案。
在一实施例中，所述判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案的步骤之后，还包括：
若当前获取到的待定可选方案属于所述预设的TPS总值限制方案，则根据当前获取到的待定可选方案的TPS总值和所述商户的TPS，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；
若能切换，则将当前获取到的待定可选方案确定为所述商户的目标代付方案；
若不能切换，则获取下一个预设TPS阈值更小的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。
在一实施例中，所述判断所述商户的当前代付方案是否为预设批量方案的步骤之后，还包括：
若当前代付方案是预设批量方案，则获取所述商户的预设代付可选方案，并从所述商户的预设代付可选方案中筛选出比当前代付方案对应的预设TPS阈值更小的待定可选方案；
根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；
若能切换为当前获取到的待定可选方案，则将当前获取到的代付可选方案确定为所述商户的目标代付方案；
若不能切换为任一待定可选方案，则维持所述商户的当前代付方案。
在一实施例中，应用于代付请求处理***，所述代付请求处理***包括存款核心，所述执行所述目标代付方案，以完成所述代付请求对应的处理流程的步骤包括：
对所述代付请求对应的代付流水进行状态初始化处理，以将所述代付流水的当前处理状态初始化为预设初始处理状态；
将所述代付流水存储至预设数据库，并将所述代付流水对应的请求信息发送给所述商户对应的消息队列；
通过所述消息队列对应的监听线程从所述预设数据库中取出所述代付流水，并将所述代付流水发往所述存款核心，以供所述存款核心根据所述目标代付方案对所述代付流水进行代付处理，完成所述代付请求对应的处理流程。
在一实施例中，所述方法还包括：
从所述预设数据库中取出当前处理状态为预设初始处理状态的待处理代付流水，并对所述待处理代付流水进行代付处理，得到对应的代付处理状态；
将所述待处理代付流水的当前处理状态更新为所述代付处理状态；
当所述预设数据库中的代付流水对应的代付处理状态均为预设处理完成状态时，则将处理完成后的待处理代付流水发往所述存款核心，以供所述存款核心对所述处理完成后的待处理代付流水进行代付处理。
在一实施例中，所述目标代付方案为预设批量方案，所述将所述代付流水存储至预设数据库的步骤之后，还包括：
从所述预设数据库中查询当前处理状态为预设初始处理状态的批量代付流水，并生成所述批量代付流水对应的统一批次号；
获取所述批量代付流水中的商户号，将所述统一批次号和所述商户号发送给预设目标消息队列；
通过所述预设目标消息队列对应的监听线程根据所述统一批次号和所述商户号从所述预设数据库取出所述批量代付流水，并组装所述批量流水对应的批量请求发往所述存款核心，以供所述存款核心根据所述批量请求对所述批量代付流水进行代付处理。
此外，为实现上述目的，本申请还提供一种代付请求处理装置，所述代付请求处理装置包括：
第一判断模块，用于当接收到代付请求时，确定所述代付请求对应的商户，以及所述商户的当前代付方案，并判断所述商户的当前代付方案是否为预设批量方案；
比较确定模块，用于若当前代付方案不是预设批量方案，则将所述商户的TPS与当前代付方案对应的预设TPS阈值进行比较，并根据比较结果确定所述商户的方案切换方向，所述商户的TPS为单位时间内处理的所述商户的代付请求数；
第二判断模块，用于获取所述商户的预设代付可选方案，并判断所述预设代付可选方案中是否存在与所述方案切换方向相匹配的待定可选方案；
方案切换模块，用于若存在，则从所述待定可选方案中确定所述商户的目标代付方案，并将所述商户的当前代付方案切换为所述目标代付方案；
代付执行模块，用于执行所述目标代付方案，以完成所述代付请求对应的处理流程。
此外，为实现上述目的，本申请还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上所述的代付请求处理方法的步骤。
此外，为实现上述目的，本申请还提供一种代付请求处理***，所述代付请求处理***包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的代付请求处理程序，所述代付请求处理程序被所述处理器执行时实现如上所述的代付请求处理方法的步骤。
此外，为实现上述目的，本申请还提供一种存储介质，所述存储介质上存储有代付请求处理程序，所述代付请求处理程序被处理器执行时实现如上所述的代付请求处理方法的步骤。
本申请提出的代付请求处理方法，当接收到代付请求时，确定对应的商户和当前代付方案，判断当前代付方案是否为批量方案；若不是批量方案，则将商户TPS与当前代付方案的TPS阈值进行比较，以确定商户的方案切换方向；判断商户的预设代付可选方案中是否存在与方案切换方向相匹配的待定可选方案；若存在，则确定目标代付方案，并将当前代付方案切换为目标代付方案；执行目标代付方案，以完成对应的代付处理流程。通过动态地对商户进行方案切换处理，将商户的当前代付方案切换到适配的目标代付方案，以及时处理不同并发程度的代付请求，提高代付请求的处理效率。
附图说明
图1是本申请实例方案涉及的硬件运行环境的***结构示意图；
图2为本申请代付请求处理方法第一实施例的流程示意图；
图3为本申请代付请求处理方法较佳实施例的商户配置表；
图4为本申请代付请求处理方法较佳实施例的商户属性扩展表；
图5为本申请代付请求处理方法较佳实施例(方案一)的代付处理流程图；
图6为本申请代付请求处理方法较佳实施例(方案二)的代付处理流程图；
图7为本申请代付请求处理方法较佳实施例的方案切换处理流程图；
图8为本申请代付请求处理方法较佳实施例(方案三)的代付处理流程图；
图9为本申请代付请求处理方法较佳实施例(方案三)的并发控制流程图；
图10为本申请代付请求处理方法较佳实施例(批量方案)的代付处理流程图；
图11为本申请代付请求处理方法较佳实施例(批量方案)的并发控制流程图；
图12为本申请代付请求处理方法较佳实施例的功能模块示意图。
本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
如图1所示，图1是本申请实施例方案涉及的硬件运行环境的***结构示意图。
本申请实施例***可以是管理服务器、PC端、移动设备等。
如图1所示，该***可以包括：处理器1001，例如CPU，网络接口1004，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard)，可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。
本领域技术人员可以理解，图1中示出的***结构并不构成对***的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
如图1所示，作为一种计算机存储介质的存储器1005中可以包括操作***、网络通信模块、用户接口模块以及代付请求处理程序。
其中，操作***是管理和控制代付请求处理***与软件资源的程序，支持网络通信模块、用户接口模块、代付请求处理程序以及其他程序或软件的运行；网络通信模块用于管理和控制网络接口1002；用户接口模块用于管理和控制用户接口1003。
在图1所示的代付请求处理***中，所述代付请求处理***通过处理器1001调用存储器1005中存储的代付请求处理程序，并执行下述代付请求处理方法各个实施例中的操作。
基于上述硬件结构，提出本申请代付请求处理方法实施例。
参照图2，图2为本申请代付请求处理方法第一实施例的流程示意图，所述方法包括：
步骤S10，当接收到代付请求时，确定所述代付请求对应的商户，以及所述商户的当前代付方案， 并判断所述商户的当前代付方案是否为预设批量方案；
本实施例代付请求处理方法运用于各大金融机构的代付请求处理***中。为描述方便，以银行机构的代付处理过程为例进行阐述，那么，在本实施例中的代付，是指客户从本行的账户向指定的银行卡账户进行款项划付的业务。目前，为了保证代付请求处理过程中账户数据的准确性，银行机构在进行记账处理时，会先对账户的资源加锁，待记账处理完毕后自动释放锁。而随着处理业务量的增大，数据库中的账户常常会在短时间内产生多个并发操作，但在实际的代付处理过程中，只有一个线程能够持有当前账户的资源锁，而其他线程必须等待该锁被释放后再逐一进行记账处理，使得该账户被频繁加锁释放锁，即高频进行扣款、入账处理等代付处理流程，从而成为代付请求处理***中的热点账户，这会严重影响到其他账户代付请求的处理速度，导致代付请求的处理效率低下。
在本实施例中，可预先根据本银行机构的合作商户所提供的初步预估的代付请求并发量来配置一张商户配置表，如图3所示，可在商户配置表配置商户号、代付方案类型、消息队列主题topic、代付方案是否可动态切换等内容，其中，不同商户号对应不同的商户。为描述方便，若按照商户并发量升序的方式进行排序，以本实施例的代付方案类型包括方案一、方案二、方案三和批量方案为例进行阐述，其中，方案一和方案二用于处理低并发或正常并发情况的代付请求，方案三和批量方案用于处理高并发情况下的代付请求。当接收到代付请求时，可根据代付请求中携带的商户号确定该代付请求对应的商户，并查询商户配置表中该商户对应的代付方案类型，即可确定该商户对应的当前代付方案，当然，在对商户进行方案切换处理之前，需要先查询商户配置表，以确定该商户是否可以动态切换方案，即确定该商户是否拥有方案切换权限。如图3的商户配置表所示，商户号为0000001的商户可进行动态切换，即说明该商户拥有方案切换权限，则可将该商户的当前代付方案切换为另一个代付方案；而商户号为0000002的商户不能进行动态切换，即说明该商户不拥有方案切换权限，则无论该商户的TPS如何变化，都会维持当前代付方案。因此，只有在商户配置表中查询到该商户能动态切换方案，即该商户拥有方案切换权限时，才能对该商户进行方案切换处理，故本实施例中的方案切换处理流程主要是针对具有方案切换权限的商户提出的。
另外，若商户的预设代付可选方案包括方案一、方案二、方案三和批量方案，可分别为方案一、方案二和方案三设置对应的TPS阈值，由于批量方案(预设批量方案)对应的吞吐量最大，故批量方案没有对应的TPS阈值，因此在对该商户进行方案切换处理时，还需要判断该商户的当前代付方案是否为预设批量方案，以将不需要将该商户的TPS和当前代付方案对应的TPS阈值进行比较的批量方案和其他方案(方案一、方案二和方案三)区分开来。
需要说明的是，和方案三不同的是，批量方案的消息队列只有一个，也即，当前代付方案为批量方案的所有商户，其对应的代付请求都共用同一个消息队列，所以无需为每个商户配置一个消息队列。但是，在设置商户配置表时，如对于方案三，也可为每个商户配置一个消息队列，从而达到各商户之间隔离的目的。当然，代付方案的类型和数量可根据实际情况进行设定，本申请对此不作具体限制。
步骤S20，若当前代付方案不是预设批量方案，则将所述商户的TPS与当前代付方案对应的预设TPS阈值进行比较，并根据比较结果确定所述商户的方案切换方向，所述商户的TPS为单位时间内处理的所述商户的代付请求数；
在本实施例中，单位时间内处理的商户的代付请求数，即商户的TPS(Transactions Per Second)，商户的TPS可以代表商户当前的并发量；TPS阈值指的是TPS上限值。由于预设代付可选方案中包含该商户的当前代付方案，该商户可能存在吞吐量比当前代付方案的吞吐量更大和/或更小的其他预设代付可选方案，因此，该商户对应的方案切换方向包括向吞吐量更大的预设代付可选方案切换或向吞吐量更小的预设代付可选方案切换。具体的，若确定商户的当前代付方案不是批量方案，即该商户的当前代付方案是方案一或方案二或方案三，则将商户当前的TPS与当前代付方案对应的TPS阈值进行比较，以根据比较结果确定该商户的方案切换方向，从而提高代付请求的处理效率，并提升用户体验。
进一步地，所述根据比较结果确定所述商户的方案切换方向的步骤包括：
步骤a1，若比较结果为所述商户的TPS大于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更大的预设代付可选方案切换；
步骤a2，若比较结果为所述商户的TPS小于或等于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更小的预设代付可选方案切换。
在本实施例中，若商户的TPS大于当前代付方案对应的预设TPS阈值，则确定该商户的方案切换方向为向预设TPS阈值更大的预设代付可选方案切换，也即，将该商户的当前代付方案往吞吐量更大的方案进行切换；若商户的TPS小于或等于当前代付方案对应的预设TPS阈值，由于需要对该商户进行方案切换处理，则确定该商户的方案切换方向为向预设TPS阈值更小的预设代付可选方案切换，也即，将该商户的当前代付方案往吞吐量更小的方案进行切换，以确定该商户最适配的代付方案。例如， 假设某商户配置的代付可选方案包括方案一、方案二、方案三和批量方案，且当前商户在方案一配置的TPS阈值为100，在方案二配置的TPS阈值为200，在方案三配置的TPS阈值为300，在批量方案不需要配置TPS阈值，因为批量方案无TPS上限值，且商户的当前代付方案是方案三，即当前商户的TPS小于300，如果检测到该商户的TPS升到400了，则直接切到批量方案；若该商户的TPS又下降到280，则将当前代付方案切换到方案三，如此类推。另外，如果该商户的TPS由280下降到50了，也可以直接将当前代付方案切换到方案一，也可以逐步将商户当前的TPS与待切换的方案对应的TPS阈值进行比较，从而确定商户当前的最适配方案。
步骤S30，获取所述商户的预设代付可选方案，并判断所述预设代付可选方案中是否存在与所述方案切换方向相匹配的待定可选方案；
在本实施例中，确定该商户往吞吐量更大/更小的方案进行切换之后，可从预先配置的商户属性扩展表中获取该商户的预设代付可选方案，如图4所示，商户属性扩展表中包括各个预设商户对应的预设代付可选方案，一般来说，预设代付可选方案包括商户的当前代付方案，然后判断预设代付可选方案中是否存在与该商户的方案切换方向相匹配的待定可选方案，具体的，若该商户的方案切换方向为向预设TPS阈值更大的预设代付可选方案切换，则判断该商户的预设代付可选方案中是否存在比当前代付方案吞吐量更大的代付方案；若该商户的方案切换方向为向预设TPS阈值更小的预设代付可选方案切换，则判断该商户的预设代付可选方案中是否存在比当前代付方案吞吐量更小的代付方案。例如，图4中商户号为0000004的商户拥有方案切换权限，且其对应的预设代付可选方案包括方案一、方案二和方案三，由于方案一、方案二和方案三对应的吞吐量是越来越大的，若该商户的当前代付方案为方案二，当确定该商户需要进行方案切换处理时，可根据该商户的方案切换方向，将方案一或方案三作为该商户对应的目标代付方案，如向吞吐量更小的方向进行切换时，将方案一作为待定可选方案；若向吞吐量更大的方向进行切换时，可将方案三作为待定可选方案。
步骤S40，若存在，则从所述待定可选方案中确定所述商户的目标代付方案，并将所述商户的当前代付方案切换为所述目标代付方案；
在本实施例中，若预设代付可选方案中存在与方案切换方向相匹配的待定可选方案，即说明理论上可将该商户的当前代付方案切换到另一待定可选方案，且待定可选方案至少包括一个代付方案，因此，可从待定可选方案中确定商户待切换的代付方案，即目标代付方案，并将该商户的当前代付方案切换为目标代付方案。为需要进行方案切换处理的商户动态切换到适配的方案，可尽可能地保证不同并发量的商户代付请求被及时处理，从而提高代付请求的处理效率。
进一步地，所述判断所述预设代付可选方案中是否存在与所述方案切换方向相匹配的待定可选方案的步骤之后，还包括：
步骤b，若不存在与所述方案切换方向相匹配的待定可选方案，则维持所述商户的当前代付方案，并执行当前代付方案，以完成所述代付请求对应的处理流程。
在本实施例中，若商户的预设代付可选方案中不存在与方案切换方向相匹配的待定可选方案，则说明该商户的当前代付方案已经是最适配的代付方案，只需要维持带钱代付方案即可，从而执行当前代付方案，以完成代付请求对应的处理流程。
步骤S50，执行所述目标代付方案，以完成所述代付请求对应的处理流程。
在本实施例中，代付请求处理***包括存款核心、统一支付平台等，其中，存款核心为银行的核心记账***；统一支付平台特指银行对内的统一支付平台***，用于将代付请求中的款项转入他行银行卡。目标代付方案可以是处理不同商户并发量的方案一、方案二、方案三、批量方案等代付方案中的一个方案，如图5所示，图5为本申请代付请求处理方法较佳实施例(方案一)的代付处理流程图。若目标代付方案为方案一，在接收到客户的代付请求后，首先对代付请求中的请求数据进行校验，如校验请求数据对应的商户与发送该代付请求的商户是否匹配、请求数据是否为空、数据格式是否符合等等，在请求数据校验通过后入库到代付流水表中，然后组装一对一转账请求数据，发往存款核心；若存款核心处理失败，即客户账户上的款项扣款失败，则将该代付请求在代付流水表中的代付状态更新为“失败”，并将交易失败的消息返回对应的客户端；若存款核心处理成功，即客户账户上的款项扣款成功，则判断待转入的账户(收款方)是否为本银行开立的账户(行内账户)；若收款方为行内账户，则直接将客户账户上的款项划到待转入的账户上，并将交易成功的消息返回对应的客户端；若收款方不是行内账户，则将客户账户上的款项划到产品专有的内部户中，组装报文请求发送到统一支付平台，由统一支付平台走不同的支付通路，如网联、银联等支付通路，将内部户的钱转入到代付请求对应的他行银行卡上，统一支付平台接收到支付通路的转账结果后，再将支付结果回调产品***提供的支付结果接口，以更新代付流水表中的支付状态，产品***再通知用户交易结果。其中，调统一支付平台将内部户的钱转入到客户指定的他行银行卡上是一个异步的过程。由此可见，方案一最大的特点就是尽量同步返回代付处理过 程中的交易结果，一般用于正常的个人账户转账，并发量不高，所以执行方案一时代付处理***的整体吞吐量低下。
如图6所示，图6为本申请代付请求处理方法较佳实施例(方案二)的代付处理流程图。对比图5和图6可知：方案二与方案一的代付处理流程类似，不同的是，在代付处理过程中，方案二是由异步线程调存款核心、统一支付平台进行处理，且交易结果由请求方发起代付结果查询。虽然方案二可以很好地解决***吞吐量低下的问题，但如果某一个或多个商户的对公账户请求量非常大时，会使得这个高并发请求商户的账户变成热点账户，即该热点账户对应的代付处理会比较慢，则会影响其他并发请求并不高的商户对应的代付请求处理速度，使得代付请求处理***的处理效率低下。为了解决因热点账户导致处理速度慢的问题，可通过执行方案三来处理高并发情况下的代付请求，通过执行批量方案来处理超高并发情况下的代付请求。根据目标代付方案执行代付请求对应的处理流程，可在提高代付请求处理效率的同时，也提升不同并发程度的商户的支付体验。
本实施例的代付请求处理方法，当接收到代付请求时，确定对应的商户和当前代付方案，判断当前代付方案是否为批量方案；若不是批量方案，则将商户TPS与当前代付方案的TPS阈值进行比较，以确定商户的方案切换方向；判断商户的预设代付可选方案中是否存在与方案切换方向相匹配的待定可选方案；若存在，则确定目标代付方案，并将当前代付方案切换为目标代付方案；执行目标代付方案，以完成对应的代付处理流程。通过动态地对商户进行方案切换处理，将商户的当前代付方案切换到适配的目标代付方案，以及时处理不同并发程度的代付请求，提高代付请求的处理效率。
进一步地，基于本申请代付请求处理方法第一实施例，提出本申请代付请求处理方法第二实施例。
代付请求处理方法的第二实施例与代付请求处理方法的第一实施例的区别在于，所述方案切换方向为向预设TPS阈值更大的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：
步骤c1，根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更大的待定可选方案，并判断当前获取到的待定可选方案是否为预设批量方案；
步骤c2，若当前获取到的待定可选方案不为预设批量方案，则将所述商户的TPS与当前获取到的待定可选方案对应的预设TPS阈值进行比较；
步骤c3，当所述商户的TPS小于或等于当前获取到的待定可选方案对应的预设TPS阈值时，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案，若能切换，则将当前获取到的预设代付可选方案确定为所述商户的目标代付方案；
步骤c4，当所述商户的TPS大于当前获取到的待定可选方案对应的预设TPS阈值，或者不能将所述商户的当前代付方案切换为当前获取到的待定可选方案时，获取下一个预设TPS阈值更大的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。
在本实施例中，若确定将商户的当前代付方案向吞吐量更大的方案进行切换，则根据待定可选方案的吞吐量大小，逐一获取比当前代付方案吞吐量更大的方案进行判断。例如，在配置如图4所示的商户属性扩展表时，可通过两两比较的方式根据预设代付可选方案对应的TPS阈值来确定各个预设代付可选方案对应的吞吐量大小，一般来说，TPS阈值相对较大的预设代付可选方案，其对应的吞吐量也就更大；然后可按照吞吐量大小降序/升序的方式对各个预设代付可选方案进行排序。以图4中商户号为0000001的商户1为例，若预设代付可选方案是按照吞吐量降序的方式进行排序，那么，在商户属性扩展表中查询到商户1排序后的预设代付可选方案包括方案一、方案二和方案三，若商户1的当前代付方案是方案一，即商户1的当前代付方案为吞吐量最小的代付方案，不是批量方案，则可确定该商户可以切换到吞吐量更大的方案二或方案三。对于商户1来说，首先获取的待定可选方案为方案二，不是批量方案，则将商户1当前的TPS与商户1在方案二中配置的TPS阈值进行比较，若比较结果为商户1的TPS小于或等于商户1在方案二中配置的TPS阈值，由于方案二还会受到总的TPS控制，因此还需要进一步判断能否切换到方案二。若能切换到方案二，则确定当前获取到的方案二确定为商户1的目标代付方案；若比较结果为商户1的TPS大于商户1在方案二中配置的TPS阈值，或者，在进一步判断能否切换到方案二时确定不能切换到方案二，则继续获取下一个吞吐量更大的待定可选方案，即方案三，判断方案三是否为商户1的目标代付方案的过程与上述方案二的判断过程类似，此处不再赘述，但是，由于方案三是用于处理高并发代付请求情况的，所以方案三也不会受到总的TPS控制，只要商户1的TPS小于或等于商户1在方案三中配置的TPS阈值，就能将商户1的当前代付方案切换到方案三。
又例如，针对图4中商户号为0000004的商户4，在商户属性扩展表中查询到商户4排序后的预设代付可选方案包括方案二、方案三和批量方案，若商户4的当前代付方案是方案二，即商户4的当前代付方案为吞吐量最小的代付方案，则可确定该商户可以切换到吞吐量更大的方案三或者批量方案。但具体是切换到方案三还是批量方案，需要以当前实时的TPS为准。首先获取的待定可选方案为方案三， 不是批量方案，则将商户4当前的TPS与商户4在方案三中配置的TPS阈值进行比较，若比较结果为当前商户4的TPS大于商户4在方案三中配置的TPS阈值，则直接将商户4的当前代付方案切换到批量方案，否则将商户4的当前代付方案切换到方案三，也即，在进行方案切换处理时，如果获取到的待定可选方案不是批量方案，则需要确定商户的TPS小于或等于哪一个待定可选方案对应的TPS阈值，且商户的TPS与待切换方案对应的TPS阈值最为接近，即确定该TPS阈值对应的预设代付可选方案为该商户对应的目标代付方案。
进一步地，所述判断当前获取到的待定可选方案是否为预设批量方案的步骤之后，还包括：
步骤d，若当前获取到的待定可选方案为预设批量方案，则将当前获取到的待定可选方案确定为所述商户的目标代付方案，并将所述商户的当前代付方案切换为所述目标代付方案。
在本实施例中，若获取到的待定可选方案是批量方案，则直接将该商户的当前代付方案切换为批量方案。以图4中商户号为0000004的商户4为例，若商户4的当前代付方案是方案三，并确定将商户4切换到吞吐量更大的代付方案，那么，对于商户4来说，首先获取的待定可选方案肯定是批量方案，不是批量方案，则直接将商户4的当前代付方案切换到批量方案，也即，将批量方案确定为商户4对应的目标代付方案。
进一步地，所述方案切换方向为向预设TPS阈值更小的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：
步骤e1，根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案；
步骤e2，若当前获取到的待定可选方案不属于所述预设的TPS总值限制方案，则将当前获取到的待定可选方案确定为所述商户的目标代付方案。
在本实施例，若确定将商户的当前代付方案向吞吐量更小的代付方案进行切换，需要根据吞吐量降序的方向，逐一获取比当前代付方案吞吐量更小的待定可选方案。但由于本实施例的方案一和方案二适用于低并发程度以及正常并发程度的代付请求处理场景，因此，方案一和方案二还会受到总的TPS控制，也即，在本实施例中，预设的TPS总值限制方案包括方案一和方案二。但是，由于本实施例的方案三和批量方案适用于处理高并发以及超高并发程度的代付请求处理场景，不受总的TPS控制，因此，若当前获取到的待定可选方案不是方案一或方案二，即可确定该商户的带钱代付方案为批量方案，且当前获取到的待定可选方案为方案三，如图4中商户号为0000006的商户6。若商户6的TPS小于或等于商户6在方案三中配置的TPS阈值，则可直接将方案三确定为商户6的目标代付方案，否则，继续维持商户6的代付方案为批量方案。
进一步地，所述判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案的步骤之后，还包括：
步骤f1，若当前获取到的待定可选方案属于所述预设的TPS总值限制方案，则根据当前获取到的待定可选方案的TPS总值和所述商户的TPS，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；
步骤f2，若能切换，则将当前获取到的待定可选方案确定为所述商户的目标代付方案；
步骤f3，若不能切换，则获取下一个预设TPS阈值更小的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。
在本实施例中，若当前获取到的待定可选方案属于预设的TPS总值限制方案，即当前获取到的待定可选方案为方案一或方案二，需要进一步判断能否将商户的当前代付方案切换到当前获取到的待定可选方案，若能切换，则将当前获取到的待定可选方案确定为商户的目标代付方案，若不能切换，则继续获取下一个吞吐量更小的待定可选方案，并重复上述切换判断流程。例如，方案一的TPS总值为300，若商户A、商户B、商户C、商户D、商户E、商户F和商户G的当前代付方案为方案一，且这7个商户的当前TPS数值均为40，那么，此时方案一的TPS总值是7*40＝280，小于方案一的TPS总值300。但此时，如果***中的商户X当前代付方案是方案二，但在某一瞬间，商户X的TPS数值降到了30，小于商户X在方案一配置的TPS阈值45，从商户X的角度来看，是可以将商户X切换到方案一的，但此时，如果将商户X切换到方案一，那么，方案一的TPS总值就会从280变成310(280+30)，大于方案一预先设置好的TPS总值300，所以，商户X暂时不能切换到方案一，即商户X的当前代付方案继续维持为方案二。若商户Y的当前代付方案为方案三，待定可选方案包括方案一和方案二，且商户Y的当前TPS小于其在方案一配置的TPS阈值，当确定商户Y不能切换到方案二之后，会继续获取方案一，以确定商户Y能否切换到方案一；由于当前获取到的方案一为商户Y待定可选方案列表中的最后一个，若确定不能将方案一确定为商户Y的目标代付方案，则确定商户Y维持当前代付方案，即维持方案三。
本实施例的代付请求处理方法，在对商户进行方案切换处理时，依次判断否将商户的当前代付方案切换到每一个待定可选方案，以将商户的当前代付方案切换到适配的预设代付可选方案，尽可能地保证商户对应的代付请求能被及时处理，从而提高代付请求处理***的处理效率。
进一步地，基于本申请代付请求处理方法第一、第二实施例，提出本申请代付请求处理方法第三实施例。
代付请求处理方法的第三实施例与代付请求处理方法的第一、第二实施例的区别在于，判断所述商户的当前代付方案是否为预设批量方案的步骤之后，还包括：
步骤g1，若当前代付方案是预设批量方案，则获取所述商户的预设代付可选方案，并从所述商户的预设代付可选方案中筛选出比当前代付方案对应的预设TPS阈值更小的待定可选方案；
步骤g2，根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；
步骤g3，若能切换为当前获取到的待定可选方案，则将当前获取到的代付可选方案确定为所述商户的目标代付方案；
步骤g4，若不能切换为任一待定可选方案，则维持所述商户的当前代付方案。
在本实施例中，如图7所示，在对商户进行方案切换处理时，先通过查询预设商户配置表确定当前商户是否可动态切换方案；若不能动态切换方案，则确定商户的当前代付方案保持不变；若可动态切换方案，则判断当前商户的当前代付方案是否为批量方案，由于批量方案没有对应的TPS阈值，若当前商户的当前代付方案是批量方案，则确定该商户只能往吞吐量更小的方案进行切换，具体的切换流程可参考第二实施例中向吞吐量更小的方案机械能切换的切换判断过程，此处不再赘述，且如果确定该商户不能切换至任一吞吐量更小的待定可选方案，则确定该商户的代付方案继续维持为批量方案。若当前代付方案不是批量方案，则判断该商户的TPS是否超过了当前代付方案的TPS上限阈值；若当前商户的TPS超过当前代付方案的TPS上限阈值，则查询预设的商户属性扩展表，获得当前商户的预设代付可选方案列表，并查询是否存在比当前商户TPS阈值大的待定可选方案；若不存在，即说明该商户的当前代付方案为当前吞吐量最大的预设代付可选方案，则保持当前代付方案不变；若存在比当前代付方案吞吐量更大的预设代付可选方案，则获取下一个吞吐量更大的预设代付可选方案A；由于在本实施例中，批量方案对应的吞吐量最大，因此，若A为批量方案，则可直接将该商户的当前代付方案切换为批量方案；若A不是批量方案，则需要评估能否将该商户的当前代付方案切换为A，即判断如果将当前代付方案切换为A后，当前的TPS是否还小于或等于A对应的TPS总值；若当前的TPS还小于或等于A对应的TPS总值，则将该商户的当前代付方案切换为A；若当前的TPS大于A对应的TPS阈值，则继续获取下一个吞吐量更大的待定可选方案B，基于上述类似的评估过程，确定能否将该商户的当前代付方案切换为B，以此类推，直到将该商户的当前代付方案切换为最适配的预设代付可选方案。否则，该商户的当前代付方案保持不变。
而若当前商户的TPS不超过当前代付方案的TPS上限阈值，则进一步检测当前商户的TPS是否小于或等于吞吐量更小的待定可选方案对应的TPS阈值；若小于或等于，则按照排序后的待定可选方案获取下一个吞吐量更小的待定可选方案C，并判断C是否为方案一或方案二；若C为方案一或方案二，则需要评估能否将该商户的当前代付方案切换为C，即判断如果将当前代付方案切换为C后，当前的TPS是否会超过C对应的TPS总值；若当前的TPS不会超过C对应的TPS总值，则将该商户的当前代付方案切换为C；若当前的TPS超过C对应的TPS总值，则继续从排序后的待定可选方案中获取下一个吞吐量更小的待定可选方案D，基于上述类似的评估过程，确定能否将该商户的当前代付方案切换为D，以此类推，直到将该商户的当前代付方案切换为最适配的预设代付可选方案。否则，该商户的当前代付方案保持不变。
另外，若当前商户的TPS小于或等于另一待定可选方案对应的TPS阈值，但该商户未能进行方案切换处理时，还可设置轮询检测机制，在到达预设轮询时间时，再次检查该商户能否切换到相应的待定可选方案，例如，可判断该商户距离上次预切换方案但实际未能进行方案切换处理的时间是否超过了预设方案切换间隔，若超过了预设方案切换间隔，则执行方案切换处理流程。通过轮训机制查询商户是否可进行方案切换处理，可以提高代付请求处理***的灵活性，并进一步提高代付请求处理***的处理效率。
本实施例的代付请求处理方法，若商户的当前代付方案为批量方案，则想吞吐量更大的方案进行切换，以确定该商户的最适配代付方案，在保证代付请求处理***稳定性的同时，也可以提高代付请求的处理效率。
进一步地，基于本申请代付请求处理方法第一、第二、第三实施例，提出本申请代付请求处理方法第四实施例。
代付请求处理方法的第四实施例与代付请求处理方法的第一、第二、第三实施例的区别在于，应用于代付请求处理***，代付请求处理***包括存款核心，步骤S50还包括：
步骤h1，对所述代付请求对应的代付流水进行状态初始化处理，以将所述代付流水的当前处理状态初始化为预设初始处理状态；
步骤h2，将所述代付流水存储至预设数据库，并将所述代付流水对应的请求信息发送给所述商户对应的消息队列；
步骤h3，通过所述消息队列对应的监听线程从所述预设数据库中取出所述代付流水，并将所述代付流水发往所述存款核心，以供所述存款核心根据所述目标代付方案对所述代付流水进行代付处理，以完成所述代付请求对应的处理流程。
在本实施例中，通过设置消息队列来将高并发商户的代付请求隔离出来。对代付请求对应的代付流水进行状态初始化处理，可以减少后续组装请求数据时的入库处理动作，使得组装请求的效率更高。如图8所示，图8为本申请代付请求处理方法较佳实施例(方案三)对应的代付处理流程图。由于在方案三中会为每个商户都配置一个消息队列，消息队列可包括RocketMQ、ActiveMQ、RibbitMQ等，因此，若确定商户当前运行的代付方案为方案三，对代付请求对应的代付流水进行状态初始化处理时，可将代付流水的当前处理状态初始化为“I-待处理”，预设数据库优选为代付流水表，在代付请求组装入库到代付流水表后，将代付请求对应的请求消息发送给该商户对应的消息队列，其中，请求信息可包括该代付请求对应的唯一标识、代付请求对应的报文等信息。当该消息队列对应的监听线程接收到消息队列的消息时，返回接收成功的响应，并组装代付请求发往存款核心，由存款核心进行后续的代付处理，存款核心进行的代付处理过程与方案一和方案二的类似，此处不再赘述。在方案三中，通过为每个高并发的商户设置一个对应的消息队列，以将高并发的代付请求隔离出来，保证其他不是高并发商户的代付请求能被及时处理，从而提高非高并发商户代付请求的处理能力。
进一步地，代付请求处理***包括预设兜底任务线程，所述将所述代付流水存储至预设数据库的步骤之后，还包括：
步骤i1，通过所述预设兜底任务线程判断所述预设数据库中是否存在超过预设等待处理时间的目标代付流水；
步骤i2，若存在，则通过预设兜底任务线程从所述预设数据库中取出所述目标代付流水，并将所述目标代付流水发往所述存款核心，以供所述存款核心对所述目标代付流水进行代付处理。
在本实施例中，可通过实时或定时的兜底任务来保证消息队列中的消息不会丢失，可以理解的，由于消息队列可以是专门的消息中间件，也可以是简单的内存消息队列等，但这些消息队列不能完全保证消息不会丢失，因此，为了保证不丢失消息队列中的消息，需要设置一个兜底任务线程来扫描预设数据库，其中，兜底任务优选为兜底定时任务；预设数据库可以是代付流水表或者一对一转账流水表，预设数据库可根据该商户当前运行的代付方案对应的并发程度来决定，例如，若当前的目标代付方案为方案三，由于在执行方案三时，代付请求是入库到代付流水表中，因此，可通过兜底定时任务线程扫描代付流水表来查询超过预设等待处理时间的目标代付流水；若当前的目标的代付方案为批量方案，由于在执行批量方案时，代付请求除了入库到代付流水表外，还入库到一对一转账流水表中，但是后续组装代付请求发往存款核心时，可直接从一对一转账流水表获取代付流水，因此，在执行批量方案时，兜底定时任务线程可通过扫描一对一转账流水表来查询超过预设等待处理时间的目标代付流水，然后通过兜底任务线程将取出的目标代付流水发往存款核心，以供存款核心对该目标代付流水进行后续的代付处理。通过兜底任务来兜住超过预设等待处理时间的代付流水，有利于提高***的健壮性。
本实施例的代付请求处理方法，可通过为每一个高并发的商户设置一个对应的消息队列，以将高并发的代付请求隔离出来，保证其他不是高并发商户的代付请求能被及时处理，提高非高并发商户代付请求的处理能力；也可以通过预设兜底任务线程查询并处理预设数据库中超过预设等待处理时间的目标代付请求，保证消息队列中的消息不会丢失，有利于提高***的健壮性。
进一步地，基于本申请代付请求处理方法第一、第二、第三、第四实施例，提出本申请代付请求处理方法第五实施例。
代付请求处理方法的第五实施例与代付请求处理方法的第一、第二、第三、第四实施例的区别在于，所述方法还包括：
步骤j1，从所述预设数据库中取出当前处理状态为预设初始处理状态的待处理代付流水，并对所述待处理代付流水进行代付处理，得到对应的代付处理状态；
步骤j2，将所述待处理代付流水的当前处理状态更新为所述代付处理状态；
步骤j3，当所述预设数据库中的代付流水对应的代付处理状态均为预设处理完成状态时，则将处理完成后的待处理代付流水发往所述存款核心，以供所述存款核心对所述处理完成后的待处理代付流水进行代付处理。
在本实施例中，在处理高并发代付请求时，通过兜底任务线程扫描预设数据库，可能会存在监听消息队列的线程和兜底任务的线程，或者是异常情况下两个监听线程同时处理同一笔代付流水的问题，因此，通过监听线程或兜底任务线程从预设数据库中取出每一笔代付流水进行处理时需要进行并发控制，以保证高并发情况下代付请求的处理效率，另外，由于不同代付方案对应的并发情况不同，因此，针对不同并发程度的高并发代付方案，可采用不同的并发控制措施。在处理每一笔代付流水时，可根据代付流水表对应的主键来获取待处理的代付流水，其中，主键即主关键字(primary key)，可以根据主键来唯一确定代付流水表中的一行数据，即一笔代付流水。
如图9所示，图9为本申请代付请求处理方法较佳实施例(方案三)的并发控制流程图。通过方案三进行代付处理时，通过在代付流水表上新增一个字段concurrent_status来进行并发控制，假设代付流水的初始处理状态是“I-待处理”，通过状态扭转来进行并发控制时，具体的，可通过查询concurrent_status状态为“I-待处理”的代付流水列表，再从查询到的代付流水列表中按照时间先后顺序依次取出对应的代付流水来组装一对一转账流水，并更新当前处理的代付流水的concurrent_status状态为“P-处理中”；在检测到当前处理的代付流水的concurrent_status状态成功更新为“P-处理中”后，将组装的一对一转账流水发送给存款核心，然后将该代付流水的concurrent_status状态更新为“S-已处理”；在更新成功后，检测当前处理的代付流水是否为代付流水列表中的最后一个；若当前处理的代付流水为代付流水列表中的最后一个，则结束该笔代付流水的并发控制流程；若当前处理的代付流水不是代付流水列表的最后一个，则继续从查询到的代付流水列表中按照时间先后顺序依次取出对应的代付流水来组装一对一转账流水，按照上述的并发控制流程来更新代付流水的concurrent_status状态，直到更新完代付流水列表中所有代付流水的代付处理状态，即当检测到预设数据库中的代付流水对应的代付处理状态均为预设处理完成状态时，则可结束预设数据库中的代付流水对应的处理状态更新流程，并将处理完成后的代付流水发往存款核心，以供存款核心对处理完成后的代付流水进行后续的代付处理。
如图11所示，图11为本申请代付请求处理方法较佳实施例(批量方案)的并发控制流程图。与方案三不同的是，利用批量方案进行并发控制时，查询的是一对一转账流水列表，具体的，根据商户号、批次号查询批次状态为“02-已打标”的一对一转账流水列表，从查询到的一对一转账流水列表中依次取出代付流水组装一对一转账流水，然后根据查询到的一对一转账流水的逐渐将一对一转账流水的批次状态更新为“03-组装中”；在更新成功后，将当前的一对一转账流水数据组装到核心批量请求报文中，然后更新当前处理的代付流水的批次状态为“04-已组装”，根据上述的并发控制流程依次处理一对一转账流水列表中的代付流水，直到一对一转账代付流水列表中的代付流水的代付处理状态全部更新完毕，则将组装好的这一批代付流水发往存款核心，然后将这一批次的一对一转账流水的批次状态更新为“05-已处理”，也即，当检测到预设数据库中的代付流水对应的代付处理状态均为预设处理完成状态时，则结束该预设数据库中的代付流水对应的处理状态更新流程，从而完成这一批次代付流水的并发控制流程。
本实施例的代付请求处理方法，在处理高并发代付请求时，通过更新代付流水的代付处理状态来进行并发控制，可提高代付请求处理***的稳定性，保证***的代付请求处理效率。
进一步地，基于本申请代付请求处理方法第一、第二、第三、第四、第五实施例，提出本申请代付请求处理方法第六实施例。
代付请求处理方法的第六实施例与代付请求处理方法的第一、第二、第三、第四、第五实施例的区别在于，所述目标代付方案为预设批量方案，所述将所述代付流水存储至预设数据库的步骤之后，还包括：
步骤k1，从所述预设数据库中查询当前处理状态为预设初始处理状态的批量代付流水，并生成所述批量代付流水对应的统一批次号；
步骤k2，获取所述批量代付流水中的商户号，将所述统一批次号和所述商户号发送给预设目标消息队列；
步骤k3，通过所述预设目标消息队列对应的监听线程根据所述统一批次号和所述商户号从所述预设数据库取出所述批量代付流水，并组装所述批量流水对应的批量请求发往所述存款核心，以供所述存款核心根据所述批量请求对所述批量代付流水进行代付处理。
在本实施例中，如图10所示，图10为本申请代付请求处理方法较佳实施例(批量方案)的代付处理流程图。与方案三不同的是，批量方案中的所有商户共用同一个消息队列。如果检测到商户当前的代付方案为批量方案，在代付请求校验成功后，直接将代付请求入库到代付流水表、一对一转账流水表，并初始化发往存款核心的一对一转账流水表，以将这一批一对一转账流水表中的batch_status状态初始 化为“01-待打标”，然后通过兜底定时任务扫描一对一转账流水表，获取batch_status状态为“待打标”的代付流水，也可预先设置每次获取的流水记录数，如每次最多获取30条代付流水记录数，生成一个唯一的处理编号batch_no，并将代付流水的batch_status状态更新为“02-已打标”，以将这一批一对一转账流水的batch_no更新为同一个唯一的批次号，即统一批次号，然后将商户号、batch_no发到消息队列中，当监听消息队列的线程接收到消息队列的消息时，取出消息队列中的商户号、batch_no，根据商户号、batch_no查询一对一转账流水表，将这批一对一转账流水取出，循环组装批量请求报文发送给存款核心，由存款核心，或由存款核心和统一支付平台处理完成后得到对应的处理结果，然后基于上述的处理流程循环处理一对一转账流水，从而批量完成一对一转账流水的代付处理流程。存款核心的代付处理流程与上述的类似，此处不再赘述。
本实施例的代付请求处理方法，通过批量方案从商户的维度来组装批量代付请求，且批量方案中的一个或多个商户共用同一个消息队列，不仅可以将TPS比较大的商户的代付请求隔离出来，还可以提高超高并发商户的代付请求组处理速度。
本申请还提供一种代付请求处理装置。参照图12，本申请代付请求处理装置包括：
第一判断模块10，用于当接收到代付请求时，确定所述代付请求对应的商户，以及所述商户的当前代付方案，并判断所述商户的当前代付方案是否为预设批量方案；
比较确定模块20，用于若当前代付方案不是预设批量方案，则将所述商户的TPS与当前代付方案对应的预设TPS阈值进行比较，并根据比较结果确定所述商户的方案切换方向，所述商户的TPS为单位时间内处理的所述商户的代付请求数；
第二判断模块30，用于获取所述商户的预设代付可选方案，并判断所述预设代付可选方案中是否存在与所述方案切换方向相匹配的待定可选方案；
方案切换模块40，用于若存在，则从所述待定可选方案中确定所述商户的目标代付方案，并将所述商户的当前代付方案切换为所述目标代付方案；
代付执行模块50，用于执行所述目标代付方案，以完成所述代付请求对应的处理流程。
在一实施例中，所述比较确定模块还用于：
若比较结果为所述商户的TPS大于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更大的预设代付可选方案切换；
若比较结果为所述商户的TPS小于或等于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更小的预设代付可选方案切换。
在一实施例中，所述方案切换模块还用于：
根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更大的待定可选方案，并判断当前获取到的待定可选方案是否为预设批量方案；
若当前获取到的待定可选方案不为预设批量方案，则将所述商户的TPS与当前获取到的待定可选方案对应的预设TPS阈值进行比较；
当所述商户的TPS小于或等于当前获取到的待定可选方案对应的预设TPS阈值时，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案，若能切换，则将当前获取到的预设代付可选方案确定为所述商户的目标代付方案；
当所述商户的TPS大于当前获取到的待定可选方案对应的预设TPS阈值，或者不能将所述商户的当前代付方案切换为当前获取到的待定可选方案时，获取下一个预设TPS阈值更大的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。
在一实施例中，所述方案切换模块还用于：
根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案；
若当前获取到的待定可选方案不属于所述预设的TPS总值限制方案，则将当前获取到的待定可选方案确定为所述商户的目标代付方案。
在一实施例中，所述方案切换模块还包括总值判断单元，所述总值判断单元用于：
若当前获取到的待定可选方案属于所述预设的TPS总值限制方案，则根据当前获取到的待定可选方案的TPS总值和所述商户的TPS，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；
若能切换，则将当前获取到的待定可选方案确定为所述商户的目标代付方案；
若不能切换，则获取下一个预设TPS阈值更小的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。
在一实施例中，所述第一判断模块还包括批量方案判断单元，所述批量方案判断用于：
若当前代付方案是预设批量方案，则获取所述商户的预设代付可选方案，并从所述商户的预设代付可选方案中筛选出比当前代付方案对应的预设TPS阈值更小的待定可选方案；
根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；
若能切换为当前获取到的待定可选方案，则将当前获取到的代付可选方案确定为所述商户的目标代付方案；
若不能切换为任一待定可选方案，则维持所述商户的当前代付方案。
在一实施例中，所述代付请求处理装置还包括存款核心，所述代付执行模块用于：
对所述代付请求对应的代付流水进行状态初始化处理，以将所述代付流水的当前处理状态初始化为预设初始处理状态；
将所述代付流水存储至预设数据库，并将所述代付流水对应的请求信息发送给所述商户对应的消息队列；
通过所述消息队列对应的监听线程从所述预设数据库中取出所述代付流水，并将所述代付流水发往所述存款核心，以供所述存款核心根据所述目标代付方案对所述代付流水进行代付处理，完成所述代付请求对应的处理流程。
在一实施例中，所述代付请求处理装置还包括并发控制模块，所述并发控制模块用于：
从所述预设数据库中取出当前处理状态为预设初始处理状态的待处理代付流水，并对所述待处理代付流水进行代付处理，得到对应的代付处理状态；
将所述待处理代付流水的当前处理状态更新为所述代付处理状态；
当所述预设数据库中的代付流水对应的代付处理状态均为预设处理完成状态时，则将处理完成后的待处理代付流水发往所述存款核心，以供所述存款核心对所述处理完成后的待处理代付流水进行代付处理。
在一实施例中，所述代付执行模块还包括批量代付单元，所述批量代付单元用于：
从所述预设数据库中查询当前处理状态为预设初始处理状态的批量代付流水，并生成所述批量代付流水对应的统一批次号；
获取所述批量代付流水中的商户号，将所述统一批次号和所述商户号发送给预设目标消息队列；
通过所述预设目标消息队列对应的监听线程根据所述统一批次号和所述商户号从所述预设数据库取出所述批量代付流水，并组装所述批量流水对应的批量请求发往所述存款核心，以供所述存款核心根据所述批量请求对所述批量代付流水进行代付处理。
本申请还提供一种计算机程序产品，包括计算机程序，所述计算机程序被处理器执行时实现如上所述的代付请求处理方法的步骤。
本申请还提供一种存储介质。
本申请存储介质上存储有代付请求处理程序，所述代付请求处理程序被处理器执行时实现如上所述的代付请求处理方法的步骤。
其中，本申请代付请求处理***、计算机程序产品和存储介质的各实施例，均可参照本申请代付请求处理方法各个实施例，此处不再赘述。
需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者***不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者***所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者***中还存在另外的相同要素。
上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。
通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在如上所述的一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端***(可以是手机，计算机，服务器，空调器，或者网络***等)执行本申请各个实施例所述的方法。
以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书与附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

  1. 一种代付请求处理方法，其中，所述方法包括如下步骤：
    当接收到代付请求时，确定所述代付请求对应的商户，以及所述商户的当前代付方案，并判断所述商户的当前代付方案是否为预设批量方案；
    若当前代付方案不是预设批量方案，则将所述商户的TPS与当前代付方案对应的预设TPS阈值进行比较，并根据比较结果确定所述商户的方案切换方向，所述商户的TPS为单位时间内处理的所述商户的代付请求数；
    获取所述商户的预设代付可选方案，并判断所述预设代付可选方案中是否存在与所述方案切换方向相匹配的待定可选方案；
    若存在，则从所述待定可选方案中确定所述商户的目标代付方案，并将所述商户的当前代付方案切换为所述目标代付方案；
    执行所述目标代付方案，以完成所述代付请求对应的处理流程。
  2. 如权利要求1所述的代付请求处理方法，其中，所述根据比较结果确定所述商户的方案切换方向的步骤包括：
    若比较结果为所述商户的TPS大于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更大的预设代付可选方案切换；
    若比较结果为所述商户的TPS小于或等于当前代付方案对应的预设TPS阈值，则确定所述商户的方案切换方向为向预设TPS阈值更小的预设代付可选方案切换。
  3. 如权利要求2所述的代付请求处理方法，其中，所述方案切换方向为向预设TPS阈值更大的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：
    根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更大的待定可选方案，并判断当前获取到的待定可选方案是否为预设批量方案；
    若当前获取到的待定可选方案不为预设批量方案，则将所述商户的TPS与当前获取到的待定可选方案对应的预设TPS阈值进行比较；
    当所述商户的TPS小于或等于当前获取到的待定可选方案对应的预设TPS阈值时，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案，若能切换，则将当前获取到的预设代付可选方案确定为所述商户的目标代付方案；
    当所述商户的TPS大于当前获取到的待定可选方案对应的预设TPS阈值，或者不能将所述商户的当前代付方案切换为当前获取到的待定可选方案时，获取下一个预设TPS阈值更大的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。
  4. 如权利要求2所述的代付请求处理方法，其中，所述方案切换方向为向预设TPS阈值更小的预设代付可选方案切换，所述从所述待定可选方案中确定所述商户的目标代付方案的步骤包括：
    根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案；
    若当前获取到的待定可选方案不属于所述预设的TPS总值限制方案，则将当前获取到的待定可选方案确定为所述商户的目标代付方案。
  5. 如权利要求4所述的代付请求处理方法，其中，所述判断当前获取到的待定可选方案是否属于预设的TPS总值限制方案的步骤之后，还包括：
    若当前获取到的待定可选方案属于所述预设的TPS总值限制方案，则根据当前获取到的待定可选方案的TPS总值和所述商户的TPS，判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；
    若能切换，则将当前获取到的待定可选方案确定为所述商户的目标代付方案；
    若不能切换，则获取下一个预设TPS阈值更小的待定可选方案并重复上述确定所述商户的目标代付方案的步骤。
  6. 如权利要求1所述的代付请求处理方法，其中，所述判断所述商户的当前代付方案是否为预设批量方案的步骤之后，还包括：
    若当前代付方案是预设批量方案，则获取所述商户的预设代付可选方案，并从所述商户的预设代 付可选方案中筛选出比当前代付方案对应的预设TPS阈值更小的待定可选方案；
    根据各所述待定可选方案对应的预设TPS阈值大小，依次获取预设TPS阈值更小的待定可选方案，并判断能否将所述商户的当前代付方案切换为当前获取到的待定可选方案；
    若能切换为当前获取到的待定可选方案，则将当前获取到的代付可选方案确定为所述商户的目标代付方案；
    若不能切换为任一待定可选方案，则维持所述商户的当前代付方案。
  7. 如权利要求1所述的代付请求处理方法，其中，应用于代付请求处理***，所述代付请求处理***包括存款核心，所述执行所述目标代付方案，以完成所述代付请求对应的处理流程的步骤包括：
    对所述代付请求对应的代付流水进行状态初始化处理，以将所述代付流水的当前处理状态初始化为预设初始处理状态；
    将所述代付流水存储至预设数据库，并将所述代付流水对应的请求信息发送给所述商户对应的消息队列；
    通过所述消息队列对应的监听线程从所述预设数据库中取出所述代付流水，并将所述代付流水发往所述存款核心，以供所述存款核心根据所述目标代付方案对所述代付流水进行代付处理，完成所述代付请求对应的处理流程。
  8. 如权利要求7所述的代付请求处理方法，其中，所述方法还包括：
    从所述预设数据库中取出当前处理状态为预设初始处理状态的待处理代付流水，并对所述待处理代付流水进行代付处理，得到对应的代付处理状态；
    将所述待处理代付流水的当前处理状态更新为所述代付处理状态；
    当所述预设数据库中的代付流水对应的代付处理状态均为预设处理完成状态时，则将处理完成后的待处理代付流水发往所述存款核心，以供所述存款核心对所述处理完成后的待处理代付流水进行代付处理。
  9. 如权利要求7所述的代付请求处理方法，其中，所述目标代付方案为预设批量方案，所述将所述代付流水存储至预设数据库的步骤之后，还包括：
    从所述预设数据库中查询当前处理状态为预设初始处理状态的批量代付流水，并生成所述批量代付流水对应的统一批次号；
    获取所述批量代付流水中的商户号，将所述统一批次号和所述商户号发送给预设目标消息队列；
    通过所述预设目标消息队列对应的监听线程根据所述统一批次号和所述商户号从所述预设数据库取出所述批量代付流水，并组装所述批量流水对应的批量请求发往所述存款核心，以供所述存款核心根据所述批量请求对所述批量代付流水进行代付处理。
  10. 一种代付请求处理***，其中，所述代付请求处理***包括：存储器、处理器及存储在所述存储器上并可在所述处理器上运行的代付请求处理程序，所述代付请求处理程序被所述处理器执行时实现如权利要求1至9中任一项所述的代付请求处理方法的步骤。
PCT/CN2021/139716 2021-06-21 2021-12-20 代付请求处理方法及*** WO2022267395A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110686622.4A CN113298513A (zh) 2021-06-21 2021-06-21 代付请求处理方法及***
CN202110686622.4 2021-06-21

Publications (1)

Publication Number Publication Date
WO2022267395A1 true WO2022267395A1 (zh) 2022-12-29

Family

ID=77328954

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/139716 WO2022267395A1 (zh) 2021-06-21 2021-12-20 代付请求处理方法及***

Country Status (2)

Country Link
CN (1) CN113298513A (zh)
WO (1) WO2022267395A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113298513A (zh) * 2021-06-21 2021-08-24 深圳前海微众银行股份有限公司 代付请求处理方法及***

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190236577A1 (en) * 2018-01-26 2019-08-01 Partially Inc. Customizable and flexible payment plans
CN110852744A (zh) * 2019-10-08 2020-02-28 深圳汇商通盈科技有限公司 一种切换交易通道的方法、装置、终端设备及介质
CN111369257A (zh) * 2020-03-06 2020-07-03 上海佩俪信息科技有限公司 通过智能合约在区块链上实现资产代扣的方法与装置
CN113298513A (zh) * 2021-06-21 2021-08-24 深圳前海微众银行股份有限公司 代付请求处理方法及***

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2011378113A1 (en) * 2011-09-30 2014-04-17 BPAY Group Limited Payment requests
US10467602B2 (en) * 2015-03-11 2019-11-05 Facebook, Inc. Facilitating sending, receiving, and updating of payments using message and payment queues
CN107016536B (zh) * 2017-01-16 2018-06-22 平安银行股份有限公司 交易处理的方法及交易服务器
CN108958893B (zh) * 2017-05-23 2020-12-08 ***通信集团重庆有限公司 高并发业务的资源控制方法、装置和计算机可读存储介质
CN107274162A (zh) * 2017-05-31 2017-10-20 深圳市长亮科技股份有限公司 一种高交易并发量的处理方法
CN107943584A (zh) * 2017-11-15 2018-04-20 中国银行股份有限公司 批量交易请求的处理方法及装置
CN109816502A (zh) * 2019-01-02 2019-05-28 深圳壹账通智能科技有限公司 批量代付方法、装置、计算机设备和存储介质
CN111459963B (zh) * 2020-04-07 2024-03-15 中国建设银行股份有限公司 核心账务交易并发处理方法及装置
CN112104731B (zh) * 2020-09-11 2022-05-20 北京奇艺世纪科技有限公司 请求处理方法、装置、电子设备和存储介质

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190236577A1 (en) * 2018-01-26 2019-08-01 Partially Inc. Customizable and flexible payment plans
CN110852744A (zh) * 2019-10-08 2020-02-28 深圳汇商通盈科技有限公司 一种切换交易通道的方法、装置、终端设备及介质
CN111369257A (zh) * 2020-03-06 2020-07-03 上海佩俪信息科技有限公司 通过智能合约在区块链上实现资产代扣的方法与装置
CN113298513A (zh) * 2021-06-21 2021-08-24 深圳前海微众银行股份有限公司 代付请求处理方法及***

Also Published As

Publication number Publication date
CN113298513A (zh) 2021-08-24

Similar Documents

Publication Publication Date Title
US6205464B1 (en) System for building optimal commit trees in a distributed transaction processing system
US7756940B2 (en) Transaction processing system having service level control capabilities
US8347292B2 (en) Transaction aggregation to increase transaction processing throughout
US7502824B2 (en) Database shutdown with session migration
US7953860B2 (en) Fast reorganization of connections in response to an event in a clustered computing system
US5768587A (en) Operating a transaction manager with a non-compliant resource manager
US6317773B1 (en) System and method for creating an object oriented transaction service that interoperates with procedural transaction coordinators
US20100318570A1 (en) Pluggable session context
US20100042675A1 (en) Request processing method and computer system
CN108280150B (zh) 一种分布式异步业务分发方法及***
JPH035846A (ja) リモート・アプリケーシヨン実行方式
WO2021036768A1 (zh) 数据读取方法、装置、计算机设备及存储介质
WO2020000720A1 (zh) 服务器、报文处理方法、程序和计算机可读存储介质
CN110363663B (zh) 基于区块链的数据批量处理方法、装置、设备及存储介质
CN109886694A (zh) 基于区块链的数据处理方法及装置和电子设备
WO2019149032A1 (zh) 分布式事务处理方法及装置
CN112615793A (zh) 一种数据限流方法及装置
WO2022267395A1 (zh) 代付请求处理方法及***
CN109614271A (zh) 多个集群数据一致性的控制方法、装置、设备及存储介质
WO2020006901A1 (zh) 资金归集方法、装置、计算机设备和存储介质
US11881996B2 (en) Input and output for target device communication
CN112199401B (zh) 数据请求处理方法、装置、服务器、***及存储介质
CN112131238B (zh) 一种交易状态机设计方法、处理装置和处理方法
CN111161048B (zh) 一种资金归集自动过账的应用方法及装置
JP2017091213A (ja) データベース更新処理システムおよびデータベース更新処理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21946869

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21946869

Country of ref document: EP

Kind code of ref document: A1