Business request idempotence control system, method, device and storage medium

Abstract

The embodiment of the present invention discloses a service request idempotency control system, method, device and storage medium, wherein the system includes an idempotency configuration module and a request interception module, wherein: the idempotency configuration module is used to configure the scenario control parameters of the idempotency control access service scenario associated with the parameter configuration instruction in response to the detected parameter configuration instruction; the request interception module is used to receive a service request and lock the service request based on the scenario control parameters associated with the service request. The system provided by the embodiment of the present invention flexibly configures the scenario control parameters under different idempotency control access service scenarios through the idempotency configuration module, and the request interception module performs idempotency control according to the configured scenario control parameters, thereby realizing flexible access to multiple idempotency control scenarios and unified management of different idempotency control scenarios.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of computer technology, and in particular to a service request idempotence control system, method, device, and storage medium. Background Art

[0002] In the field of e-commerce technology, the characteristic of idempotent operations is that the results of any multiple requests with the same parameters are the same. Typical scenarios include: when an e-commerce system places an order, the inventory system should ensure that the inventory can only be fastened successfully once, and after the order is placed, the points system should ensure that the points can only be accumulated successfully once. At present, typical technical solutions for idempotency control include token-based mechanism, optimistic lock-based, distributed lock-based, etc. In the process of realizing the present invention, the inventors found that there are at least the following technical problems in the prior art: when there are a large number of scenarios that require idempotency control in the same system, the idempotency design is cumbersome and the workload is large. Summary of the invention

[0003] The embodiments of the present invention provide a service request idempotency control system, method, device and storage medium to achieve flexible access to multiple idempotency control scenarios, unified management of different idempotency control scenarios, and simplify the design complexity of idempotency control.

[0004] In a first aspect, an embodiment of the present invention provides a service request idempotency control system for multiple service scenarios, including an idempotency configuration module and a request interception module, wherein:

[0005] An idempotence configuration module, configured to, in response to a detected parameter configuration instruction, configure a scenario control parameter of an idempotence control access business scenario associated with the parameter configuration instruction;

[0006] The request interception module is used to receive a business request and perform locking control on the business request based on the scenario control parameters associated with the business request.

[0007] Optionally, further, the scene control parameter includes a scene identifier and at least one idempotent service parameter.

[0008] Optionally, further, the request interception module is specifically used to:

[0009] Receive a business request, and parse the business request to obtain a scenario identifier associated with the business request;

[0010] Determine idempotent service parameters associated with the service request based on the scenario identifier;

[0011] A distributed lock cache key value of the business request is generated according to the scenario identifier and idempotent business parameters, and the business request is locked based on the distributed lock cache key value.

[0012] Optionally, further, the scenario identifier includes an identifier of a subsystem to which the idempotence control access business scenario belongs and an access interface of a subsystem to which the idempotence control access business scenario belongs, and a distributed lock cache key value of a business request is generated according to the scenario identifier and the idempotence business parameter, including:

[0013] Get the business parameter request value of the idempotent business parameter;

[0014] The subsystem identifier, access interface and business parameter request value are concatenated to obtain the distributed lock cache key value.

[0015] Optionally, further, lock control is performed on the business request based on the distributed lock cache key value, including:

[0016] Store the distributed lock cache key value in the cache;

[0017] If the cache is successful, a cache success signal is generated as the response information of the business request, so that the subsystem to which the idempotent control access business scenario belongs performs the operation associated with the business request according to the response information;

[0018] If the cache fails, the business request is intercepted.

[0019] In a second aspect, an embodiment of the present invention further provides a method for controlling idempotency of service requests in multiple service scenarios, which is applied to a service request idempotency control system for multiple service scenarios provided by any embodiment of the present invention, including:

[0020] In response to the detected service request, obtaining a scenario control parameter associated with the service request, wherein the scenario control parameter is configured through an idempotence configuration module;

[0021] Generate distributed lock cache key values ​​for business requests based on scenario control parameters;

[0022] Lock control of business requests based on distributed lock cache key values.

[0023] Optionally, further, in response to the detected service request, acquiring a scene control parameter associated with the service request includes:

[0024] Parse the business request to obtain a scenario identifier associated with the business request;

[0025] Determine idempotent service parameters associated with the service request based on the scenario identifier.

[0026] Optionally, further comprising:

