WO2020103275A1 - 扣款控制方法、装置、设备及可读存储介质 - Google Patents

扣款控制方法、装置、设备及可读存储介质

Info

Publication number
WO2020103275A1
WO2020103275A1 PCT/CN2018/123190 CN2018123190W WO2020103275A1 WO 2020103275 A1 WO2020103275 A1 WO 2020103275A1 CN 2018123190 W CN2018123190 W CN 2018123190W WO 2020103275 A1 WO2020103275 A1 WO 2020103275A1
Authority
WO
WIPO (PCT)
Prior art keywords
deduction
request
deduction request
charge control
control method
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/CN2018/123190
Other languages
English (en)
French (fr)
Inventor
宋斌
梁洪涛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ping An Technology Shenzhen Co Ltd
Original Assignee
Ping An Technology Shenzhen Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Ping An Technology Shenzhen Co Ltd filed Critical Ping An Technology Shenzhen Co Ltd
Publication of WO2020103275A1 publication Critical patent/WO2020103275A1/zh
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/407—Cancellation of a transaction
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • This application relates to the field of financial technology, and in particular, to a deduction control method, device, equipment, and readable storage medium.
  • the main purpose of this application is to provide a deduction control method, device, equipment, and readable storage medium, which are intended to solve the technical problems that existing banks are easy to debit and affect user experience when debiting.
  • the present application provides a deduction control method.
  • the deduction control method is applied to a collection system.
  • the collection system includes multiple distributed servers.
  • the deduction control method includes:
  • the step of locking the deduction request includes:
  • the deduction request is locked.
  • the step of locking the deduction request based on the distributed locking method provided by the Redis database includes:
  • the user account and the preset prefix are set as the first parameter content of the first parameter key pre-stored in the distributed locking mode, and the IP address of the target server is set as the pre-stored first parameter in the distributed locking mode
  • determining that the debit request is successfully locked includes:
  • the unlock processing is performed on the lock processing deduction request whose storage time is greater than the lock over time.
  • the lock deduction request is sent to the target server for the target server to perform pre-storage on the user account corresponding to the lock deduction request
  • the deduction operation steps include:
  • the deduction request corresponding to the successful deduction is unlocked.
  • the charge control method further includes:
  • the unlocking type of the deduction request is obtained based on the unlocking completion instruction
  • unlocking type is an active unlocking type, it is determined to generate the first prompt message of successful deduction
  • the unlocking type is a passive unlocking type, it is determined to generate a second prompt message that the deduction has failed.
  • This application also provides a charge control device, the charge control device includes:
  • a receiving module configured to determine the target server side of the deduction request according to the current number of pending requests of the multiple server sides when receiving the deduction request;
  • a locking module configured to perform a locking process on the deduction request, and send the deduction request after the locking process to the target server side, so that the target server side
  • the user account corresponding to the deduction request corresponds to the execution of the pre-stored deduction operation.
  • the locking module includes:
  • a calling unit used to call a pre-stored concurrency control program segment to intercept the deduction request
  • the locking unit is used for locking the deduction request based on the distributed locking method provided by the Redis database.
  • the locking unit includes:
  • the first obtaining subunit is used to obtain the user account corresponding to the deduction request, the IP address of the target server, and the preset lock timeout time;
  • a verification subunit configured to verify the target lock and determine whether a preset return value is received
  • the determination subunit is configured to determine that the deduction request is successfully locked if the preset return value is received.
  • the locking unit further includes:
  • a storage subunit configured to store the deduction request after successful locking in the Redis database, and periodically scan each deduction request after locking processing stored in the Redis database;
  • a detection subunit configured to detect the deduction request after the lock processing that the storage time is greater than the lock over time if the storage time of each deduction request after locking processing in the Redis database is greater than the lock over time Unlock processing.
  • the charge control device further includes:
  • the unlocking module is used for unlocking the deduction request corresponding to the successful deduction if the target server side detects that the client corresponding to the deduction request after the lock processing is successfully debited.
  • the charge control device further includes:
  • An obtaining module configured to obtain an unlocking type of the deduction request based on the unlocking completion instruction if it is detected that the deduction request has been unlocked and processed;
  • a first determining module configured to determine, if the unlocking type is an active unlocking type, the first prompt information of successful payment deduction
  • the second determining module is configured to determine, if the unlocking type is a passive unlocking type, to generate second prompt information that the deduction has failed.
  • the present application also provides a charge control device, the charge control device includes: a memory, a processor, a communication bus, and a charge control instruction readable stored on the memory,
  • the communication bus is used to realize the communication connection between the processor and the memory
  • the processor is used to execute the deduction control readable instructions to implement the following steps:
  • the present application also provides a readable storage medium that stores one or more programs, and the one or more programs may be executed by one or more processors to Used for:
  • the target server side of the deduction request is determined according to the current number of pending requests of the multiple servers; the lock request is processed to lock the deduction request
  • the processed deduction request is sent to the target server side for the target server side to perform a pre-stored deduction operation corresponding to the user account corresponding to the locked deduction request.
  • the client corresponding to the deduction request is locked synchronously, Therefore, if there is another deduction request that is synchronized with the deduction request, the other deduction request will be abandoned and not processed. Therefore, repeated deductions can be avoided and the user experience can be improved, thereby solving the problem that the existing bank debits Technical issues that are easy to debit and affect user experience.
  • FIG. 1 is a schematic flowchart of a first embodiment of a deduction control method of this application
  • FIG. 2 is a detailed flowchart of a lock processing step of the deduction request in the second embodiment of the deduction control method of the present application;
  • FIG. 3 is a schematic diagram of a device structure of a hardware operating environment involved in the method of an embodiment of the present application
  • FIG. 4 is a schematic flowchart of the deduction control device of the present application.
  • the present application provides a deduction control method.
  • the deduction control method is applied to a collection system.
  • the collection system includes a plurality of distributed distributions.
  • the charge control method includes:
  • Step S10 When receiving the deduction request, determine the target server end of the deduction request according to the current number of pending requests of the multiple server ends;
  • Step S20 Perform a lock processing on the deduction request, and send the deduction request after the lock processing to the target server side for the target server side to process the deduction after the lock processing Request the corresponding user account to perform the pre-stored deduction operation.
  • Step S10 When receiving the deduction request, determine the target server end of the deduction request according to the current number of pending requests of the multiple server ends;
  • the deduction control method is applied to a collection system, and the collection system includes a plurality of distributed server ends, each of which has a function of processing a deduction request, in which When a chargeback request is made, the multiple server ends may compete to process the chargeback request.
  • the specific competition method may be: determining the target server end of the chargeback request according to the current number of pending requests of the multiple server ends, and the server end The smaller the current number of pending requests, the greater the competitiveness, and the greater the current number of pending requests on the server, the lower the competitiveness.
  • the specific competition method may also be: determined according to the processing speed or processing capacity of the server Specifically, the better the configuration performance on the server side, the higher the processing speed or processing capacity on the server side, and the higher the processing speed or processing capacity on the server side, the greater the competitiveness of the server side, and the more likely it is to compete to get a deduction request.
  • the collection system After receiving the deduction request, the collection system determines the target server side through the above-mentioned competitive manner, and needs to send the deduction request to the target server side.
  • Step S20 Perform a lock processing on the deduction request, and send the deduction request after the lock processing to the target server side for the target server side to process the deduction after the lock processing Request the corresponding user account to perform the pre-stored deduction operation.
  • the lock processing is performed on the deduction request, where the lock processing on the deduction request includes the following two methods:
  • Method 1 Send the deduction request to the cache subsystem in the collection system, and lock the deduction request in the cache subsystem. After the lock processing is completed, send the deduction request after the lock to the target server end;
  • Method 2 Send the deduction request directly to the target server, and lock the deduction request on the target server.
  • the deduction request is locked, the account number of the client corresponding to the deduction request is synchronized and locked, that is, the deduction request is When locking, the user account cannot be used for other deduction operations, which will be described in specific embodiments.
  • the bank payment code is scanned twice in succession to generate two corresponding
  • the other payment request cannot be synchronously locked because the bank account already has a locked record.
  • the lock deduction request is sent to the target server for the target server to correspond to the user account corresponding to the lock deduction request Perform pre-stored deductions.
  • the target server performs corresponding pre-stored deduction operation steps corresponding to the user account corresponding to the deduction request after the lock processing includes: obtaining the deduction amount carried in the deduction request, the deduction account number, and the deduction agreement, Based on the deduction amount, deduction account number and deduction agreement, request a deduction from the bank.
  • an operation log file is generated.
  • the operation log file may be based on a NOSQL (non-relational) memory database Redis, and Using Redis' persistent storage.
  • Redis-based persistent storage AOF mode When receiving a debit request, Redis-based persistent storage AOF mode will "operate + "Data" is appended to the end of the corresponding operation log file in the form of formatting instructions, that is, as soon as the deduction request is received, the processing flow steps of the deduction request and the data obtained in the processing flow steps are written Into the log file, all historical operation processes are saved in the log file. Therefore, when data recovery is required, all operation processes can be restored according to the log file. Avoid various losses caused by the failure to find the deduction record.
  • the locked deduction request when it is detected that the deduction request is locked, the locked deduction request is permanently stored in the Redis database in real time.
  • the target server side of the deduction request is determined according to the current number of pending requests of the multiple servers; the lock request is processed to lock the deduction request
  • the processed deduction request is sent to the target server side for the target server side to perform a pre-stored deduction operation corresponding to the user account corresponding to the locked deduction request.
  • the client corresponding to the deduction request is locked synchronously, Therefore, if there is another deduction request that is synchronized with the deduction request, the other deduction request will be abandoned and not processed. Therefore, repeated deductions can be avoided and the user experience can be improved, thereby solving the problem that the existing bank debits Technical issues that are easy to debit and affect user experience.
  • the step of locking the deduction request includes:
  • Step S21 calling a pre-stored concurrency control program segment to intercept the deduction request
  • the concurrency control program segment is pre-stored in the collection system, and the DistributedLockAspect class is pre-stored in the concurrency control program segment.
  • the DistributedLockAspect class mainly encapsulates the implementation logic of the Redis distributed lock, so as to realize the locking processing of the deduction request, specifically ,
  • the DistributedLockAspect class uses the lock and unlock methods for concurrent lock control.
  • the specific implementation process of the DistributedLockAspect class program is: define "method annotation @Lock" and "parameter annotation @ParamLock", that is, use Spring annotation @Aspect to customize a distributed
  • the lock dynamic proxy class namely the DistributedLockAspect class, implements concurrency control.
  • the concurrency control program segment can intercept the deduction request when the target server side that detects the deduction request is determined. The purpose of intercepting the deduction request is to Debit requests are locked.
  • Step S22 Lock the deduction request based on the distributed lock method provided by the Redis database.
  • the debit request is locked based on the distributed locking method provided by the Redis database.
  • the step of locking the deduction request based on the distributed locking method provided by the Redis database includes:
  • Step S221 Obtain the user account corresponding to the deduction request, the IP address of the target server, and the preset lock timeout time;
  • the deduction request carries the user account, the IP address of the target server side and the preset lock time, so the corresponding user account, the IP address of the target server side and the preset can be extracted from the deduction request Lock over time.
  • Step S222 Based on the Redis database, set the user account and the preset prefix to the first parameter content of the first parameter key pre-stored in the distributed locking mode, and set the IP address of the target server to the distributed locking mode Pre-store the second parameter content of the second parameter value, and set the preset lock overtime as the third parameter content of the third parameter second pre-stored in the distributed locking mode to obtain the target corresponding to the deduction request lock;
  • the specific locking process is set using the setnx (key, value, second) method provided by Redis, where key is the first parameter, value is the second parameter, and second is the third parameter.
  • the user account And the preset prefix are set as the first parameter content of the first parameter key pre-stored in the distributed locking method, for example, the prefix “LOCK_KEY_ACCT_” + user account is used as the first parameter content, and the IP address of the target server is set to be distributed
  • the second parameter content of the second parameter value is pre-stored in the lock mode, in particular, the IP address of the target server and the current setting time are set as the second parameter content of the pre-stored second parameter value in the distributed lock mode, For example, taking "node IP (target server) ******" + current system time as the second parameter content, the preset lock timeout time is set to the third parameter second pre-stored in the distributed locking method
  • the content of the third parameter for example, the lock timeout time may be set to 180 seconds, and the content of the third
  • Step S223 Perform verification processing on the target lock to determine whether a preset return value is received
  • Step S224 if the preset return value is received, it is determined that the deduction request is successfully locked.
  • setnx if setnx returns the preset return value or returns true, it means that the lock is successful, and the charge operation can be performed. If setnx does not return the preset return value and does not return true, it means that the lock fails.
  • Step S225 Store the deduction request after successful locking in the Redis database, and regularly scan each deduction request after locking processing stored in the Redis database;
  • the deduction request after successful locking is stored in the Redis database, and after the deduction request after locking processing is sent to the target server, the target server will process the deduction after locking Request, because the target server may be under maintenance, or the target server may not be working properly, the target server may not be able to complete the deduction operation.
  • the compensation mechanism includes: the collection system starts the pre-stored JAVAJOB (timed task), and regularly scans the deduction request after locking processing saved in Redis.
  • the "node IP (target server) ******" + current system time is used as the second parameter, it is possible to obtain the storage time of the deduction request after the lock processing in the Redis database.
  • the storage time of the deduction request after lock processing in the Redis database is greater than the lock timeout time, if the storage time is greater than 180 seconds (lock timeout time), it will be unlocked immediately to release the locked resources to ensure that the account is not locked abnormally The operation is executed smoothly.
  • the lock can be released after the deduction is successful, that is, after the deduction is successful, the user account corresponding to the deduction request is not locked to avoid affecting the client's next deduction operation.
  • the IP address of the target server and the preset lock timeout time are set to distributed locking
  • the first parameter content of the first parameter key is pre-stored in the mode
  • the IP address of the target server is set to the second parameter content of the second parameter value pre-stored in the distributed locking mode
  • the preset lock overtime is set
  • Pre-store the third parameter content of the third parameter second in the distributed lock mode to obtain the target lock corresponding to the deduction request; verify the target lock to determine whether a preset return value is received; if received When the preset return value is reached, it is determined that the deduction request is successfully locked.
  • the lock processing for the deduction request is implemented, which lays the foundation for avoiding repeated deductions.
  • the present application provides another embodiment of a deduction control method.
  • the deduction request after the lock processing is sent to the target server side for the target server side
  • After performing the pre-stored deduction operation steps corresponding to the user account corresponding to the deduction request after the lock processing includes:
  • step A1 if it is detected that the client server corresponding to the deduction request after the lock processing is successfully debited by the target server, the deduction request corresponding to the successful deduction is unlocked.
  • the deduction request corresponding to the successful deduction is unlocked. That is, in this embodiment, as long as the deduction is successful, it is unlocked to avoid affecting the client's subsequent non-simultaneous deduction operation.
  • the charge control method further includes:
  • Step B1 if it is detected that an unlocking completion instruction of the deduction request has been unlocked, obtain the unlocking type of the deduction request based on the unlocking completion instruction;
  • the unlock type of the deduction request is obtained based on the unlock completion instruction, where the unlock type includes an active unlock type and a passive unlock type,
  • the active unlocking type refers to unlocking after successful deduction
  • the passive unlocking type refers to unlocking unprocessed locked deduction requests after the lock timeout time is reached.
  • Step B2 if the unlocking type is an active unlocking type, it is determined to generate the first prompt message of successful deduction;
  • Step B3 if the unlocking type is a passive unlocking type, it is determined to generate a second prompt message that the deduction has failed.
  • the unlocking type is an active unlocking type, it is determined that the first prompt information of successful deduction is generated, and if the unlocking type is a passive unlocking type, it is determined that a second prompting information of the deduction failure is generated.
  • the prompt content and the prompt method of the first prompt information and the second prompt information are different to distinguish whether the prompt deduction is successful.
  • the unlocking type of the deduction request is obtained based on the unlocking completion instruction; if the unlocking type is an active unlocking type, it is determined to generate The first prompt message of successful payment deduction; if the unlock type is a passive unlock type, it is determined that the second prompt message of failed payment deduction is generated.
  • the unlocking type is a passive unlock type, it is determined that the second prompt message of failed payment deduction is generated.
  • differentiate between prompting active unlocking and passive unlocking to obtain a more effective prompting effect and improve user experience.
  • FIG. 3 is a schematic diagram of a device structure of a hardware operating environment involved in a solution of an embodiment of the present application.
  • the deduction control device in the embodiment of the present application may be a PC, or may be a smartphone, tablet computer, e-book reader, MP3 (Moving Picture Experts Group Audio Layer III, motion picture expert compression standard audio layer 3 player, MP4 (Moving Picture Experts Group Audio Layer IV, the standard audio layer for motion picture experts compression 3) Terminal devices such as players and portable computers.
  • MP3 Moving Picture Experts Group Audio Layer III, motion picture expert compression standard audio layer 3 player
  • MP4 Moving Picture Experts Group Audio Layer IV, the standard audio layer for motion picture experts compression 3
  • Terminal devices such as players and portable computers.
  • the charge control device may include: a processor 1001, such as a CPU, a memory 1005, and a communication bus 1002.
  • the communication bus 1002 is used to implement connection communication between the processor 1001 and the memory 1005.
  • the memory 1005 may be a high-speed RAM memory or a stable memory (non-volatile memory), such as disk storage.
  • the memory 1005 may optionally be a storage device independent of the foregoing processor 1001.
  • the charge control device may further include a target user interface, a network interface, a camera, and RF (Radio Frequency (radio frequency) circuits, sensors, audio circuits, WiFi modules, etc.
  • the target user interface may include a display (Display), an input unit such as a keyboard (Keyboard), and the optional target user interface may also include a standard wired interface and a wireless interface.
  • the network interface may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface).
  • the structure of the charge control device shown in FIG. 3 does not constitute a limitation on the charge control device, and may include more or less components than the illustration, or a combination of certain components, or different Parts arrangement.
  • the memory 1005 which is a computer storage medium, may include an operating system, a network communication module, and readable instructions for charge control.
  • the operating system is a program that manages and controls the hardware and software resources of the charge control device, and supports the operation of the charge control readable instructions and other software and / or programs.
  • the network communication module is used to implement communication between various components within the memory 1005 and other hardware and software in the charge control device.
  • the processor 1001 is used to execute the charge control readable instructions stored in the memory 1005 to implement the steps of any of the charge control methods described above.
  • the charge control device includes:
  • a receiving module configured to determine the target server side of the deduction request according to the current number of pending requests of the multiple server sides when receiving the deduction request;
  • a locking module configured to perform a locking process on the deduction request, and send the deduction request after the locking process to the target server side, so that the target server side
  • the user account corresponding to the deduction request corresponds to the execution of the pre-stored deduction operation.
  • the locking module includes:
  • a calling unit used to call a pre-stored concurrency control program segment to intercept the deduction request
  • the locking unit is used for locking the deduction request based on the distributed locking method provided by the Redis database.
  • the present application provides a readable storage medium that stores one or more computer-readable instructions, and the one or more computer-readable instructions may also be executed by one or more processors to Steps for realizing any of the deduction control methods described above.
  • the readable storage medium may be a non-volatile readable storage medium.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Technology Law (AREA)
  • Marketing (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种扣款控制方法、装置、设备及可读存储介质，基于分布式云部署技术，所述方法包括：在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端（S10）；对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作（S20）。该方法解决现有银行在扣款时，易重复扣款并影响用户体验的技术问题。

Description

扣款控制方法、装置、设备及可读存储介质
本申请要求于2018年11月20日提交中国专利局、申请号为201811394571.2、发明名称为“扣款控制方法、装置、设备及可读存储介质”的中国专利申请的优先权，其全部内容通过引用结合在申请中。
技术领域
本申请涉及金融技术领域，尤其涉及一种扣款控制方法、装置、设备及可读存储介质。
背景技术
目前，银行是基于分布式部署的服务器端对用户进行实时扣款的，与单点式部署的服务器端对用户进行实时扣款方式不同，基于分布式部署的服务器端对用户进行实时扣款，时常会造成重复扣款的情况，例如，服务人员因不小心在短时间内触发对同一账户的扣款操作而对应生成两次扣款请求时，往往会造成重复扣款，也即在生成两次扣款请求时，由于分布式部署的服务器端是竞争处理扣款请求的，若其中一个服务器处理某一扣款请求时，另一个服务器也会进行另一扣款请求的处理（由于服务器是分布式的，因而无法识别是否存在重复的扣款请求），因而，重复扣款的现象还是难以消除。
发明内容
本申请的主要目的在于提供一种扣款控制方法、装置、设备及可读存储介质，旨在解决现有银行在扣款时，易重复扣款并影响用户体验的技术问题。
为实现上述目的，本申请提供一种扣款控制方法，所述扣款控制方法应用于催收系统，所述催收系统包括分布式分布的多个服务器端，所述扣款控制方法包括：
在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端；
对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。
可选地，所述对所述扣款请求进行加锁处理步骤包括：
调用预存的并发控制程序段，以拦截所述扣款请求；
基于Redis数据库提供的分布式加锁方式对所述扣款请求进行加锁处理。
可选地，所述基于Redis数据库提供的分布式加锁方式对所述扣款请求进行加锁处理步骤包括：
获取所述扣款请求对应的用户账号、目标服务器端的IP地址以及预设的锁超时间；
基于Redis数据库，将所述用户账号与预设前缀设置为分布式加锁方式中预存第一参数key的第一参数内容，将所述目标服务器端的IP地址设置为分布式加锁方式中预存第二参数value的第二参数内容，将所述预设的锁超时间设置为分布式加锁方式中预存第三参数second的第三参数内容，以得到所述扣款请求对应的目标锁；
对所述目标锁进行验证处理，确定是否接收到预设返回值；
若接收到预设返回值，则确定成功加锁所述扣款请求。
可选地，所述若接收到预设返回值，则确定成功加锁所述扣款请求步骤之后包括：
将成功加锁后的所述扣款请求存储在Redis数据库中，并定时扫描所述Redis数据库中存储的各个加锁处理后的扣款请求；
若检测到各个加锁处理后的扣款请求在Redis数据库中的存储时间大于锁超时间时，则对所述存储时间大于锁超时间的加锁处理后的扣款请求进行解锁处理。
可选地，所述将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作步骤之后包括：
若检测到所述目标服务器端对加锁处理后的所述扣款请求相应的客户端扣款成功时，则对所述扣款成功对应的扣款请求进行解锁处理。
可选地，所述扣款控制方法还包括：
若检测到扣款请求已解锁处理的解锁完成指令，则基于所述解锁完成指令获取所述扣款请求的解锁类型；
若所述解锁类型为主动解锁类型，则确定生成扣款成功的第一提示信息；
若所述解锁类型为被动解锁类型，则确定生成扣款失败的第二提示信息。
本申请还提供一种扣款控制装置，所述扣款控制装置包括：
接收模块，用于在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端；
加锁模块，用于对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。
可选地，所述加锁模块包括：
调用单元，用于调用预存的并发控制程序段，以拦截所述扣款请求；
加锁单元，用于基于Redis数据库提供的分布式加锁方式对所述扣款请求进行加锁处理。
可选地，所述加锁单元包括：
第一获取子单元，用于获取所述扣款请求对应的用户账号、目标服务器端的IP地址以及预设的锁超时间；
设置子单元，用于基于Redis数据库，将所述用户账号与预设前缀设置为分布式加锁方式中预存第一参数key的第一参数内容，将所述目标服务器端的IP地址设置为分布式加锁方式中预存第二参数value的第二参数内容，将所述预设的锁超时间设置为分布式加锁方式中预存第三参数second的第三参数内容，以得到所述扣款请求对应的目标锁；
验证子单元，用于对所述目标锁进行验证处理，确定是否接收到预设返回值；
确定子单元，用于若接收到预设返回值，则确定成功加锁所述扣款请求。
可选地，所述加锁单元还包括：
存储子单元，用于将成功加锁后的所述扣款请求存储在Redis数据库中，并定时扫描所述Redis数据库中存储的各个加锁处理后的扣款请求；
检测子单元，用于若检测到各个加锁处理后的扣款请求在Redis数据库中的存储时间大于锁超时间时，则对所述存储时间大于锁超时间的加锁处理后的扣款请求进行解锁处理。
可选地，所述扣款控制装置还包括：
解锁模块，用于若检测到所述目标服务器端对加锁处理后的所述扣款请求相应的客户端扣款成功时，则对所述扣款成功对应的扣款请求进行解锁处理。
可选地，所述扣款控制装置还包括：
获取模块，用于若检测到扣款请求已解锁处理的解锁完成指令，则基于所述解锁完成指令获取所述扣款请求的解锁类型；
第一确定模块，用于若所述解锁类型为主动解锁类型，则确定生成扣款成功的第一提示信息；
第二确定模块，用于若所述解锁类型为被动解锁类型，则确定生成扣款失败的第二提示信息。
此外，为实现上述目的，本申请还提供一种扣款控制设备，所述扣款控制设备包括：存储器、处理器，通信总线以及存储在所述存储器上的扣款控制可读指令，
所述通信总线用于实现处理器与存储器间的通信连接；
所述处理器用于执行所述扣款控制可读指令，以实现以下步骤：
在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端；
对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。
此外，为实现上述目的，本申请还提供一种可读存储介质，所述可读存储介质存储有一个或者一个以上程序，所述一个或者一个以上程序可被一个或者一个以上的处理器执行以用于：
在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端；
对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。
本申请在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端；对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。在本申请中，在接收到扣款请求时，首先确定目标服务器，然后对扣款请求进行加锁并进行处理，在加锁后，该扣款请求对应的客户端是同步被加锁的，因而，若存在与该扣款请求同步的其它扣款请求，该其它扣款请求会被遗弃不处理，因而，能够避免重复扣款，提升用户体验，进而解决了现有银行在扣款时，易重复扣款并影响用户体验的技术问题。
附图说明
图1为本申请扣款控制方法第一实施例的流程示意图；
图2为本申请扣款控制方法第二实施例中对所述扣款请求进行加锁处理步骤的细化流程示意图；
图3是本申请实施例方法涉及的硬件运行环境的设备结构示意图；
图4是本申请扣款控制装置的流程示意图。
本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。
本申请提供一种扣款控制方法，在本申请扣款控制方法的第一实施例中，参照图1，所述扣款控制方法应用于催收系统，所述催收系统包括分布式分布的多个服务器端，所述扣款控制方法包括：
步骤S10，在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端；
步骤S20，对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。
具体步骤如下：
步骤S10，在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端；
在本实施例中，所述扣款控制方法应用于催收系统，所述催收系统包括分布式分布的多个服务器端，该多个服务器端都具有处理扣款请求的功能，其中，在接收到扣款请求时，该多个服务器端可以竞争处理该扣款请求，具体竞争方式可以是：根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端，服务器端当前的待处理请求数目越少，则竞争力度越大，服务器端当前的待处理请求数目越多，则竞争力度越小，另外，具体竞争方式还可以是：根据服务器端的处理速度或者处理能力确定，具体地，服务器端的配置性能越好，则服务器端的处理速度或者处理能力越高，服务器端的处理速度或者处理能力越高，则该服务器端的竞争力度越大，越有可能竞争得到扣款请求。
在接收到扣款请求后，催收系统通过上述竞争方式确定目标服务器端，并需要将所述扣款请求发送给所述目标服务器端。
步骤S20，对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。
在本实施例中，在确定扣款请求的目标服务器端后，对所述扣款请求进行加锁处理，其中，对所述扣款请求进行加锁处理包括如下两种方式：
方式一：将扣款请求发送给催收系统中的缓存子系统，在缓存子系统中对扣款请求进行加锁处理，在加锁处理完成后，将加锁完成的扣款请求发送给目标服务器端；
方式二：直接将扣款请求发送给目标服务器端，在目标服务器端进行扣款请求的加锁处理。
在本实施例中，上述方式一的方式，若存在所述扣款请求对应的其它扣款请求时，如服务人员因不小心在短时间内触发对同一账户的扣款操作而对应生成两次扣款请求时，该其它扣款请求不会被加锁处理，且不会被发送到该其它扣款请求对应的目标服务器端，而对于上述方式二的方式，在存在扣款请求对应的其它扣款请求时，该其它扣款请求不会被加锁处理，但是该其它扣款请求可能会被发送到该其它扣款请求对应的目标服务器端。
需要说明的是，对于被加锁的扣款请求而言，若该扣款请求被加锁，则该扣款请求对应的客户端的账号是被同步加锁的，也即，在扣款请求被加锁时，该用户账号是不能够再进行其它扣款操作的，用以具体实施例进行说明，在扫描银行付款码进行付款时，该银行付款码被先后扫描两次，生成两个对应的付款请求，则对该其中一个付款请求进行加锁后，该另一个付款请求是不能够被同步加锁的，因为，该银行账号已经存在被加锁的记录。
在加锁扣款请求后，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。
其中，目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作步骤包括：获取扣款请求中所携带的扣款金额，扣款账号，扣款协议，基于该扣款金额，扣款账号以及扣款协议，向银行请求扣款。
在本实施例中，在接收到扣款请求并对扣款请求进行处理的过程中，是生成了操作日志文件的，该操作日志文件是可以基于NOSQL（非关系型）的内存数据库Redis，并利用Redis的持久化存储实现的。
在接收到扣款请求时，基于Redis的持久化存储AOF模式，将“操作 + 数据”以格式化指令的方式追加到相应操作日志文件的尾部，即是只要从接收到扣款请求开始，即将对扣款请求进行的处理流程步骤以及在处理流程步骤中得到的各数据均写入至日志文件中，在日志文件中保存了所有的历史操作过程，因而，当需要数据恢复时，根据日志文件，可还原所有的操作过程。避免无法找到扣款记录而造成的各项损失。
另外，在本实施例中，在检测到对扣款请求进行加锁时，将加锁后的扣款请求实时持久化存储至Redis数据库中。
本申请在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端；对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。在本申请中，在接收到扣款请求时，首先确定目标服务器，然后对扣款请求进行加锁并进行处理，在加锁后，该扣款请求对应的客户端是同步被加锁的，因而，若存在与该扣款请求同步的其它扣款请求，该其它扣款请求会被遗弃不处理，因而，能够避免重复扣款，提升用户体验，进而解决了现有银行在扣款时，易重复扣款并影响用户体验的技术问题。
进一步地，本申请提供扣款控制方法的另一实施例，在该实施例中，参照图2，所述对所述扣款请求进行加锁处理步骤包括：
步骤S21，调用预存的并发控制程序段，以拦截所述扣款请求；
催收系统中预存有并发控制程序段，该并发控制程序段中预存有DistributedLockAspect类，该DistributedLockAspect类主要封装Redis分布式锁的实现逻辑，以实现对对所述扣款请求进行加锁处理，具体地，该DistributedLockAspect类利用lock与unlock方法进行并发锁控制，具体DistributedLockAspect类程序上的实现过程为：定义“方法注解@Lock”以及“参数注解@ParamLock”，即利用Spring注解@Aspect自定义一个分布式锁动态代理类也即DistributedLockAspect类，实现并发控制，具体地，该并发控制程序段能够在检测到扣款请求的目标服务器端确定时，拦截所述扣款请求，拦截扣款请求的目的在于对扣款请求进行加锁处理。
步骤S22，基于Redis数据库提供的分布式加锁方式对所述扣款请求进行加锁处理。
在本实施例中，是基于Redis数据库提供的分布式加锁方式对所述扣款请求进行加锁处理的。
具体地，所述基于Redis数据库提供的分布式加锁方式对所述扣款请求进行加锁处理步骤包括：
步骤S221，获取所述扣款请求对应的用户账号、目标服务器端的IP地址以及预设的锁超时间；
在本实施例中，扣款请求中携带用户账号、目标服务器端的IP地址以及预设的锁超时间，因而，能从扣款请求中提取得到对应的用户账号、目标服务器端的IP地址以及预设的锁超时间。
步骤S222，基于Redis数据库，将所述用户账号与预设前缀设置为分布式加锁方式中预存第一参数key的第一参数内容，将所述目标服务器端的IP地址设置为分布式加锁方式中预存第二参数value的第二参数内容，将所述预设的锁超时间设置为分布式加锁方式中预存第三参数second的第三参数内容，以得到所述扣款请求对应的目标锁；
具体加锁处理过程是使用Redis提供的setnx(key,value,second)方法设置的，其中，key为第一参数，value为第二参数，second为第三参数，具体地，将所述用户账号与预设前缀设置为分布式加锁方式中预存第一参数key的第一参数内容，例如，以“LOCK_KEY_ACCT_”前缀+用户账号作为第一参数内容，将所述目标服务器端的IP地址设置为分布式加锁方式中预存第二参数value的第二参数内容，特别地，将所述目标服务器端的IP地址与当前设置时间设置为分布式加锁方式中预存第二参数value的第二参数内容，例如，以“节点IP（目标服务器）******”+系统当前时间作为第二参数内容，将所述预设的锁超时间设置为分布式加锁方式中预存第三参数second的第三参数内容，例如锁超时时间可以设置为180秒，second的第三参数内容为180S，在设置完成后，得到所述扣款请求对应的目标锁。
步骤S223，对所述目标锁进行验证处理，确定是否接收到预设返回值；
在本实施例中，判断本实施例中通过setnx(key,value,second)方法设置的setnx是否返回预设返回值或者是否返回true。
步骤S224，若接收到预设返回值，则确定成功加锁所述扣款请求。
在本实施例中，若setnx返回预设返回值或者返回true，则说明加锁成功，则可以进行扣款操作，若setnx未返回预设返回值且未返回true，则说明加锁失败。
进一步地，所述若接收到预设返回值，则确定成功加锁所述扣款请求步骤之后包括：
步骤S225，将成功加锁后的所述扣款请求存储在Redis数据库中，并定时扫描所述Redis数据库中存储的各个加锁处理后的扣款请求；
在本实施例中，将成功加锁后的所述扣款请求存储在Redis数据库中，在将加锁处理后的扣款请求发送给目标服务器端后，目标服务器会处理加锁后的扣款请求，由于目标服务器可能在维修中，或者是目标服务器可能处于不能正常工作的状态，因而目标服务器可能不能够完成扣款操作，此时，为避免死锁的情况，在本实施例中，还会获取提供异常情况下的补偿机制，补偿机制包括：催收系统启动预存的JAVAJOB（定时任务），定时扫描Redis中保存的加锁处理后的扣款请求。
步骤S226，若检测到各个加锁处理后的扣款请求在Redis数据库中的存储时间大于锁超时间时，则对所述存储时间大于锁超时间的加锁处理后的扣款请求进行解锁处理。
由于以“节点IP（目标服务器）******”+系统当前时间作为第二参数内容，因而，能够获取加锁处理后的扣款请求在Redis数据库中的存储时间，若检测到各个加锁处理后的扣款请求在Redis数据库中的存储时间大于锁超时间时，如存储时间大180秒（锁超时间），则立即解锁，释放锁定资源，确保账户不被异常锁定，保证扣款操作顺利执行。扣款成功后即可释放锁，也即在扣款成功后，扣款请求对应的用户账号是未被锁住的，避免影响客户端的下次扣款操作。
在本实施例中，通过获取所述扣款请求对应的用户账号、目标服务器端的IP地址以及预设的锁超时间；基于Redis数据库，将所述用户账号与预设前缀设置为分布式加锁方式中预存第一参数key的第一参数内容，将所述目标服务器端的IP地址设置为分布式加锁方式中预存第二参数value的第二参数内容，将所述预设的锁超时间设置为分布式加锁方式中预存第三参数second的第三参数内容，以得到所述扣款请求对应的目标锁；对所述目标锁进行验证处理，确定是否接收到预设返回值；若接收到预设返回值，则确定成功加锁所述扣款请求。在本实施例中，实现对扣款请求的加锁处理，为避免重复扣款奠定基础。
进一步地，本申请提供扣款控制方法的另一实施例，在该实施例中，所述将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作步骤之后包括：
步骤A1，若检测到所述目标服务器端对加锁处理后的所述扣款请求相应的客户端扣款成功时，则对所述扣款成功对应的扣款请求进行解锁处理。
在本实施例中，若检测到所述目标服务器端对加锁处理后的所述扣款请求相应的客户端扣款成功时，则对所述扣款成功对应的扣款请求进行解锁处理。也即在本实施例中，只要扣款成功即解锁，避免影响客户端后续非同时的扣款操作。
所述扣款控制方法还包括：
步骤B1，若检测到扣款请求已解锁处理的解锁完成指令，则基于所述解锁完成指令获取所述扣款请求的解锁类型；
在本实施例中，若检测到扣款请求已解锁处理的解锁完成指令，则基于所述解锁完成指令获取所述扣款请求的解锁类型，其中，解锁类型包括主动解锁类型与被动解锁类型，主动解锁类型指的是扣款成功后的解锁，被动解锁类型指的是到达锁超时间后，未被处理的加锁后的扣款请求的解锁。
步骤B2，若所述解锁类型为主动解锁类型，则确定生成扣款成功的第一提示信息；
步骤B3，若所述解锁类型为被动解锁类型，则确定生成扣款失败的第二提示信息。
若所述解锁类型为主动解锁类型，则确定生成扣款成功的第一提示信息，若所述解锁类型为被动解锁类型，则确定生成扣款失败的第二提示信息。其中，第一提示信息与第二提示信息的提示内容以及提示方式均不相同，以区别提示扣款成功与否。
在本实施例中，若检测到扣款请求已解锁处理的解锁完成指令，则基于所述解锁完成指令获取所述扣款请求的解锁类型；若所述解锁类型为主动解锁类型，则确定生成扣款成功的第一提示信息；若所述解锁类型为被动解锁类型，则确定生成扣款失败的第二提示信息。在本实施例中，区分提示主动解锁以及被动解锁，取得更有效的提示效果，提升用户体验。
参照图3，图3是本申请实施例方案涉及的硬件运行环境的设备结构示意图。
本申请实施例扣款控制设备可以是PC，也可以是智能手机、平板电脑、电子书阅读器、MP3（Moving Picture Experts Group Audio Layer III，动态影像专家压缩标准音频层面3）播放器、MP4（Moving Picture Experts Group Audio Layer IV，动态影像专家压缩标准音频层面3）播放器、便携计算机等终端设备。
如图3所示，该扣款控制设备可以包括：处理器1001，例如CPU，存储器1005，通信总线1002。其中，通信总线1002用于实现处理器1001和存储器1005之间的连接通信。存储器1005可以是高速RAM存储器，也可以是稳定的存储器（non-volatile memory），例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储设备。
可选地，该扣款控制设备还可以包括目标用户接口、网络接口、摄像头、RF（Radio Frequency，射频）电路，传感器、音频电路、WiFi模块等等。目标用户接口可以包括显示屏（Display）、输入单元比如键盘（Keyboard），可选目标用户接口还可以包括标准的有线接口、无线接口。网络接口可选的可以包括标准的有线接口、无线接口（如WI-FI接口）。
本领域技术人员可以理解，图3中示出的扣款控制设备结构并不构成对扣款控制设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。
如图3所示，作为一种计算机存储介质的存储器1005中可以包括操作系统、网络通信模块以及扣款控制可读指令。操作系统是管理和控制扣款控制设备硬件和软件资源的程序，支持扣款控制可读指令以及其它软件和/或程序的运行。网络通信模块用于实现存储器1005内部各组件之间的通信，以及与扣款控制设备中其它硬件和软件之间通信。
在图3所示的扣款控制设备中，处理器1001用于执行存储器1005中存储的扣款控制可读指令，实现上述任一项所述的扣款控制方法的步骤。
本申请扣款控制设备具体实施方式与上述扣款控制方法各实施例基本相同，在此不再赘述。
本申请还提供一种扣款控制装置，参照图4，所述扣款控制装置包括：
接收模块，用于在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端；
加锁模块，用于对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。
可选地，所述加锁模块包括：
调用单元，用于调用预存的并发控制程序段，以拦截所述扣款请求；
加锁单元，用于基于Redis数据库提供的分布式加锁方式对所述扣款请求进行加锁处理。
本申请扣款控制装置具体实施方式与上述扣款控制方法各实施例基本相同，在此不再赘述。
本申请提供了一种可读存储介质，所述可读存储介质存储有一个或者一个以上计算机可读指令，所述一个或者一个以上计算机可读指令还可被一个或者一个以上的处理器执行以用于实现上述任一项所述的扣款控制方法的步骤。该可读存储介质可以为非易失性可读存储介质。
本申请可读存储介质具体实施方式与上述扣款控制方法各实施例基本相同，在此不再赘述。
以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利处理范围内。

Claims (20)

  1. 一种扣款控制方法，其特征在于，所述扣款控制方法应用于催收系统，所述催收系统包括分布式分布的多个服务器端，所述扣款控制方法包括：
    在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端；
    对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。
  2. 如权利要求1所述的扣款控制方法，其特征在于，所述对所述扣款请求进行加锁处理步骤包括：
    调用预存的并发控制程序段，以拦截所述扣款请求；
    基于Redis数据库提供的分布式加锁方式对所述扣款请求进行加锁处理。
  3. 如权利要求2所述的扣款控制方法，其特征在于，所述将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作步骤之后包括：
    若检测到所述目标服务器端对加锁处理后的所述扣款请求相应的客户端扣款成功时，则对所述扣款成功对应的扣款请求进行解锁处理。
  4. 如权利要求2所述的扣款控制方法，其特征在于，所述扣款控制方法还包括：
    若检测到扣款请求已解锁处理的解锁完成指令，则基于所述解锁完成指令获取所述扣款请求的解锁类型；
    若所述解锁类型为主动解锁类型，则确定生成扣款成功的第一提示信息；
    若所述解锁类型为被动解锁类型，则确定生成扣款失败的第二提示信息。
  5. 如权利要求2所述的扣款控制方法，其特征在于，所述基于Redis数据库提供的分布式加锁方式对所述扣款请求进行加锁处理步骤包括：
    获取所述扣款请求对应的用户账号、目标服务器端的IP地址以及预设的锁超时间；
    基于Redis数据库，将所述用户账号与预设前缀设置为分布式加锁方式中预存第一参数key的第一参数内容，将所述目标服务器端的IP地址设置为分布式加锁方式中预存第二参数value的第二参数内容，将所述预设的锁超时间设置为分布式加锁方式中预存第三参数second的第三参数内容，以得到所述扣款请求对应的目标锁；
    对所述目标锁进行验证处理，确定是否接收到预设返回值；
    若接收到预设返回值，则确定成功加锁所述扣款请求。
  6. 如权利要求5所述的扣款控制方法，其特征在于，所述将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作步骤之后包括：
    若检测到所述目标服务器端对加锁处理后的所述扣款请求相应的客户端扣款成功时，则对所述扣款成功对应的扣款请求进行解锁处理。
  7. 如权利要求5所述的扣款控制方法，其特征在于，所述扣款控制方法还包括：
    若检测到扣款请求已解锁处理的解锁完成指令，则基于所述解锁完成指令获取所述扣款请求的解锁类型；
    若所述解锁类型为主动解锁类型，则确定生成扣款成功的第一提示信息；
    若所述解锁类型为被动解锁类型，则确定生成扣款失败的第二提示信息。
  8. 如权利要求5所述的扣款控制方法，其特征在于，所述若接收到预设返回值，则确定成功加锁所述扣款请求步骤之后包括：
    将成功加锁后的所述扣款请求存储在Redis数据库中，并定时扫描所述Redis数据库中存储的各个加锁处理后的扣款请求；
    若检测到各个加锁处理后的扣款请求在Redis数据库中的存储时间大于锁超时间时，则对所述存储时间大于锁超时间的加锁处理后的扣款请求进行解锁处理。
  9. 如权利要求8所述的扣款控制方法，其特征在于，所述将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作步骤之后包括：
    若检测到所述目标服务器端对加锁处理后的所述扣款请求相应的客户端扣款成功时，则对所述扣款成功对应的扣款请求进行解锁处理。
  10. 如权利要求8所述的扣款控制方法，其特征在于，所述扣款控制方法还包括：
    若检测到扣款请求已解锁处理的解锁完成指令，则基于所述解锁完成指令获取所述扣款请求的解锁类型；
    若所述解锁类型为主动解锁类型，则确定生成扣款成功的第一提示信息；
    若所述解锁类型为被动解锁类型，则确定生成扣款失败的第二提示信息。
  11. 如权利要求1所述的扣款控制方法，其特征在于，所述将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作步骤之后包括：
    若检测到所述目标服务器端对加锁处理后的所述扣款请求相应的客户端扣款成功时，则对所述扣款成功对应的扣款请求进行解锁处理。
  12. 如权利要求11所述的扣款控制方法，其特征在于，所述扣款控制方法还包括：
    若检测到扣款请求已解锁处理的解锁完成指令，则基于所述解锁完成指令获取所述扣款请求的解锁类型；
    若所述解锁类型为主动解锁类型，则确定生成扣款成功的第一提示信息；
    若所述解锁类型为被动解锁类型，则确定生成扣款失败的第二提示信息。
  13. 如权利要求1所述的扣款控制方法，其特征在于，所述扣款控制方法还包括：
    若检测到扣款请求已解锁处理的解锁完成指令，则基于所述解锁完成指令获取所述扣款请求的解锁类型；
    若所述解锁类型为主动解锁类型，则确定生成扣款成功的第一提示信息；
    若所述解锁类型为被动解锁类型，则确定生成扣款失败的第二提示信息。
  14. 一种扣款控制装置，其特征在于，所述扣款控制装置包括：
    接收模块，用于在接收到扣款请求时，根据所述多个服务器端当前的待处理请求数目确定所述扣款请求的目标服务器端；
    加锁模块，用于对所述扣款请求进行加锁处理，将所述加锁处理后的扣款请求发送给所述目标服务器端，以供所述目标服务器端对加锁处理后的所述扣款请求相应的用户账号对应执行预存的扣款操作。
  15. 如权利要求14所述的扣款控制装置，其特征在于，所述加锁模块包括：
    调用单元，用于调用预存的并发控制程序段，以拦截所述扣款请求；
    加锁单元，用于基于Redis数据库提供的分布式加锁方式对所述扣款请求进行加锁处理。
  16. 一种扣款控制设备，其特征在于，所述扣款控制设备包括：存储器、处理器，通信总线以及存储在所述存储器上的扣款控制可读指令，
    所述通信总线用于实现处理器与存储器间的通信连接；
    所述处理器用于执行所述扣款控制可读指令，以实现如权利要求1所述的扣款控制方法的步骤。
  17. 一种扣款控制设备，其特征在于，所述扣款控制设备包括：存储器、处理器，通信总线以及存储在所述存储器上的扣款控制可读指令，
    所述通信总线用于实现处理器与存储器间的通信连接；
    所述处理器用于执行所述扣款控制可读指令，以实现如权利要求2所述的扣款控制方法的步骤。
  18. 一种扣款控制设备，其特征在于，所述扣款控制设备包括：存储器、处理器，通信总线以及存储在所述存储器上的扣款控制可读指令，
    所述通信总线用于实现处理器与存储器间的通信连接；
    所述处理器用于执行所述扣款控制可读指令，以实现如权利要求3所述的扣款控制方法的步骤。
  19. 一种可读存储介质，其特征在于，所述可读存储介质上存储有扣款控制可读指令，所述扣款控制可读指令被处理器执行时实现如权利要求1所述的扣款控制方法的步骤。
  20. 一种可读存储介质，其特征在于，所述可读存储介质上存储有扣款控制可读指令，所述扣款控制可读指令被处理器执行时实现如权利要求2所述的扣款控制方法的步骤。
PCT/CN2018/123190 2018-11-20 2018-12-24 扣款控制方法、装置、设备及可读存储介质 Ceased WO2020103275A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811394571.2A CN109670807A (zh) 2018-11-20 2018-11-20 扣款控制方法、装置、设备及可读存储介质
CN201811394571.2 2018-11-20

Publications (1)

Publication Number Publication Date
WO2020103275A1 true WO2020103275A1 (zh) 2020-05-28

Family

ID=66142706

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2018/123190 Ceased WO2020103275A1 (zh) 2018-11-20 2018-12-24 扣款控制方法、装置、设备及可读存储介质

Country Status (2)

Country Link
CN (1) CN109670807A (zh)
WO (1) WO2020103275A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111324622A (zh) * 2020-02-20 2020-06-23 中国建设银行股份有限公司 一种资源抢购的处理方法、装置、设备及存储介质
CN111459963B (zh) * 2020-04-07 2024-03-15 中国建设银行股份有限公司 核心账务交易并发处理方法及装置
CN113593127B (zh) * 2020-04-30 2023-09-29 海南掌上能量传媒有限公司 一种移动电源租赁终端的控制方法
CN111833034B (zh) * 2020-07-02 2024-01-30 泰康保险集团股份有限公司 一种批量扣款方法、支付服务器、计算机设备及存储介质
CN112565467A (zh) * 2021-02-22 2021-03-26 常州微亿智造科技有限公司 业务处理方法、装置和存储介质
CN113516471B (zh) * 2021-07-07 2023-12-05 深圳市雪球科技有限公司 公交付费的方法、装置和设备
CN115049394B (zh) * 2022-07-05 2025-11-18 中国工商银行股份有限公司 交易扣款的处理方法、处理系统和处理装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103581273A (zh) * 2012-08-08 2014-02-12 阿里巴巴集团控股有限公司 一种分布式系统执行业务的方法、装置及系统
CN107358425A (zh) * 2017-06-29 2017-11-17 湖南搜云网络科技股份有限公司 交易费用的计算及支付方法和装置、交易平台及存储介质
CN107767140A (zh) * 2017-10-02 2018-03-06 头等尝网络餐饮管理科技（深圳）有限公司 支付方法、装置、设备及可读存储介质
CN107808285A (zh) * 2017-09-28 2018-03-16 深圳市生银万国网络科技有限公司 一种支付方法、设备及计算机可读存储介质
CN107818018A (zh) * 2016-09-14 2018-03-20 北京京东尚科信息技术有限公司 分布式锁的控制方法和装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103793843B (zh) * 2012-10-26 2017-10-13 阿里巴巴集团控股有限公司 一种账户数据的处理方法和装置
CN105988862B (zh) * 2015-02-04 2019-06-21 阿里巴巴集团控股有限公司 分布式事务处理方法及装置

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103581273A (zh) * 2012-08-08 2014-02-12 阿里巴巴集团控股有限公司 一种分布式系统执行业务的方法、装置及系统
CN107818018A (zh) * 2016-09-14 2018-03-20 北京京东尚科信息技术有限公司 分布式锁的控制方法和装置
CN107358425A (zh) * 2017-06-29 2017-11-17 湖南搜云网络科技股份有限公司 交易费用的计算及支付方法和装置、交易平台及存储介质
CN107808285A (zh) * 2017-09-28 2018-03-16 深圳市生银万国网络科技有限公司 一种支付方法、设备及计算机可读存储介质
CN107767140A (zh) * 2017-10-02 2018-03-06 头等尝网络餐饮管理科技（深圳）有限公司 支付方法、装置、设备及可读存储介质

Also Published As

Publication number Publication date
CN109670807A (zh) 2019-04-23

Similar Documents

Publication Publication Date Title
WO2020103275A1 (zh) 扣款控制方法、装置、设备及可读存储介质
WO2020253135A1 (zh) 自动化分析方法、用户设备、存储介质及装置
WO2019144738A1 (zh) 金融业务的验证方法、装置、设备和计算机存储介质
WO2016137307A1 (en) Attestation by proxy
WO2020006852A1 (zh) 差旅费自助核销处理方法、装置、设备和计算机存储介质
WO2020215681A1 (zh) 指示信息生成方法、装置、终端及存储介质
WO2020147383A1 (zh) 基于区块链系统的流程审批方法、装置、系统及非易失性存储介质
WO2020062642A1 (zh) 基于区块链的电子合同签署方法、装置、设备及存储介质
WO2020107591A1 (zh) 重复投保限制方法、装置、设备及可读存储介质
WO2020224246A1 (zh) 基于区块链的数据管理方法、装置、设备和存储介质
WO2017067293A1 (zh) 一种指纹解锁的方法、装置和终端
WO2020206899A1 (zh) 基于时间戳的身份验证方法、装置、设备及存储介质
WO2020147385A1 (zh) 数据录入方法、装置、终端及计算机可读存储介质
WO2020087981A1 (zh) 风控审核模型生成方法、装置、设备及可读存储介质
WO2020015060A1 (zh) 用电量异常评估方法、装置、设备和计算机存储介质
WO2018233352A1 (zh) 数据传输方法、装置、终端以及计算机可读存储介质
WO2018076844A1 (zh) 数据备份的方法、装置、存储介质及电子设备
WO2018076865A1 (zh) 数据分享方法、装置、存储介质及电子设备
WO2020233073A1 (zh) 区块链环境检测方法、设备、装置及存储介质
WO2020098075A1 (zh) 金融数据处理方法、装置、设备和存储介质
WO2020233060A1 (zh) 事件通知方法、事件通知服务器、存储介质及装置
WO2020119369A1 (zh) 智能it运维故障定位方法、装置、设备及可读存储介质
WO2020237849A1 (zh) 网络块设备快照读写方法、装置、设备及存储介质
WO2020019405A1 (zh) 数据库监控方法、装置、设备及可读存储介质
WO2020119384A1 (zh) 基于大数据分析的医保异常检测方法、装置、设备和介质

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: 18940638

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: 18940638

Country of ref document: EP

Kind code of ref document: A1