WO2017162056A1 - 一种业务处理方法、装置及系统 - Google Patents

一种业务处理方法、装置及系统 Download PDF

Info

Publication number
WO2017162056A1
WO2017162056A1 PCT/CN2017/076397 CN2017076397W WO2017162056A1 WO 2017162056 A1 WO2017162056 A1 WO 2017162056A1 CN 2017076397 W CN2017076397 W CN 2017076397W WO 2017162056 A1 WO2017162056 A1 WO 2017162056A1
Authority
WO
WIPO (PCT)
Prior art keywords
service processing
request
service
reference information
information
Prior art date
Application number
PCT/CN2017/076397
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 阿里巴巴集团控股有限公司
Priority to EP17769333.0A priority Critical patent/EP3435604B1/en
Priority to JP2018550376A priority patent/JP6921107B2/ja
Publication of WO2017162056A1 publication Critical patent/WO2017162056A1/zh
Priority to US16/137,306 priority patent/US11445030B2/en

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • G06F16/278—Data partitioning, e.g. horizontal or vertical partitioning

Definitions

  • the present application relates to the field of computer application technologies, and in particular, to a service processing method, apparatus, and system.
  • the idempotent operation is characterized by the fact that its effects of any number of executions are the same as those of one execution. In practical applications, idempotent operations are often used to avoid the effects of repeated operations on the system. . Taking the financial system as an example, for a single account transfer or transfer request, it must be ensured that the request only results in an actual transfer process, and does not allow multiple transfer transactions due to network delays, etc., so the financial system needs to ensure that it is externally The idempotency of the accounting interface.
  • a common practice in the prior art is to establish a unique constraint for each service request in a database on the business system side, for example, to establish an idempotent table in the database, and each time before processing the service request, it is required to A certain identification information of the service request (for example, "service request number”, “service request number + service type”, "business request number + service request source”, etc.) is inserted into this table, if the insertion is successful, the description If the business system processes the service request for the first time, it continues the normal business process; if the insertion fails, the information of the service already exists in the idempot table, that is, the service system has processed the service request before, then Directly determining that the request is a duplicate request, and then stopping processing the request.
  • a certain identification information of the service request for example, "service request number”, “service request number + service type", "business request number + service request source”, etc.
  • the above solution can better achieve the idempotency of the external interface of the service system.
  • the application of data partitioning or sub-storage storage is more and more common.
  • a situation may occur: In the same service, the request sends multiple requests to the service system, and for some reason (such as disaster recovery handover, etc.), multiple requests are routed by the service system to different data tables, because the idempot table used by different data tables Different, so idempotent failures are likely to occur, which in turn leads to business duplication.
  • the present application provides a service processing method, apparatus, and system for solving the above technical problem.
  • the idempotent failure problem in the multi-database application scenario is as follows:
  • a service processing method comprising:
  • the service request side generates a service processing request carrying the service processing reference information, and sends the service processing request to the service processing side;
  • the service processing reference information is used by the service processing side to determine a storage location of the current service related data in the database,
  • the service processing request that is sent multiple times for the same service event carries the same service processing reference information;
  • the service processing side After receiving the service processing request, the service processing side determines a corresponding storage location according to the service processing reference information carried in the request, performs an idempotent check on the determined storage location, and processes the current service according to the idempotent check result.
  • a service processing method which is applied to a service request side, and the method includes:
  • the service processing reference information is used by the service processing side to determine the storage location of the related data of the current service in the database, and the service processing request that is sent multiple times for the same service event carries the same service processing reference information.
  • a service processing method which is applied to a service processing side, and the method includes:
  • the service processing reference information is used by the service processing side to determine the storage location of the related data of the current service in the database, and the service processing request that the service request side sends for the same service event multiple times carries the same service processing reference information.
  • a service processing apparatus which is applied to a service request side, and the apparatus includes:
  • a request generation module configured to generate a service processing request that carries service processing reference information
  • a request sending module configured to send the service processing request to the service processing side, so that after receiving the service processing request, the service processing side determines a corresponding storage location according to the service processing reference information carried in the request, for determining The storage location is subjected to an idempotent check, and the current service is processed according to the result of the idempotent check;
  • the service processing reference information is used by the service processing side to determine related data of the current service in the database.
  • the storage location, the service processing request that is sent multiple times for the same service event carries the same service processing reference information.
  • a service processing apparatus which is applied to a service processing side, and the apparatus includes:
  • a request receiving module configured to receive a service processing request sent by a service requesting side, where the service processing request carries service processing reference information
  • a service processing module configured to determine a corresponding storage location according to the service processing reference information carried in the request, perform an idempotent check on the determined storage location, and process the current service according to the idempotent check result;
  • the service processing reference information is used by the service processing side to determine the storage location of the related data of the current service in the database, and the service processing request that the service request side sends for the same service event multiple times carries the same service processing reference information.
  • a service processing system comprising a service request side device and a service processing side device:
  • the service request side device includes:
  • a request generation module configured to generate a service processing request that carries service processing reference information
  • a request sending module configured to send the service processing request to a service processing side
  • the service processing reference information is used by the service processing side to determine the storage location of the related data of the current service in the database, and the service processing request that is sent multiple times for the same service event carries the same service processing reference information;
  • the service processing device includes:
  • a request receiving module configured to receive a service processing request sent by a service request side
  • the service processing module is configured to determine a corresponding storage location according to the service processing reference information carried in the request, perform an idempotent check on the determined storage location, and process the current service according to the idempotent check result.
  • the technical solution provided by the application adds service processing reference information to the service processing request sent by the service request side to the service processing side, and the service processing reference information carried in the service processing request sent multiple times for the same service event It is the same, so there is no case that multiple idempotent checks for the same business event are performed at different storage locations, thereby effectively avoiding the problem of business duplication processing.
  • FIG. 1 is a schematic flow chart of a service processing method of the present application
  • FIG. 2 is a schematic diagram of a database deployment scheme of the present application
  • FIG. 3 is a schematic structural diagram of a service request side device of the present application.
  • FIG. 4 is a schematic structural diagram of a service processing side device of the present application.
  • FIG. 5 is a schematic structural diagram of a service processing system of the present application.
  • data is generally stored in a manner of sub-tables.
  • the table can be implemented based on multiple dimensions.
  • One commonly used partitioning dimension is based on "time”.
  • Dimensions are divided into sub-tables. For example, 12 sub-tables are divided according to 1 year and 12 months, which are used to store business data corresponding to service requests initiated at different times.
  • redundant backup of the database is also a common processing scheme, that is, the data in the main library is completely copied to the FO (Failover) library, and the main library and the FO library are generally Deployed in different areas.
  • service requests are routed to the main library (normal mode).
  • service requests are routed to the FO library (failover mode).
  • the transfer platform on the service processing side receives the transfer request sent by A through an application platform at 23:59 on November 30, and routes the service to sub-table 11 (for November).
  • the general name of the corresponding sub-table) the identification information of the service can be successfully inserted in the idempotent table of the sub-table 11, so the service is normally processed: 100 yuan is transferred from the account A to the account B.
  • the application platform on the service request side does not receive a response that the service has successfully processed, and then determines that the processing timeout and resends the second transfer request to the transfer platform.
  • the transfer platform receives the second transfer request at 00:01 on December 1, and routes the service to the sub-table 12 (collectively for the December corresponding sub-table), and in the idempot table of the sub-table 12 There is no identification information of the transfer service, so the service can also be successfully inserted and processed normally, causing A to transfer 100 yuan to B again.
  • the transfer platform on the service processing side receives A for the first time.
  • the transfer request is sent by an application platform, the system is in the normal running state. Therefore, the service is routed to the data table in the main library.
  • the identification information of the service can be successfully inserted into the idempotent table of the main library. Therefore, the service is processed normally: Transferring 100 yuan from account A to account B; due to network problems, the application platform on the service request side did not receive a response that the service has successfully processed, and then determined that the processing timed out and resend the second transfer request to the transfer platform.
  • the main library fails, so the service is routed to the data table in the FO library, and the identification information of the transfer service does not exist in the idempot table of the FO library, so the same can be Successfully inserting and processing the business normally, causing A to transfer 100 yuan to B again.
  • the present application provides a service processing method. As shown in FIG. 1, the method may include the following steps:
  • the service request side generates a service processing request that carries service processing reference information.
  • the solution of the present application adds an extended parameter to the service processing request: the service processing reference information, and the role of the information is to enable the service processing side to be based on the information in the application scenario of the sub-database or the sub-table.
  • the service processing reference information determines the database storage location used to process the current business, that is, in which database (including main library/FO, sub-library, etc.) and/or which data table the related data processing operation needs in the process of processing the current business. So that the service processing side performs subsequent data processing operations in the determined storage location.
  • the solution of the present application does not require the service request to understand the actual sub-library or sub-table logic on the service processing side, and only the service processing reference information provided by the service request side can be identified by the service processing side, and the current service should be determined according to the information.
  • the specific database or data table can be.
  • the service request side only needs to obtain the current time information before sending the service processing request, and write the time information into the service processing request. Further, the service processing side may select a corresponding time dimension data sub-table according to the time information to perform subsequent processing.
  • the service request side needs to perceive the database operation mode information currently used by the service processing side before sending the service processing request.
  • the operation mode mentioned here includes the normal operation mode and the failover mode, and then The database run mode information is written into the business process request.
  • the service processing side may select a main library or a FO library for subsequent processing according to the database operation mode information.
  • the service requesting side may obtain the database running mode information actively pushed by the service request side or the middleware in a subscription manner, or obtain the database running mode information as needed when the service processing request needs to be sent, and the application does not need to be performed. limited.
  • service processing reference information are only used for illustrative purposes, and should not be construed as limiting the solution of the present application.
  • the service request side knows the sub-database table logic on the service processing side
  • multiple service processing reference information is allowed to be carried in a service processing request, for example, carrying the foregoing time information and database operation mode information, so as to simultaneously satisfy the time dimension. Scenario and failover scenario application requirements.
  • S102 The service requesting side sends the service processing request to the service processing side.
  • another function of the service processing reference information is to ensure the idempotency of the interface on the service processing side in the application scenario of the sub-database.
  • the service processing reference information carried in the service processing request that is required to be sent by the service requesting party for the same service event should be the same, so that the service processing side can process multiple requests based on the same service event. , all power checks for the same storage location, thus avoiding the problem of idempotent check failure.
  • the service requesting side may obtain service processing reference information (such as current time information, current database operation mode information, etc.) when the service processing request is first sent, write the information into the service processing request, and write to the first time.
  • the business process reference information is stored with the business event as the identifier. If the processing request for the same business event needs to be sent again, the previously stored business processing reference information is directly read and written into the new business processing request.
  • the solution of the present application only needs to ensure that the same service processing reference information is carried in the service processing request that is sent multiple times for the same service event. Therefore, the foregoing manner is not to be construed as limiting the solution of the present application.
  • the service request side also All or part of the first-time business processing request message body (including at least the first-time business processing reference information) may be directly saved, and when the resend request is subsequently performed, the pre-saved content may be read to retransmit. And ensure that the service processing reference information carried in multiple requests is the same.
  • the service processing side After receiving the service processing request, the service processing side determines the corresponding storage location according to the service processing reference information carried in the request.
  • the service processing side needs to determine, according to the service processing reference information provided by the service request side, which database (including the main library/FO, the sub-database, etc.) and/or the related data processing operation needs to be processed when processing the current service. Which data sheet is used.
  • the service processing side may determine the corresponding time dimension data table according to the time information; if the service operation request carries the database operation mode information, The business processing side determines whether to use the main library or the FO library based on the information.
  • the foregoing service processing reference information may only be a part of information for determining a storage location, for example, in a two-dimensional partitioning scheme based on "user number” and "time”, it is required to combine " Initiating the current requested user number (this information belongs to the information carried by default in the service request) and the "time information" to determine the specific data table; after determining the main library or the FO library, further determining according to the part table scheme Data table, and so on.
  • the “other information” belongs to the information that can be normally obtained according to the prior art solution, and the use of other information to determine the storage location may also adopt a solution consistent with the prior art, which does not affect the implementation of the solution of the present application.
  • S104 Perform an idempotent check on the determined storage location, and process the current service according to the idempotent check result.
  • the idempotent check in the solution of the present application may adopt the same scheme as the prior art, that is, a certain unique identifier of the service request before each processing of the service request.
  • Information (such as "business request number”, “service request number + service type”, “service request number + service request source”, etc.) is inserted into the idempot table corresponding to the current storage location.
  • the business system is The first time the service request is processed, the normal business process flow is continued; if the insertion fails, the information of the service already exists in the idempot table, that is, the service system has previously processed the service request, then the directly determined The request is a duplicate request and then stops processing the request.
  • this application does not need to define a specific idempotent check scheme.
  • each sub-table corresponds to an idempot table.
  • the data in the main library is fully backed up to the FO library, and the FO library and the main library have the same sub-table structure.
  • the service request is routed to the main library (normal mode), and the service request will be switched to the FO library (failover mode) in the disaster recovery state.
  • user A (user number is 10002) wishes to transfer 100 yuan to user B, and initiates a transfer request to the transfer platform through the application platform.
  • the application platform initiated the transfer request for the first time at 23:59 on November 30, 2015. And when the database is running in normal mode, the application platform writes "2015-11-30 23:59" and "normal mode" into the transfer request.
  • the transfer platform After receiving the above transfer request, the transfer platform first determines the storage location as the main library 02_11 table according to the information carried in the request, and then inserts the serial number of the transfer service into the idempot table of the main library 02_11 table, because the insertion is successful. Therefore, the business is handled normally: 100 yuan is transferred from account A to account B.
  • Scenario 1 Assume that due to network problems, the application platform does not receive a response that the service has successfully processed, and then determines that the processing timeout and resends the second transfer request to the transfer platform. The second time the transfer request was initiated was 00:01 on December 1, 2015, but in the second transfer request, the storage location information carried is still "2015-11-30 23:59" and "normal mode" ".
  • the transfer platform After receiving the second transfer request, the transfer platform determines the storage location as the main library 02_11 table according to the information carried in the request, and further performs the operation of inserting the serial number of the transfer service into the idempot table of the main library 02_11 table, because The same record already exists in the idempotent table, so the insertion fails, and then the processing of this transfer request is stopped, avoiding the erroneous retransfer process.
  • Scenario 2 It is still assumed that due to network problems, the application platform does not receive a response that the service has successfully processed, so it is determined that the processing timeout and resending the second transfer request to the transfer platform.
  • the second time the transfer request was initiated was 00:01 on December 1, 2015, and the database on the transfer system side has now switched to the failover mode.
  • the information carried is still "2015-11-30 23:59" and "normal mode”.
  • the transfer platform After receiving the second transfer request, the transfer platform determines the storage location as the main library 02_11 table according to the information carried in the request, and further performs the operation of inserting the serial number of the transfer service into the idempot table of the main library 02_11 table, but At this point, the main library failure cannot be accessed, so this business request cannot be processed. As a result, the wrong duplicate transfer processing is also avoided.
  • the application examples of the above-mentioned financial system are for illustrative purposes only and do not constitute a limitation on the application scenarios of the present application.
  • the application scenario can be applied.
  • the application plan guarantees the idempotency of the system interface.
  • the application scheme since the service processing reference information carried in the service processing request sent by the service request side for the same service event is the same, the application scheme does not have multiple idempotent checks for the same service event. The situation is carried out at different storage locations, thereby effectively avoiding the problem of business duplication processing.
  • the application further provides a service processing device applied to the service request side.
  • the device may include:
  • the request generating module 110 is configured to generate a service processing request that carries the service processing reference information.
  • the request sending module 120 is configured to send the service processing request to the service processing side, so that after receiving the service processing request, the service processing side determines the corresponding storage location according to the service processing reference information carried in the request, for the determined storage location. Perform an idempotent check to process the current service according to the result of the idempotent check;
  • the service processing reference information is used by the service processing side to determine the storage location of the current service related data in the database, and the service processing request that is sent multiple times for the same service event carries the same service processing reference information.
  • the service processing reference information may be time information
  • the request generating module 110 may be specifically configured to: if the service processing request is sent for the first time, obtain the current time information, write the time information into the service processing request, and subsequently request the retransmission for the service event. Carry the time information.
  • the service processing reference information may be database operation mode information
  • the database mode may include: a normal mode, a failover mode
  • the request generation module 110 may be specifically configured to: if the service processing request is sent for the first time, obtain the database operation mode information currently used by the service processing side, and write the database operation mode information into the service processing request, and subsequently The database operation mode information is carried in the request for retransmission of the service event.
  • the application further provides a service processing apparatus applied to a service processing side, where the apparatus may include:
  • the request receiving module 210 is configured to receive a service processing request sent by the service requesting side, where the service processing request carries the service processing reference information;
  • the service processing module 220 is configured to determine a corresponding storage location according to the service processing reference information carried in the request, perform an idempotent check on the determined storage location, and process the current service according to the idempotent check result;
  • the service processing reference information is used by the service processing side to determine the storage location of the related data of the current service in the database, and the service processing request that the service request side sends for the same service event multiple times carries the same service processing reference information.
  • the service processing reference information may be time information
  • the service processing module 220 may be specifically configured to: determine, according to the time information carried in the request, a time dimension data part table corresponding to the time information, perform an idempotent check on the determined data part table, and perform current service according to the idempotent check result. Process it.
  • the service processing reference information may be database operation mode information
  • the database mode may include: a normal mode, a failover mode
  • the service processing module 220 may be specifically configured to: determine a database corresponding to the database running mode information according to the database running mode information carried in the request, perform an idempotent check on the determined database, and process the current service according to the idempotent check result. .
  • the present application further provides a service processing system.
  • the system may include a service request side device 100 and a service processing device 200.
  • the devices on both sides refer to the previous embodiment. Repeat the explanation.
  • the present application can be implemented by means of software plus a necessary general hardware platform. Based on such understanding, the technical solution of the present application may be embodied in the form of a software product in essence or in the form of a software product, which may be stored in a storage medium such as a ROM/RAM or a disk. , an optical disk, etc., includes instructions for causing a computer device (which may be a personal computer, server, or network device, etc.) to perform the methods described in various embodiments of the present application or portions of the embodiments.
  • a computer device which may be a personal computer, server, or network device, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Hardware Redundancy (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种业务处理方法、装置及系统。所述业务处理方法包括：业务请求侧生成携带业务处理参考信息的业务处理请求，将所述业务处理请求发送至业务处理侧；针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息；业务处理侧接收到所述业务处理请求后，根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理。应用该方法，不会出现针对同一业务事件的多次幂等检查在不同存储位置进行的情况，从而有效地避免了业务重复处理的问题。

Description

一种业务处理方法、装置及系统
本申请要求2016年03月24日递交的申请号为201610173747.6、发明名称为“一种业务处理方法、装置及系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机应用技术领域，尤其涉及一种业务处理方法、装置及系统。
背景技术
在计算机系统中，幂等操作的特点是其任意多次执行所产生的影响均与一次执行的所产生的影响相同，在实际应用中，幂等操作常用于避免重复操作对系统的造成的影响。以金融系统为例，针对一次账务转入或转出请求，必须保证该请求只导致一次实际的转账处理，不允许由于网络延迟等原因导致多次转账处理，因此金融系统都需要保证其对外账务接口的幂等性，。
为了实现幂等性，现有技术的常用做法是在业务系统侧的数据库中针对每次业务请求建立唯一性约束，例如：在数据库中建立幂等表，每次处理业务请求之前，均要求将该业务请求的某种唯一标识信息(例如“业务请求单号”、“业务请求单号+业务类型”、“业务请求单号+业务请求来源”等)插入这张表，如果插入成功，说明业务系统是第一次处理该业务请求，则继续正常的业务处理流程；反之如果插入失败，则说明幂等表中已经存在该业务的信息，即业务系统之前曾经处理过该业务请求，那么可以直接确定该请求为重复请求，进而停止处理该请求。
在一般情况下，上述方案可以较好地实现业务系统对外接口的幂等性。然而基于分布式存储或灾备等需求，对数据进行分表或分库存储的方案应用越来越普遍，而在分表或分库的应用场景下，可能会出现的一种情况是：针对同一业务，请求方向业务系统发起了多次请求，而出于某种原因(例如灾备切换等)，多次请求被业务系统路由到了不同的数据表，由于不同数据表所使用的幂等表不同，因此很可能出现幂等失效，进而导致业务重复处理。
发明内容
针对上述技术问题，本申请提供一种业务处理方法、装置及系统，以解决在分库或 多库应用场景下的幂等失效问题，技术方案如下：
根据本申请的第一方面，提供一种业务处理方法，该方法包括：
业务请求侧生成携带业务处理参考信息的业务处理请求，将所述业务处理请求发送至业务处理侧；所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息；
业务处理侧接收到所述业务处理请求后，根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理。
根据本申请的第二方面，提供一种业务处理方法，应用于业务请求侧，该方法包括：
生成携带业务处理参考信息的业务处理请求；
将所述业务处理请求发送至业务处理侧，以使得业务处理侧接收到所述业务处理请求后，根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理；
其中，所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息。
根据本申请的第三方面，提供一种业务处理方法，应用于业务处理侧，该方法包括：
接收业务请求侧发送的业务处理请求，所述业务处理请求中携带业务处理参考信息；
根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理；
其中，所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，业务请求侧针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息。
根据本申请的第四方面，提供一种业务处理装置，应用于业务请求侧，该装置包括：
请求生成模块，用于生成携带业务处理参考信息的业务处理请求；
请求发送模块，用于将所述业务处理请求发送至业务处理侧，以使得业务处理侧接收到所述业务处理请求后，根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理；
其中，所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中 的存储位置，针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息。
根据本申请的第五方面，提供一种业务处理装置，应用于业务处理侧，该装置包括：
请求接收模块，用于接收业务请求侧发送的业务处理请求，所述业务处理请求中携带业务处理参考信息；
业务处理模块，用于根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理；
其中，所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，业务请求侧针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息。
根据本申请的第六方面，提供一种业务处理系统，该系统包括业务请求侧装置及业务处理侧装置：
所述业务请求侧装置包括：
请求生成模块，用于生成携带业务处理参考信息的业务处理请求；
请求发送模块，用于将所述业务处理请求发送至业务处理侧；
其中，所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息；
所述业务处理侧装置包括：
请求接收模块，用于接收业务请求侧发送的业务处理请求；
业务处理模块，用于根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理。
本申请所提供的技术方案，在业务请求侧向业务处理侧发送的业务处理请求中添加了业务处理参考信息，由于针对同一业务事件多次发送的业务处理请求中所携带的业务处理参考信息都是相同的，因此不会出现针对同一业务事件的多次幂等检查在不同存储位置进行的情况，从而有效地避免了业务重复处理的问题。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据这些附图获得其他的附图。
图1是本申请的业务处理方法的流程示意图；
图2是本申请的数据库部署方案示意图；
图3是本申请的业务请求侧装置的结构示意图；
图4是本申请的业务处理侧装置的结构示意图；
图5是本申请的业务处理系统的结构示意图。
具体实施方式
在海量数据的应用场景下，为了实现数据的分布式存储，一般会对采用分表的方式对数据进行存储，分表可以基于多种维度实现，其中一种常用的划分维度是基于“时间”维度进行分表，例如按照1年12个月划分出12个分表，分别用于存储在不同时间发起的业务请求所对应的业务数据。
此外，为了保证系统的容灾特性，对数据库进行冗余备份也是一种常见的处理方案，即将主库中的数据完全复制到FO(Failover，故障切换)库中，主库和FO库一般被部署在不同的区域，正常状态下，业务请求被路由到主库(正常模式)，灾备状态下业务请求将被切换路由至FO库(故障切换模式)。
分库和分表都是数据库应用的常见方案，然而在分库和分表的应用场景下，可能会导致现有的幂等性实现方案失效，场景举例如下：
假设用户A希望向用户B转账100元，业务处理侧的转账平台在11月30日23时59分接收到A通过某应用平台发送的转账请求，将该业务路由到分表11(对11月对应分表的统称)，分表11的幂等表中可以成功插入该业务的标识信息，因此正常处理该业务：将100元从账户A转到账户B。但是由于网络问题，业务请求侧的应用平台并没有收到业务已成功处理的响应，于是判定为处理超时并重新向转账平台发送第二次转账请求。转账平台收到第二次转账请求的时间为12月1日00时01分，将该业务路由到分表12(对12月对应分表的统称)，而分表12的幂等表中并不存在该转账业务的标识信息，因此同样可以成功插入并且正常处理业务，导致A再一次向B转账100元。
假设用户A希望向用户B转账100元，业务处理侧的转账平台第一次接收到A通过 某应用平台发送的转账请求时，系统处于正常运行状态，因此将该业务路由到主库中的数据表，主库的幂等表中可以成功插入该业务的标识信息，因此正常处理该业务：将100元从账户A转到账户B；由于网络问题，业务请求侧的应用平台并没有收到业务已成功处理的响应，于是判定为处理超时并重新向转账平台发送第二次转账请求。转账平台收到第二次转账请求时，主库出现故障，因此将该业务路由到FO库中的数据表，而FO库的幂等表中并不存在该转账业务的标识信息，因此同样可以成功插入并且正常处理业务，导致A再一次向B转账100元。
可见，在数据分库或多库存储的应用场景下，由于不同的存储位置(例如主库/FO库、分库、分表等等)分别维护各自的幂等表，因此当同一业务事件的多次请求被路由到不同的存储位置时，就会导致幂等检查失效的问题。
针对上述问题，本申请提供一种业务处理方法，参见图1所示，该方法可以包括以下步骤：
S101，业务请求侧生成携带业务处理参考信息的业务处理请求。
与现有技术方案相比，本申请方案在业务处理请求中添加扩展参数：业务处理参考信息，该信息的一个作用是在分库或分表的应用场景下，令业务处理侧能够根据该信息确定出处理当前业务所使用的数据库存储位置，即在处理当前业务的过程中，相关的数据处理操作需要在哪个数据库(包括主库/FO、分库等)和/或哪张数据表中进行，以便业务处理侧在所确定的存储位置中进行后续的数据处理操作。
本申请方案并不要求业务请求了解业务处理侧的实际分库或分表逻辑，只需业务请求侧所提供的业务处理参考信息能够被业务处理侧识别、并且根据该信息确定处理当前业务应该使用的具体数据库或数据表即可。
例如：对于数据库按“时间”维度进行分表的情况，业务请求侧只需在发送业务处理请求前，获取当前的时刻信息，并且将该时刻信息写入业务处理请求中。进而业务处理侧可以根据该时刻信息，选择对应的时间维度数据分表来进行后续处理。
对于数据库冗余备份的应用场景，业务请求侧需要在发送业务处理请求前，感知业务处理侧当前所使用的数据库运行模式信息，这里所说的运行模式包括正常运行模式和故障切换模式，然后将该数据库运行模式信息写入业务处理请求中。进而业务处理侧可以根据该数据库运行模式信息，选择主库或FO库来进行后续的处理。实际应用时，业务请求侧可以以订阅的方式获取业务请求侧或中间件主动推送的数据库运行模式信息，也可以在需要发送业务处理请求时按需获取数据库运行模式信息，本申请并不需要进行 限定。
需要说明的是，上述两种“业务处理参考信息”仅用于示意性说明，不应理解为对本申请方案的限定，例如，在业务请求侧了解业务处理侧的分库分表逻辑的情况下，也可以直接将处理当前业务所使用的数据库或数据表的标识添加到业务请求中。另外可以理解的是，根据实际的应用需求，在一条业务处理请求中，允许同时携带多种类型的业务处理参考信息，例如同时携带上述的时刻信息及数据库运行模式信息，以便同时满足按时间维度分表及故障切换的场景应用需求。
S102，业务请求侧将业务处理请求发送至业务处理侧。
本申请方案中，业务处理参考信息的另一个作用是在分库分表的应用场景下，保证业务处理侧接口的幂等性。具体而言，要求业务请求侧针对同一业务事件多次发送的业务处理请求中所携带的业务处理参考信息应该是相同的，这样就能够令业务处理侧在处理基于同一业务事件的多次请求时，都针对相同的存储位置进行幂等检查，从而避免幂等检查失效的问题发生。
实际应用时，业务请求侧可以在首次发送业务处理请求时，获取业务处理参考信息(例如当前时刻信息、当前数据库运行模式信息等)，将该信息写入业务处理请求中，并且对首次写入的业务处理参考信息以业务事件为标识进行存储。后续如果需要再次发送针对同一业务事件的处理请求，则直接读取之前存储的业务处理参考信息并将其写入新的业务处理请求中。当然，本申请方案只需保证针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息即可，因此上述方式并不应理解为对本申请方案的限定，例如，业务请求侧也可以直接对首次生成的业务处理请求消息体的全部或一部分(其中至少应包含首次使用的业务处理参考信息)进行保存，后续有重发需求时，通过读取预先保存的内容就可以实现重发，并且保证多次请求中携带的业务处理参考信息相同。
S103，业务处理侧接收到业务处理请求后，根据请求中携带的业务处理参考信息确定对应的存储位置。
本申请方案中，业务处理侧需要根据业务请求侧提供的业务处理参考信息来确定：处理当前业务时，相关的数据处理操作需要在哪个数据库(包括主库/FO、分库等)和/或哪张数据表中进行。
例如：如果在业务处理请求中携带了时刻信息，则业务处理侧可以根据该时刻信息确定对应的时间维度数据分表；如果在业务处理请求中携带了数据库运行模式信息，则 业务处理侧根据该信息判断是使用主库还是FO库。
应该理解的是，在实际应用中，上述业务处理参考信息可能仅是用于确定存储位置的一部分信息，例如：在基于“用户编号”和“时间”的二维分表方案中，需要结合“发起当前请求的用户编号(该信息属于业务请求中默认携带的信息)”以及“时刻信息”来确定具体的数据分表；在确定主库或FO库后，还需要根据分表方案来进一步确定数据分表，等等。当然，“其他信息”都属于根据现有技术方案可以正常获取的信息，利用其他信息确定存储位置也可以采用与现有技术一致的方案，这些并不影响本申请方案的实现。
S104，针对所确定的存储位置进行幂等检查，并根据幂等检查结果对当前业务进行处理。
在确定业务相关数据在数据库中存储位置的前提下，本申请方案中的幂等检查可以采用与现有技术相同的方案，即：每次处理业务请求之前，将该业务请求的某种唯一标识信息(例如“业务请求单号”、“业务请求单号+业务类型”、“业务请求单号+业务请求来源”等)插入当前存储位置对应的幂等表，如果插入成功，说明业务系统是第一次处理该业务请求，则继续正常的业务处理流程；反之如果插入失败，则说明幂等表中已经存在该业务的信息，即业务系统之前曾经处理过该业务请求，那么可以直接确定该请求为重复请求，进而停止处理该请求。当然，本申请并不需要对具体的幂等检查方案进行限定。
下面结合将结合具体的应用场景，对本申请的方案进行说明：
假设在一个金融系统中，转账平台侧使用的业务数据库部署情况如图2所示，其中数据分表基于两个维度：
在“用户编号”维度：取用户编号的其中2位，形成00-99共100个用户分位。
在“时间”维度：按照1年12个月形成12个分位。
结合上述两种维度，总共形成12*100共1200张分表，每张分表的命名规则为“用户编号分位_月份分位”，且每张分表各自对应一张幂等表。
此外，为了实现系统容灾，将主库中的数据全量备份到FO库中，FO库与主库的分表结构相同。正常状态下，业务请求被路由到主库(正常模式)，灾备状态下业务请求将被切换路由至FO库(故障切换模式)。
假设用户A(用户编号为100002)希望向用户B转账100元，通过应用平台向转账平台发起转账请求。应用平台首次发起转账请求的时间为2015年11月30日23时59分， 并且此时数据库运行于正常模式，则应用平台将“2015-11-30 23:59”以及“正常模式”写入转账请求中。
转账平台接收到上述转账请求后，首先根据请求中携带的信息确定存储位置为主库02_11表，然后执行将该转账业务的流水单号插入主库02_11表的幂等表的操作，由于插入成功，因此正常处理该业务：将100元从账户A转到账户B。
情景1：假设由于网络问题，应用平台并没有收到业务已成功处理的响应，于是判定为处理超时并重新向转账平台发送第二次转账请求。第二次发起转账请求的时间为2015年12月1日00时01分，但是在第二次转账请求中，携带的存储位置信息仍然为“2015-11-30 23:59”以及“正常模式”。
转账平台接收到第二次转账请求后，根据请求中携带的信息确定存储位置为主库02_11表，并进一步执行将该转账业务的流水单号插入主库02_11表的幂等表的操作，由于幂等表中已经存在相同的记录，因此插入失败，进而停止处理本次转账请求，避免了错误的重复转账处理。
情景2：仍然假设由于网络问题，应用平台并没有收到业务已成功处理的响应，于是判定为处理超时并重新向转账平台发送第二次转账请求。第二次发起转账请求的时间为2015年12月1日00时01分，并且此时转账系统侧的数据库已经切换至故障切换模式。但是在第二次转账请求中，携带的信息仍然为“2015-11-30 23:59”以及“正常模式”。
转账平台接收到第二次转账请求后，根据请求中携带的信息确定存储位置为主库02_11表，并进一步执行将该转账业务的流水单号插入主库02_11表的幂等表的操作，但是此时主库故障无法访问，因此本次业务请求无法处理，结果是同样避免了错误的重复转账处理。
可以理解的是，上述金融系统的应用实例仅用于示意性说明，并不构成对本申请方案应用场景的限制。事实上，对于系统数据库涉及数据分库或多库存储、且不同的存储位置(例如主库/FO库、分库、分表等等)分别维护各自幂等表的应用场景，都可以应用本申请方案保证系统接口的幂等性。根据本申请方案，由于业务请求侧针对同一业务事件多次发送的业务处理请求中所携带的业务处理参考信息都是相同的，因此本申请方案不会出现针对同一业务事件的多次幂等检查在不同存储位置进行的情况，从而有效地避免业务重复处理的问题。
相应于上述方法实施例，本申请还提供一种应用于业务请求侧的业务处理装置，参见图3所示，该装置可以包括：
请求生成模块110，用于生成携带业务处理参考信息的业务处理请求；
请求发送模块120，用于将业务处理请求发送至业务处理侧，以使得业务处理侧接收到业务处理请求后，根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理；
其中，业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息。
在本申请的一种具体实施方式中，业务处理参考信息可以为时刻信息；
请求生成模块110可以具体用于：针对同一业务事件，如果首次发送业务处理请求，则获取当前的时刻信息，将该时刻信息写入业务处理请求中，后续针对该业务事件重发的请求中均携带该时刻信息。
在本申请的另一种具体实施方式中，业务处理参考信息可以为数据库运行模式信息，数据库模式可以包括：正常模式、故障切换模式；
请求生成模块110可以具体用于：针对同一业务事件，如果首次发送业务处理请求，则获取业务处理侧当前所使用的数据库运行模式信息，将该数据库运行模式信息写入业务处理请求中，后续针对该业务事件重发的请求中均携带该数据库运行模式信息。
参见图4所示，本申请还提供一种应用于业务处理侧的业务处理装置，该装置可以包括：
请求接收模块210，用于接收业务请求侧发送的业务处理请求，业务处理请求中携带业务处理参考信息；
业务处理模块220，用于根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理；
其中，业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，业务请求侧针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息。
在本申请的一种具体实施方式中，业务处理参考信息可以为时刻信息；
业务处理模块220可以具体用于：根据请求中携带的时刻信息，确定与该时刻信息对应的时间维度数据分表，针对所确定的数据分表进行幂等检查，根据幂等检查结果对当前业务进行处理。
在本申请的另一种具体实施方式中，业务处理参考信息可以为数据库运行模式信息，数据库模式可以包括：正常模式、故障切换模式；
业务处理模块220可以具体用于：根据请求中携带的数据库运行模式信息，确定与该数据库运行模式信息对应的数据库，针对所确定的数据库进行幂等检查，根据幂等检查结果对当前业务进行处理。
本申请还提供一种业务处理系统，如图5所示，该系统可以包括业务请求侧装置100及业务处理侧装置200，两侧装置的具体实施方式可参见前面的实施例，本申请中不再重复说明。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的装置或系统实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，在实施本申请方案时可以把各模块的功能在同一个或多个软件和/或硬件中实现。也可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上所述仅是本申请的具体实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (16)

  1. 一种业务处理方法，其特征在于，该方法包括：
    业务请求侧生成携带业务处理参考信息的业务处理请求，将所述业务处理请求发送至业务处理侧；所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息；
    业务处理侧接收到所述业务处理请求后，根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理。
  2. 根据权利要求1所述的方法，其特征在于，所述业务处理参考信息为时刻信息；
    所述生成携带业务处理参考信息的业务处理请求，包括：针对同一业务事件，如果首次发送业务处理请求，则获取当前的时刻信息，将该时刻信息写入业务处理请求中，后续针对该业务事件重发的请求中均携带该时刻信息；
    所述根据请求中携带的业务处理参考信息确定对应的存储位置，包括：根据请求中携带的时刻信息，确定与该时刻信息对应的时间维度数据分表。
  3. 根据权利要求1所述的方法，其特征在于，所述业务处理参考信息为数据库运行模式信息，所述数据库模式包括：正常模式、故障切换模式；
    所述生成携带业务处理参考信息的业务处理请求，包括：针对同一业务事件，如果首次发送业务处理请求，则获取业务处理侧当前所使用的数据库运行模式信息，将该数据库运行模式信息写入业务处理请求中，后续针对该业务事件重发的请求中均携带该数据库运行模式信息；
    所述根据请求中携带的业务处理参考信息确定对应的存储位置，包括：根据请求中携带的数据库运行模式信息，确定与该数据库运行模式信息对应的数据库。
  4. 一种业务处理方法，应用于业务请求侧，其特征在于，该方法包括：
    生成携带业务处理参考信息的业务处理请求；
    将所述业务处理请求发送至业务处理侧，以使得业务处理侧接收到所述业务处理请求后，根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理；
    其中，所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信 息。
  5. 根据权利要求4所述的方法，其特征在于，所述业务处理参考信息为时刻信息；
    所述生成携带业务处理参考信息的业务处理请求，包括：针对同一业务事件，如果首次发送业务处理请求，则获取当前的时刻信息，将该时刻信息写入业务处理请求中，后续针对该业务事件重发的请求中均携带该时刻信息。
  6. 根据权利要求4所述的方法，其特征在于，所述业务处理参考信息为数据库运行模式信息，所述数据库模式包括：正常模式、故障切换模式；
    所述生成携带业务处理参考信息的业务处理请求，包括：针对同一业务事件，如果首次发送业务处理请求，则获取业务处理侧当前所使用的数据库运行模式信息，将该数据库运行模式信息写入业务处理请求中，后续针对该业务事件重发的请求中均携带该数据库运行模式信息。
  7. 一种业务处理方法，应用于业务处理侧，其特征在于，该方法包括：
    接收业务请求侧发送的业务处理请求，所述业务处理请求中携带业务处理参考信息；
    根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理；
    其中，所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，业务请求侧针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息。
  8. 根据权利要求7所述的方法，其特征在于，所述业务处理参考信息为时刻信息；
    所述根据请求中携带的业务处理参考信息确定对应的存储位置，包括：根据请求中携带的时刻信息，确定与该时刻信息对应的时间维度数据分表。
  9. 根据权利要求7所述的方法，其特征在于，所述业务处理参考信息为数据库运行模式信息，所述数据库模式包括：正常模式、故障切换模式；
    所述根据请求中携带的业务处理参考信息确定对应的存储位置，包括：根据请求中携带的数据库运行模式信息，确定与该数据库运行模式信息对应的数据库。
  10. 一种业务处理装置，应用于业务请求侧，其特征在于，该装置包括：
    请求生成模块，用于生成携带业务处理参考信息的业务处理请求；
    请求发送模块，用于将所述业务处理请求发送至业务处理侧，以使得业务处理侧接收到所述业务处理请求后，根据请求中携带的业务处理参考信息确定对应的存储位置， 针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理；
    其中，所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息。
  11. 根据权利要求10所述的装置，其特征在于，所述业务处理参考信息为时刻信息；
    所述请求生成模块，具体用于：针对同一业务事件，如果首次发送业务处理请求，则获取当前的时刻信息，将该时刻信息写入业务处理请求中，后续针对该业务事件重发的请求中均携带该时刻信息。
  12. 根据权利要求10所述的装置，其特征在于，所述业务处理参考信息为数据库运行模式信息，所述数据库模式包括：正常模式、故障切换模式；
    所述请求生成模块，具体用于：针对同一业务事件，如果首次发送业务处理请求，则获取业务处理侧当前所使用的数据库运行模式信息，将该数据库运行模式信息写入业务处理请求中，后续针对该业务事件重发的请求中均携带该数据库运行模式信息。
  13. 一种业务处理装置，应用于业务处理侧，其特征在于，该装置包括：
    请求接收模块，用于接收业务请求侧发送的业务处理请求，所述业务处理请求中携带业务处理参考信息；
    业务处理模块，用于根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理；
    其中，所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，业务请求侧针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息。
  14. 根据权利要求13所述的装置，其特征在于，所述业务处理参考信息为时刻信息；
    所述业务处理模块，具体用于：根据请求中携带的时刻信息，确定与该时刻信息对应的时间维度数据分表，针对所确定的数据分表进行幂等检查，根据幂等检查结果对当前业务进行处理。
  15. 根据权利要求13所述的装置，其特征在于，所述业务处理参考信息为数据库运行模式信息，所述数据库模式包括：正常模式、故障切换模式；
    所述业务处理模块，具体用于：根据请求中携带的数据库运行模式信息，确定与该 数据库运行模式信息对应的数据库，针对所确定的数据库进行幂等检查，根据幂等检查结果对当前业务进行处理。
  16. 一种业务处理系统，其特征在于，该系统包括业务请求侧装置及业务处理侧装置：
    所述业务请求侧装置包括：
    请求生成模块，用于生成携带业务处理参考信息的业务处理请求；
    请求发送模块，用于将所述业务处理请求发送至业务处理侧；
    其中，所述业务处理参考信息用于业务处理侧确定当前业务的相关数据在数据库中的存储位置，针对同一业务事件多次发送的业务处理请求中携带相同的业务处理参考信息；
    所述业务处理侧装置包括：
    请求接收模块，用于接收业务请求侧发送的业务处理请求；
    业务处理模块，用于根据请求中携带的业务处理参考信息确定对应的存储位置，针对所确定的存储位置进行幂等检查，根据幂等检查结果对当前业务进行处理。
PCT/CN2017/076397 2016-03-24 2017-03-13 一种业务处理方法、装置及系统 WO2017162056A1 (zh)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP17769333.0A EP3435604B1 (en) 2016-03-24 2017-03-13 Service processing method, device, and system
JP2018550376A JP6921107B2 (ja) 2016-03-24 2017-03-13 サービス処理方法、デバイス、及びシステム
US16/137,306 US11445030B2 (en) 2016-03-24 2018-09-20 Service processing method, device, and system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201610173747.6 2016-03-24
CN201610173747.6A CN107229455B (zh) 2016-03-24 2016-03-24 一种业务处理方法、装置及系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US16/137,306 Continuation US11445030B2 (en) 2016-03-24 2018-09-20 Service processing method, device, and system

Publications (1)

Publication Number Publication Date
WO2017162056A1 true WO2017162056A1 (zh) 2017-09-28

Family

ID=59899301

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2017/076397 WO2017162056A1 (zh) 2016-03-24 2017-03-13 一种业务处理方法、装置及系统

Country Status (6)

Country Link
US (1) US11445030B2 (zh)
EP (1) EP3435604B1 (zh)
JP (1) JP6921107B2 (zh)
CN (1) CN107229455B (zh)
TW (1) TWI777935B (zh)
WO (1) WO2017162056A1 (zh)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10693952B2 (en) 2017-10-23 2020-06-23 Salesforce.Com, Inc. Technologies for low latency messaging
CN108415792B (zh) * 2018-01-15 2022-04-29 创新先进技术有限公司 容灾系统、方法、装置及设备
CN108647950B (zh) * 2018-05-18 2022-01-28 创新先进技术有限公司 一种转账请求处理方法、装置及设备
CN108647105B (zh) * 2018-05-22 2022-02-01 创新先进技术有限公司 系统切换过程中的幂等控制方法、装置及系统
CN108805569A (zh) * 2018-05-29 2018-11-13 阿里巴巴集团控股有限公司 基于区块链的交易处理方法及装置、电子设备
US11252119B2 (en) * 2018-06-04 2022-02-15 Salesforce.Com, Inc. Message logging using two-stage message logging mechanisms
CN108984325A (zh) * 2018-07-20 2018-12-11 北京北信源信息安全技术有限公司 消息队列消费方法和装置
CN110046877B (zh) * 2018-11-30 2023-09-29 创新先进技术有限公司 对账方法和装置、服务器
CN110046976B (zh) * 2018-11-30 2023-08-18 创新先进技术有限公司 对账方法和装置、服务器
CN110020846B (zh) * 2019-03-18 2023-01-20 创新先进技术有限公司 一种转账业务处理方法及系统
CN110445846A (zh) * 2019-07-18 2019-11-12 福建星网智慧软件有限公司 一种智能充电桩与管理平台判断重复通信的方法及系统
US11665110B1 (en) * 2019-09-30 2023-05-30 Amazon Technologies, Inc. Using distributed services to continue or fail requests based on determining allotted time and processing time
CN111737351A (zh) * 2020-06-22 2020-10-02 中国银行股份有限公司 分布式管理系统事务管理方法及装置
CN112232770B (zh) * 2020-10-17 2021-08-20 成都数字家园科技有限公司 基于智慧社区和云服务的业务信息处理方法及云服务设备
CN112905492B (zh) * 2021-04-06 2024-05-24 浙江网商银行股份有限公司 验证方法及装置
CN113553214B (zh) * 2021-07-30 2024-04-02 国网数字科技控股有限公司 一种幂等性校验方法及装置
CN114676118B (zh) * 2022-05-30 2022-08-12 深圳市科力锐科技有限公司 数据库切换方法、装置、设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102035865A (zh) * 2009-09-30 2011-04-27 阿里巴巴集团控股有限公司 数据存储及数据寻址方法、系统和设备
CN103716253A (zh) * 2013-12-27 2014-04-09 广州华多网络科技有限公司 一种请求数据的方法及装置
US8751598B1 (en) * 2010-11-03 2014-06-10 Netapp, Inc. Method and system for implementing an unordered delivery of data between nodes in a clustered storage system
CN103853764A (zh) * 2012-12-03 2014-06-11 金蝶软件（中国）有限公司 终端信息同步方法及装置
CN104253702A (zh) * 2013-06-27 2014-12-31 华为软件技术有限公司 一种终端管理方法和系统

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020133601A1 (en) * 2001-03-16 2002-09-19 Kennamer Walter J. Failover of servers over which data is partitioned
US8914429B2 (en) * 2002-02-08 2014-12-16 Willaim Pitts Method for creating global distributed namespace
US7296008B2 (en) * 2004-08-24 2007-11-13 Symantec Operating Corporation Generation and use of a time map for accessing a prior image of a storage device
US7328324B2 (en) * 2005-04-27 2008-02-05 Dot Hill Systems Corp. Multiple mode controller method and apparatus
US7877757B2 (en) * 2006-05-05 2011-01-25 Microsoft Corporation Work item event monitor for procession of queued events
US8275855B2 (en) * 2007-12-20 2012-09-25 Yahoo! Inc. Method and system for monitoring rest web services
US9417977B2 (en) * 2008-12-31 2016-08-16 Sap Se Distributed transactional recovery system and method
US8655848B1 (en) * 2009-04-30 2014-02-18 Netapp, Inc. Unordered idempotent logical replication operations
US8612386B2 (en) * 2011-02-11 2013-12-17 Alcatel Lucent Method and apparatus for peer-to-peer database synchronization in dynamic networks
US8788579B2 (en) * 2011-09-09 2014-07-22 Microsoft Corporation Clustered client failover
US8924346B2 (en) * 2011-09-09 2014-12-30 Oracle International Corporation Idempotence for database transactions
US8856583B1 (en) * 2012-01-20 2014-10-07 Google Inc. Failover operation on a replicated distributed database system while maintaining access invariance
US9477706B2 (en) * 2012-04-04 2016-10-25 Viavi Solutions Inc. System and method for storing and retrieving data
US9304888B2 (en) * 2013-06-25 2016-04-05 Microsoft Technology Licensing, Llc Consistent modeling and execution of time constructs in business processes
US9471585B1 (en) * 2013-12-20 2016-10-18 Amazon Technologies, Inc. Decentralized de-duplication techniques for largescale data streams
US11379494B2 (en) * 2014-08-06 2022-07-05 Sap Se Timeline index for partitioned temporal database tables
PE20171305A1 (es) 2014-12-20 2017-09-05 Troikaa Pharmaceuticals Ltd Formulaciones inyectables de paracetamol
CN107924362B (zh) * 2015-09-08 2022-02-15 株式会社东芝 数据库系统、服务器装置、计算机可读取的记录介质及信息处理方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102035865A (zh) * 2009-09-30 2011-04-27 阿里巴巴集团控股有限公司 数据存储及数据寻址方法、系统和设备
US8751598B1 (en) * 2010-11-03 2014-06-10 Netapp, Inc. Method and system for implementing an unordered delivery of data between nodes in a clustered storage system
CN103853764A (zh) * 2012-12-03 2014-06-11 金蝶软件（中国）有限公司 终端信息同步方法及装置
CN104253702A (zh) * 2013-06-27 2014-12-31 华为软件技术有限公司 一种终端管理方法和系统
CN103716253A (zh) * 2013-12-27 2014-04-09 广州华多网络科技有限公司 一种请求数据的方法及装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3435604A4 *

Also Published As

Publication number Publication date
TW201734857A (zh) 2017-10-01
CN107229455A (zh) 2017-10-03
US11445030B2 (en) 2022-09-13
CN107229455B (zh) 2019-09-17
EP3435604A4 (en) 2019-10-30
JP6921107B2 (ja) 2021-08-18
JP2019516171A (ja) 2019-06-13
EP3435604B1 (en) 2022-03-02
TWI777935B (zh) 2022-09-21
EP3435604A1 (en) 2019-01-30
US20190028555A1 (en) 2019-01-24

Similar Documents

Publication Publication Date Title
WO2017162056A1 (zh) 一种业务处理方法、装置及系统
US10255343B2 (en) Initialization protocol for a peer-to-peer replication environment
US9462039B2 (en) Transparent failover
US7206836B2 (en) System and method for reforming a distributed data system cluster after temporary node failures or restarts
US7340490B2 (en) Storage network data replicator
US8214612B1 (en) Ensuring consistency of replicated volumes
US9311328B2 (en) Reference volume for initial synchronization of a replicated volume group
WO2017219857A1 (zh) 一种数据处理方法和设备
US20110099148A1 (en) Verification Of Remote Copies Of Data
US7203687B2 (en) Peer-to-peer replication member initialization and deactivation
WO2004051476A2 (en) Improved remote copy synchronization in disaster recovery computer systems
JP2007518195A (ja) リモートデータミラーリングを用いたクラスタデータベース
US20230098190A1 (en) Data processing method, apparatus, device and medium based on distributed storage
CN106815094B (zh) 一种用于实现主备同步模式下事务提交的方法与设备
US8676751B2 (en) High availability database systems and methods
WO2021115043A1 (zh) 分布式数据库系统和数据灾备演练方法
US20090144333A1 (en) System for maintaining a database
WO2015196692A1 (zh) 一种云计算系统以及云计算系统的处理方法和装置
CN111163120A (zh) 分布式数据库的数据存储传输方法和装置以及存储介质
US9582384B2 (en) Method and system for data replication
CN104391926A (zh) 一种同步数据复制方法及装置
US7627873B1 (en) System and method for handling device objects in a data storage environment for maintaining consistency during data replication
CN117555493B (zh) 数据处理方法、系统、装置、存储介质及电子设备
KR20190069201A (ko) 데이터 베이스 관리 방법
CN114090545A (zh) 分布式数据库的维护方法、装置、存储介质及程序产品

Legal Events

Date Code Title Description
ENP Entry into the national phase

Ref document number: 2018550376

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2017769333

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2017769333

Country of ref document: EP

Effective date: 20181024

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

Ref document number: 17769333

Country of ref document: EP

Kind code of ref document: A1