[0027] In response to the detected idempotence control configuration request, obtaining a scenario identifier associated with the idempotence control configuration request and at least one idempotence business parameter;

[0028] The scenario identifier and at least one idempotent business parameter are stored in the database accordingly.

[0029] In a third aspect, an embodiment of the present invention further provides a service request idempotence control device for multiple service scenarios, including:

[0030] The control parameter acquisition module is used to obtain the scene control parameters associated with the service request in response to the detected service request:

[0031] A cache key value generation module is used to generate a distributed lock cache key value for a business request based on scenario control parameters;

[0032] The lock control module is used to perform lock control on business requests based on the distributed lock cache key value.

[0033] In a fourth aspect, an embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a method for controlling the idempotence of business requests in multiple business scenarios as provided in any embodiment of the present invention.

[0034] The service request idempotence control system for multiple service scenarios provided by an embodiment of the present invention includes an idempotence configuration module and a request interception module, wherein: the idempotence configuration module is used to respond to a detected parameter configuration instruction and configure the scenario control parameters of the idempotence control access service scenario associated with the parameter configuration instruction; the request interception module is used to receive a service request and lock the service request based on the scenario control parameters associated with the service request, and flexibly configure the scenario control parameters in different idempotence control access service scenarios through the idempotence configuration module, and the request interception module performs idempotence control according to the configured scenario control parameters, thereby realizing flexible access to multiple idempotence control scenarios and unified management of different idempotence control scenarios, and simplifying the design complexity of idempotence control. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 This is a schematic diagram of the structure of a service request idempotence control system for multiple service scenarios provided in the first embodiment of the present invention;

[0036] Figure 2 This is a flow chart of a method for controlling idempotency of business requests in multiple business scenarios provided in Embodiment 2 of the present invention;

[0037] Figure 3a This is a schematic diagram of the structure of a service request idempotence control system for multiple service scenarios provided in Embodiment 3 of the present invention;

[0038] Figure 3b It is a schematic diagram of the processing flow of a unified interceptor provided in Embodiment 3 of the present invention;

[0039] Figure 4 It is a structural diagram of a service request idempotence control device for multiple service scenarios provided by Embodiment 4 of the present invention. DETAILED DESCRIPTION

[0040] The present invention will be further described in detail below in conjunction with the accompanying drawings and embodiments. It is to be understood that the specific embodiments described herein are only used to explain the present invention, rather than to limit the present invention. It should also be noted that, for ease of description, only parts related to the present invention, rather than all structures, are shown in the accompanying drawings.

[0041] Embodiment 1

[0042] Figure 1 1 is a schematic diagram of the structure of a service request idempotence control system for multiple service scenarios provided by the first embodiment of the present invention. This embodiment can be applied to idempotence control in multiple idempotence control scenarios. The service request idempotence control system for multiple service scenarios provided by this embodiment can be expressed in the form of a general-purpose computing device. Figure 1 As shown, the service request idempotency control system for multiple service scenarios includes an idempotency configuration module 10 and a request interception module 20, wherein:

[0043] An idempotence configuration module 10, configured to, in response to a detected parameter configuration instruction, configure a scenario control parameter of an idempotence control access service scenario associated with the parameter configuration instruction;

[0044] The request interception module 20 is used to receive a service request and perform locking control on the service request based on a scenario control parameter associated with the service request.

[0045] In this embodiment, the idempotency configuration module is used to realize the unified configuration and management of idempotency in different idempotency control scenarios, and the request interception module is used to realize the actual control of idempotency. Among them, the idempotency configuration module 10 mainly includes the design and definition of the idempotency configuration data structure, the design of the management function, and the design of the unified configuration information reading interface, which is mainly used to realize the parameter configuration and management of the idempotency control access business scenario associated with the parameter configuration instruction according to the parameter configuration instruction triggered by the detected user; the request interception module 20 is mainly used to intercept all business requests, parse the parameters of the business request, read the scene control parameters related to the business request, generate the distributed lock cache key value based on the scene control parameter, and lock the business logic based on the generated distributed lock cache key value to realize the idempotency control. It can be understood that the idempotency control access business scenario can be a scenario that requires idempotency control. Taking the e-commerce platform as an example, the idempotency control access business scenario can be an inventory deduction scenario, a deduction scenario, a points scenario, etc. Developers can configure the scene control parameters of multiple business scenarios and trigger the corresponding parameter configuration instructions to realize the idempotency control parameter configuration of multiple idempotency control access business scenarios.

[0046] The service request idempotence control system for multiple service scenarios provided by an embodiment of the present invention includes an idempotence configuration module and a request interception module, wherein: the idempotence configuration module is used to respond to a detected parameter configuration instruction and configure the scenario control parameters of the idempotence control access service scenario associated with the parameter configuration instruction; the request interception module is used to receive a service request and lock the service request based on the scenario control parameters associated with the service request, and flexibly configure the scenario control parameters in different idempotence control access service scenarios through the idempotence configuration module, and the request interception module performs idempotence control according to the configured scenario control parameters, thereby realizing flexible access to multiple idempotence control scenarios and unified management of different idempotence control scenarios, and simplifying the design complexity of idempotence control.

[0047] In one embodiment, the scenario control parameters include a scenario identifier and at least one idempotent business parameter. The scenario identifier can be understood as an identifier that uniquely points to the idempotent control access business scenario, and can be a subsystem identifier of the subsystem to which the idempotent control access business scenario belongs, an access interface of the subsystem to which the idempotent control access business scenario belongs, etc. The idempotent business parameter can be understood as a core parameter for idempotent control. The number of idempotent business parameters can be multiple, such as one or a combination of any of the order identifier, user identifier, and channel identifier. When configuring the parameters of the idempotent control access business scenario, the scenario identifier and the idempotent business parameters need to be configured to complete the parameter configuration of the idempotent control access business scenario. In addition to the scenario identifier and the idempotent business parameters that need to be configured, the validity can also be configured, that is, when the validity identifier indicates that it is valid, it means that the current configuration is enabled for idempotent control, and when the validity identifier indicates that it is invalid, the current configuration is not enabled for idempotent control. Configuring the validity flag can realize multiple idempotency control configuration methods for the same idempotency control access business scenario. According to business needs, the validity flag suitable for business needs can be configured as valid, thus realizing flexible idempotency control for the same idempotency control access business scenario.

[0048] In one embodiment of the present invention, the request interception module is specifically used to: receive a business request, parse the business request to obtain a scenario identifier associated with the business request; determine the idempotent business parameters associated with the business request based on the scenario identifier; generate a distributed lock cache key value for the business request based on the scenario identifier and the idempotent business parameters, and lock the business request based on the distributed lock cache key value. Optionally, after the idempotency control configuration is completed, the request interception module intercepts the repeatedly initiated business requests to achieve idempotency control. Specifically, when the request interception module receives the business request, it parses the business request and obtains the scenario identifier associated with the business request to determine the idempotent control access business scenario to which the business request belongs. After obtaining the scenario identifier associated with the business request, the idempotent business parameters associated with the business request are obtained according to the scenario identifier, and then the distributed lock cache key value for the business request is generated according to the scenario identifier and the idempotent business parameters, and the business request is locked based on the generated distributed lock cache key value. Exemplarily, when the request interception module receives business request 1, it parses business request 1 and determines that the scenario identifier associated with business request 1 is an inventory deduction identifier, then obtains the idempotence control parameter corresponding to the inventory deduction identifier as the idempotence control parameter associated with business request 1, generates a distributed lock cache key value for business request 1 through the inventory deduction identifier and the idempotence control parameter, and performs lock control of business request 1 and interception of repeated requests based on the generated distributed lock cache key value.

[0049] Optionally, a distributed lock cache key value for a business request is generated based on a scenario identifier and an idempotent business parameter, including: obtaining a business parameter request value for an idempotent business parameter; concatenating the subsystem identifier, the access interface, and the business parameter request value to obtain a distributed lock cache key value. Optionally, the request value for each idempotent business parameter may be obtained separately, and the scenario identifier and all request values ​​may be concatenated to obtain a distributed lock cache key value. Specifically, the scenario identifier includes the subsystem identifier to which the idempotent control access business scenario belongs and the access interface of the subsystem to which the idempotent control access business scenario belongs. After obtaining the business parameter request for each idempotent business parameter, the subsystem identifier, the interface of the access interface, and the request value for each business parameter are concatenated to obtain a distributed lock cache key value. Optionally, the business parameter request value for the idempotent business parameter may be obtained through HttpServletRequest.getParameter("idempotent business parameter").

[0050] In one embodiment, a business request is locked and controlled based on a distributed lock cache key value, including: storing the distributed lock cache key value in the cache; if the cache is successful, generating a cache success signal as the response information of the business request, so that the subsystem to which the idempotence control access business scenario belongs performs the operation associated with the business request according to the response information; if the cache fails, intercepting the business request. Optionally, the scenario control parameters associated with the same business request are the same, so the distributed lock cache key value of the same business request is also the same. That is, when the distributed lock cache key value of the business request exists in the cache, it indicates that the business request is a repeated business request and the business request needs to be intercepted. When the distributed lock cache key value of the business request does not exist in the cache, it indicates that the business request is initiated for the first time, and a feedback signal of cache success is sent to the subsystem to which the idempotence control access business scenario belongs, so that the subsystem performs the business request-related operations according to the feedback signal of cache success. Still taking the inventory deduction scenario as an example, if the distributed lock cache key value of the inventory deduction request is cached successfully, the cache success information is fed back to the inventory deduction system so that the inventory deduction system executes the inventory deduction operation according to the inventory deduction request. If the distributed lock cache key value of the inventory deduction request fails to be cached, the inventory deduction request is intercepted to avoid repeated deductions of inventory.

[0051] Embodiment 2

[0052] Figure 2 This is a flow chart of a method for controlling idempotency of service requests in multiple service scenarios provided by the second embodiment of the present invention. This embodiment is applicable to situations where idempotency is controlled in multiple scenarios. The method can be executed by a service request idempotency control device for multiple service scenarios. The service request idempotency control device for multiple service scenarios can be implemented in software and / or hardware. For example, the idempotency control can be configured in a service request idempotency control system for multiple service scenarios. Figure 2As shown, the method includes:

[0053] S210: In response to the detected service request, obtain a scene control parameter associated with the service request.

[0054] In this embodiment, the business request may be a business request in different business scenarios, such as an inventory deduction request in an inventory deduction scenario, a deduction request in a deduction scenario, a point accumulation request in a point scenario, etc. After detecting a business request initiated by a user, the business request is parsed to obtain a scenario control parameter associated with the business request, so as to perform idempotence control of the business request according to the scenario control parameter. The scenario control parameter is configured by an idempotence configuration module.

[0055] In one embodiment of the present invention, in response to a detected business request, the scene control parameters associated with the business request are obtained, including: parsing the business request to obtain the scene identifier associated with the business request; determining the idempotent business parameters associated with the business request based on the scene identifier. Optionally, the scene control parameters associated with the business request may include the scene identifier associated with the business request and the idempotent business parameters corresponding to the scene identifier. The scene identifier associated with the business request may be obtained first, and then the idempotent business parameters may be determined based on the scene identifier. Specifically, the scene identifier and the idempotent business parameters may refer to the above embodiments, which will not be repeated here. Exemplarily, the access interface in the scene identifier may be obtained by calling the getServletPath method of HttpServletRequest, and the subsystem identifier in the scene identifier may be obtained according to the getParameter("appId") method of HttpServletRequest.

[0056] It can be understood that the scene control parameters obtained in this embodiment are pre-configured. Optionally, it also includes: in response to the detected idempotence control configuration request, obtaining the scene identifier and at least one idempotence business parameter associated with the idempotence control configuration request; storing the scene identifier and at least one idempotence business parameter in the database. Among them, the configuration of the scene control parameters for the idempotence control access business scenario can be configured according to actual needs. Exemplarily, after the configuration personnel configure the scene control parameters, the idempotence control configuration request is triggered, and the business request idempotence control device for multiple business scenarios obtains the scene identifier and idempotence business parameters associated with the detected idempotence control configuration request, and stores the scene identifier and idempotence business parameters in the database, so that the subsequent idempotence control is performed according to the scene identifier and idempotence business parameters stored in the database.

[0057] S220: Generate a distributed lock cache key value for the business request based on the scenario control parameter.

[0058] Referring to the above embodiment, the scenario control parameters include a scenario identifier (the subsystem identifier to which the idempotence control access business scenario belongs and the access interface of the subsystem to which the idempotence control access business scenario belongs) and idempotence business parameters. The business parameter request value of each idempotence business parameter is obtained respectively, and the subsystem identifier, access interface and business parameter request value are spliced ​​to obtain the distributed lock cache key value.

[0059] S230: Lock the business request based on the distributed lock cache key value.

[0060] Optionally, after generating the distributed lock cache key value, the distributed lock cache key value is stored in the cache, and whether the business request needs to be intercepted is determined based on the storage result. Specifically, if the cache is successful, a cache success signal is generated as the response information of the business request, so that the subsystem to which the idempotent control access business scenario belongs performs the operation associated with the business request based on the response information; if the cache fails, the business request is intercepted.

[0061] The embodiment of the present invention obtains the scenario control parameters associated with the business request in response to the detected business request: generates a distributed lock cache key value of the business request based on the scenario control parameters; and locks the business request based on the distributed lock cache key value, thereby realizing flexible control and management of multiple idempotence control scenarios.

[0062] Embodiment 3

[0063] This embodiment provides a preferred embodiment based on the above embodiment. In this embodiment, the idempotence configuration module is concretized as the same management platform, and the request interception module is concretized as a unified interceptor process.

[0064] Figure 3a Schematic diagram of the structure of a service request idempotence control system for multiple service scenarios provided by the third embodiment of the present invention. Figure 3a As shown, the idempotency control system for business requests in multiple business scenarios includes a unified management platform and a unified interceptor processing module. The unified management platform mainly includes the design and definition of the idempotency configuration data structure, the design of the unified management platform functions, and the design of the unified configuration information reading interface. The function of the unified interceptor is to intercept all requests, parse the request parameters, read the idempotency configuration information, generate a distributed lock cache key (i.e., a distributed lock cache identifier) ​​based on the idempotency configuration information and request parameters, and lock the business logic based on the generated distributed lock cache key.

[0065] Specifically, the unified management platform mainly includes the design and definition of the idempotent configuration data structure, the design of the unified management platform functions, and the design of the unified configuration information reading interface:

[0066] 1) Design and definition of idempotent configuration data structure

[0067] Taking the request for inventory deduction as an example, the idempotency configuration data structure can be http: / / request domain name / inventory / decrise? appName = "appName" & orderId = "orderId", where the core data of the idempotency configuration includes: ①Id: the unique ID of the idempotency configuration information, that is, the identifier of the idempotency control access environment. ②domainName: the request domain name of the system to which the idempotency control access environment belongs. ③interface: the interface of the system to which the idempotency control access environment belongs to access idempotency control. Taking inventory deduction as an example, / inventory / decrise is the interface that needs to access idempotency control. ④interfaceDesc: the name of the interface to access idempotency control. ⑤busiParams: the specific interface to access idempotency control, that is, idempotency business parameters. busiParams needs to be defined to generate the cache key of the distributed cache lock. busiParams should ensure the uniqueness of the business. Multiple definitions can be defined, and multiple definitions are separated by commas. In the example of inventory deduction, busiParams corresponds to orderId. ⑥appId: The system ID for accessing idempotency control, used to distinguish different applications. ⑦appName: The system name for accessing idempotency control. ⑧yn: Validity identifier, used to identify whether the current configuration is effective.

[0068] 2) Design of unified management platform functions

[0069] The unified management platform includes the following functions: adding idempotent configuration, modifying idempotent configuration, taking effect of idempotent configuration, and invalidating idempotent configuration. All these idempotent configuration operations are completed based on the database.

[0070] 3) Design of unified configuration information reading interface

[0071] When the unified interceptor is processing, it is necessary to read the idempotent configuration information. The function of the unified configuration information reading interface is to provide the idempotent configuration information query function. The interface can be defined as:

[0072] Input parameters: appId, interface; Output parameters: idempotent configuration information of the current interface.

[0073] The unified interceptor performs locking control on business requests. Figure 3b Schematic diagram of the processing flow of a unified interceptor provided in Embodiment 3 of the present invention. Figure 3b As shown, the complete process of unified interceptor processing is:

[0074] 1) Resolve the requested uniform resource locator (URL)

[0075] Exemplarily, the getServletPath method of HttpServletRequest may be called to obtain the interface of the service request, and the appId may be obtained according to the getParameter("appId") method of HttpServletRequest.

[0076] 2) Read idempotent configuration

[0077] According to appId and interface, call the unified configuration information reading interface to read the idempotent configuration.

[0078] 3) Generate distributed cache key

[0079] After reading the idempotent configuration, generate a distributed cache key according to the busiParams field information (i.e., idempotent business parameters) of the idempotent configuration information. The cache key generation process can be: separate busiParams with commas to obtain multiple business parameters. Assume that two are configured, namely busiParam1 and busiParam2; call HttpServletRequest.getParameter("busiParam1") and HttpServletRequest.getParameter("busiParam2") to obtain the corresponding request values ​​busiParamValue1 and busiParamValue2 respectively; concatenate the scene identifier and the request value to obtain the distributed cache key, and the rule can be: appId_busiParam1_busiParam2_busiParamVaule1_busiParamValue2; 4) Lock control: According to the cache key (cacheKey), use distributed locks to control the business logic. Lock control can be performed through redis-based distributed locks. The core principle is the redis setnx instruction. The instruction format is setnx(cachekey,0). The meaning of the instruction is: if it does not exist in the cache, the cache is set successfully and true is returned; if it exists in the cache, the cache is set failed and false is returned, so that only one request can be successfully executed. The lock control logic is as follows:

[0080] boolean isExist=setnx(cachekey,0);

[0081] if(isExist){ / / Setting successful

[0082] / / Execute business logic. If the execution fails, delete cacheKey from the cache.

[0083] }eles{ / / Setting failed

[0084] / / Return to the executing status

[0085] }

[0086] The embodiment of the present invention introduces the design of a unified management platform and combines it with distributed locks to control the idempotence of interfaces, supports flexible access to idempotence control of business requests in multiple business scenarios, and achieves the effect of unified management of interface idempotence when there are many subsystems in a distributed system. Any subsystem can be accessed on demand. At the same time, due to the integration of the advantages of distributed locks, it is particularly suitable for interface idempotence control of distributed systems.

[0087] Embodiment 4

[0088] Figure 4 This is a schematic diagram of the structure of a service request idempotence control device for multiple service scenarios provided by the fourth embodiment of the present invention. The service request idempotence control device for multiple service scenarios can be implemented in software and / or hardware. For example, the service request idempotence control device for multiple service scenarios can be configured in a service request idempotence control system for multiple service scenarios. Figure 4 As shown, the device includes a control parameter acquisition module 410, a cache key value generation module 420 and a lock control module 430, wherein:

[0089] A control parameter acquisition module 410, configured to obtain, in response to a detected service request, a scenario control parameter associated with the service request, wherein the scenario control parameter is configured through an idempotence configuration module;

[0090] A cache key value generation module 420, used to generate a distributed lock cache key value of a business request based on a scenario control parameter;

[0091] The lock control module 430 is used to perform lock control on the service request based on the distributed lock cache key value.

[0092] The embodiment of the present invention obtains the scenario control parameters associated with the business request in response to the detected business request through the control parameter acquisition module: the cache key value generation module generates the distributed lock cache key value of the business request based on the scenario control parameter; the lock control module performs lock control on the business request based on the distributed lock cache key value, thereby realizing flexible control and management of multiple idempotence control scenarios.

[0093] Optionally, based on the above solution, the control parameter acquisition module 410 is specifically used to:

[0094] Parse the business request to obtain a scenario identifier associated with the business request;

[0095] Determine idempotent service parameters associated with the service request based on the scenario identifier.

[0096] Optionally, based on the above solution, an idempotence control configuration module is further included, which is used to:

[0097] In response to the detected idempotence control configuration request, obtaining a scenario identifier associated with the idempotence control configuration request and at least one idempotence business parameter;

[0098] The scenario identifier and at least one idempotent business parameter are stored in the database accordingly.

[0099] The service request idempotence control device for multiple service scenarios provided in an embodiment of the present invention can execute the service request idempotence control method for multiple service scenarios provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0100] Embodiment 5

[0101] Embodiment 5 of the present invention provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the method for controlling idempotency of service requests in multiple service scenarios provided in the embodiment of the present invention is implemented. The method includes:

[0102] In response to the detected service request, the scene control parameters associated with the service request are obtained:

[0103] Generate distributed lock cache key values ​​for business requests based on scenario control parameters;

[0104] Lock control of business requests based on distributed lock cache key values.

[0105] Of course, the computer-readable storage medium provided by an embodiment of the present invention stores a computer program which is not limited to the above method operations, but can also execute related operations of the method for controlling idempotence of business requests in multiple business scenarios provided by any embodiment of the present invention.

[0106] The computer storage medium of the embodiment of the present invention can adopt any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples (non-exhaustive list) of computer-readable storage media include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program, which can be used by an instruction execution system, device or device or used in combination with it.

[0107] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, which carry computer-readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0108] Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0109] Computer program code for performing the operations of the present invention may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., through the Internet using an Internet service provider).

[0110] Note that the above are only preferred embodiments of the present invention and the technical principles used. Those skilled in the art will understand that the present invention is not limited to the specific embodiments herein, and that various obvious changes, readjustments and substitutions can be made by those skilled in the art without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of the present invention, and the scope of the present invention is determined by the scope of the appended claims.

Claims

1. A service request idempotence control system for multiple service scenarios, characterized in that: It includes idempotence configuration module and request interception module, where: The idempotence configuration module is used to configure the scenario control parameters of the idempotence control access service scenario associated with the parameter configuration instruction in response to the detected parameter configuration instruction; The request interception module is used to receive a service request and perform locking control on the service request based on a scenario control parameter associated with the service request; Wherein, the request interception module is specifically used for: Receiving a service request, parsing the service request to obtain a scenario identifier associated with the service request; Determine an idempotent service parameter associated with the service request based on the scenario identifier; A distributed lock cache key value of the business request is generated according to the scenario identifier and the idempotent business parameter, and locking control is performed on the business request based on the distributed lock cache key value.

2. The system according to claim 1, characterized in that The scenario control parameters include a scenario identifier and at least one idempotent service parameter.

3. The system according to claim 1, characterized in that The scenario identifier includes a subsystem identifier to which the idempotence control access business scenario belongs and an access interface of the subsystem to which the idempotence control access business scenario belongs, and generating a distributed lock cache key value of the business request according to the scenario identifier and the idempotence business parameter includes: Obtaining a business parameter request value of the idempotent business parameter; The subsystem identifier, the access interface and the business parameter request value are concatenated to obtain the distributed lock cache key value.

4. The system according to claim 1, characterized in that The locking control of the service request based on the distributed lock cache key value includes: Storing the distributed lock cache key value in the cache; If the caching is successful, a caching success signal is generated as response information of the service request, so that the subsystem to which the idempotent control access service scenario belongs performs the operation associated with the service request according to the response information; If the cache fails, the service request is intercepted.

5. A method for controlling idempotence of business requests in multiple business scenarios, characterized in that: A service request idempotence control system applied to a multi-service scenario as claimed in any one of claims 1 to 4, comprising: In response to the detected service request, obtaining a scenario control parameter associated with the service request, wherein the scenario control parameter is configured by the idempotence configuration module; Generate a distributed lock cache key value for the business request based on the scenario control parameter; Performing locking control on the service request based on the distributed lock cache key value; Wherein, in response to the detected service request, obtaining the scenario control parameters associated with the service request includes: parsing the service request to obtain the scenario identifier associated with the service request; and determining the idempotent service parameters associated with the service request based on the scenario identifier; The generating the distributed lock cache key value of the business request based on the scenario control parameter includes: generating the distributed lock cache key value of the business request according to the scenario identifier and the idempotent business parameter.

6. The method according to claim 5, characterized in that Also includes: In response to the detected idempotence control configuration request, obtaining a scenario identifier and at least one idempotence service parameter associated with the idempotence control configuration request; The scenario identifier and the at least one idempotent service parameter are stored correspondingly in a database.

7. A device for controlling idempotency of business requests in multiple business scenarios, characterized in that: include: A control parameter acquisition module, configured to obtain, in response to a detected service request, a scenario control parameter associated with the service request, wherein the scenario control parameter is configured by an idempotency configuration module in the service request idempotency control system for multiple service scenarios according to any one of claims 1 to 4; A cache key value generation module, used to generate a distributed lock cache key value of the business request based on the scenario control parameter; A lock control module, used to perform lock control on the service request based on the distributed lock cache key value; The control parameter acquisition module is specifically used to: parse the service request to obtain a scenario identifier associated with the service request; determine an idempotent service parameter associated with the service request based on the scenario identifier; The cache key value generation module is specifically used to generate a distributed lock cache key value of the business request according to the scenario identifier and the idempotent business parameter.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method for controlling the idempotence of business requests in multiple business scenarios as described in any one of claims 5-6 is implemented.

Images