Request processing method, device, equipment, storage medium and program product

Abstract

The present application discloses a request processing method, device, equipment, storage medium and program product, which relates to the field of data processing technology. The method includes: obtaining different types of requests; determining the serial attributes corresponding to different types of requests, and routing the different types of requests to corresponding processing partitions based on the serial attributes, wherein the serial attributes are the standards for classifying serial processing requests of the same type; in the corresponding processing partitions, using lock management strategies and queuing mechanisms to process different types of requests. The method routes the same type of requests to the same processing partition, and different types of requests to different processing partitions, and combines the lock management and queuing mechanisms within the processing partitions to achieve serial processing of the same type of requests and parallel processing of different types of requests, finely controlling the concurrency range, and taking into account the correctness of request processing, system throughput, and database resource intensiveness.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a request processing method, device, equipment, storage medium and program product. Background Art

[0002] When dealing with high-traffic activities such as flash sales or red envelope grabbing, in order to improve system processing capabilities, business systems usually asynchronously process long and time-consuming business logic to optimize throughput efficiency. For example, online processes handle inventory, while logic such as accounting and notifying users is transferred to asynchronous processing.

[0003] At the same time, during asynchronous processing, some scenarios require refined concurrency control of requests: requests of the same type need to be processed serially, and requests of different types can be processed in parallel. For example, in the accounting process, in order to ensure the accuracy and consistency of data, for those accounting operations that require instant update of account balances, it is necessary to ensure that the entry operations of the same account are executed serially.

[0004] In order to achieve such a concurrency control effect, the pessimistic lock strategy of the database is usually used to force sequential processing. For example, when locking an account balance record, only requests that obtain the lock can execute the corresponding transaction processing, while other requests need to wait for the lock to be released. However, in a high-concurrency scenario, if a large number of requests of the same type are reached at the same time, the lock competition becomes particularly fierce, which may cause the request to fall into a long-term blocked waiting state due to the inability to obtain the lock immediately. This not only consumes valuable thread and database connection resources, but may also cause operation failures due to waiting timeouts, causing system performance bottlenecks. Summary of the invention

[0005] The main purpose of this application is to provide a request processing method, device, equipment, storage medium and program product, aiming to solve the technical problem of how to effectively control concurrent requests to minimize lock contention.

[0006] To achieve the above objectives, the present application proposes a method for processing a request, the method comprising:

[0007] Get different types of requests;

[0008] Determining serial attributes corresponding to the different types of requests, and routing the different types of requests to corresponding processing partitions based on the serial attributes, wherein the serial attributes are a standard for classifying serial processing requests of the same type;

[0009] In the corresponding processing partition, lock management strategies and queuing mechanisms are used to process different types of requests.

[0010] In one embodiment, the step of determining the serial attributes corresponding to the different types of requests and routing the different types of requests to the corresponding processing partitions based on the serial attributes includes:

[0011] Determine serial attributes corresponding to different types of requests, and use the serial attributes as partition keys;

[0012] Distributing requests with the same serial attribute to the same processing partition based on the partition key; and

[0013] Requests with different serial attributes are randomly distributed to different processing partitions based on the partition key.

[0014] In one embodiment, the steps of processing different types of requests in the corresponding processing partition using a lock management strategy and a queuing mechanism include:

[0015] In the same processing partition, acquiring a lock corresponding to the request with the same serial attribute;

[0016] When the lock corresponding to the request with the same serial attribute is acquired successfully, executing the business logic corresponding to the request with the same serial attribute; or

[0017] In the different processing partitions, acquiring locks corresponding to requests for each serial attribute;

[0018] When the locks corresponding to the requests for the various serial attributes are acquired successfully, the business logics corresponding to the requests for the various serial attributes are executed in parallel.

[0019] In one embodiment, the step of processing different types of requests in the corresponding processing partition using a lock management strategy and a queuing mechanism further includes:

[0020] In the same processing partition, if requests with different serial attributes are detected, then a lock corresponding to each request with the serial attribute is acquired;

[0021] When the locks corresponding to the requests for the various serial attributes are acquired successfully, the business logics corresponding to the requests for the various serial attributes are executed in parallel.

[0022] In one embodiment, when the lock corresponding to the request with the same serial attribute is successfully acquired, after the step of executing the business logic corresponding to the request with the same serial attribute, the method further includes:

[0023] Release the lock corresponding to the current request with the same serial attribute;

[0024] The next request for the same serial attribute is processed asynchronously.

[0025] In one embodiment, the step of processing different types of requests in the corresponding processing partition using a lock management strategy and a queuing mechanism further includes:

[0026] When the lock acquisition corresponding to the request with the same serial attribute fails, the request with the same serial attribute is added to the waiting queue, and the processing of the request is terminated.

[0027] In addition, to achieve the above-mentioned purpose, the present application also proposes a request processing device, the request processing device comprising:

[0028] The acquisition module is used to obtain different types of requests;

[0029] A partitioning module, configured to determine serial attributes corresponding to the different types of requests, and to route the different types of requests to corresponding processing partitions based on the serial attributes, wherein the serial attributes are criteria for classifying serial processing requests of the same type;

[0030] The processing module is used to process different types of requests in the corresponding processing partition using a lock management strategy and a queuing mechanism.

[0031] In addition, to achieve the above-mentioned purpose, the present application also proposes a request processing device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the request processing method as described above.

[0032] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the request processing method described above are implemented.

[0033] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the request processing method described above are implemented.

[0034] The embodiment of the present application proposes a request processing method, device, equipment, storage medium and program product, the method comprising obtaining different types of requests; determining the serial attributes corresponding to different types of requests, and routing the different types of requests to corresponding processing partitions based on the serial attributes; in the corresponding processing partitions, using lock management strategies and queuing mechanisms to process different types of requests. The method routes the same type of requests to the same processing partition, and different types of requests to different processing partitions, and combines the lock management and queuing mechanisms within the processing partitions to achieve serial processing of the same type of requests and parallel processing of different types of requests, finely controlling the concurrency range, and taking into account the correctness of request processing, system throughput, and database resource intensiveness. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0036] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0037] Figure 1 A flowchart diagram of the first embodiment of the processing method for the present application request;

[0038] Figure 2 A flowchart diagram of Embodiment 2 of the processing method for the present application request is provided;

[0039] Figure 3 A flowchart diagram of Embodiment 3 of the processing method for the present application request is provided;

[0040] Figure 4 A flowchart diagram of Embodiment 4 of the processing method for the present application request is provided;

[0041] Figure 5 A brief flowchart of a method for processing a request provided in Example 1 of the present application;

[0042] Figure 6 A schematic diagram of the module structure of the processing device requested by the embodiment of the present application;

[0043] Figure 7 A schematic diagram of the device structure of the hardware operating environment involved in the processing method requested in the embodiment of the present application. DETAILED DESCRIPTION

[0044] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0045] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0046] The main solutions of the embodiments of the present application are: obtaining different types of requests; determining the serial attributes corresponding to different types of requests, and routing different types of requests to corresponding processing partitions based on the serial attributes; in the corresponding processing partitions, using lock management strategies and queuing mechanisms to process different types of requests.

[0047] When processing requests asynchronously, some scenarios require refined concurrency control of requests, such as serial processing of requests of the same type and parallel processing of requests of different types. For example, in the accounting process, in order to ensure the accuracy and consistency of data, for those accounting operations that require instant update of account balances, it is necessary to ensure that the entry operations of the same account are executed serially.

[0048] In order to achieve such a concurrency control effect, the pessimistic lock strategy of the database is usually used to force sequential processing. For example, when locking an account balance record, only requests that obtain the lock can execute the corresponding transaction processing, while other requests need to wait for the lock to be released. However, in a high-concurrency scenario, if a large number of requests of the same type are reached at the same time, the lock competition becomes particularly fierce, which may cause the request to fall into a long-term blocked waiting state due to the inability to obtain the lock immediately. This not only consumes valuable thread and database connection resources, but may also cause operation failures due to waiting timeouts, causing system performance bottlenecks.

[0049] The present application provides a solution, by obtaining different types of requests; determining the serial attributes corresponding to the different types of requests, and routing the different types of requests to the corresponding processing partitions based on the serial attributes; in the corresponding processing partitions, using lock management strategies and queuing mechanisms to process the different types of requests. This solution utilizes the partitioning characteristics of Kafka to route requests with the same serial attributes to the same processing partition, and requests with different serial attributes are randomly routed to different processing partitions, to achieve concurrency control, independent of the database, lightweight concurrency control, and high processing performance. And use lock management strategies and queuing mechanisms to avoid request blocking or even timeout errors.

[0050] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, etc. The following takes a personal computer as an example to illustrate this embodiment and the following embodiments.

[0051] Based on this, the present application embodiment provides a method for processing a request, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the processing method requested by this application.

[0052] In this embodiment, the request processing method includes steps S10 to S30:

[0053] Step S10, obtaining different types of requests;

[0054] In this embodiment, in order to obtain different types of requests from a message queue (such as Kafka), one or more consumer instances are first created to subscribe to a specific topic, and requests are periodically pulled from the topic from the consumer instance.

[0055] Step S20, determining serial attributes corresponding to the different types of requests, and routing the different types of requests to corresponding processing partitions based on the serial attributes, wherein the serial attributes are a standard for classifying serial processing requests of the same type;

[0056] It is worth noting that in order to achieve efficient concurrency control without relying on a database, by executing step S20, not only can thread blocking be effectively avoided, but also the throughput and response speed of the system can be improved.

[0057] In a feasible implementation, step S20 may include steps S21 to S23:

[0058] Step S21, determining serial attributes corresponding to different types of requests, and using the serial attributes as partition keys;

[0059] In this embodiment, the hash key-based partitioning strategy provided by Kafka is used to achieve fine concurrency control of requests during asynchronous processing, such as serial execution of accounting requests for the same account and parallel execution of accounting requests for different accounts. Kafka is a distributed stream processing platform that allows users to publish and subscribe to record streams and can store these record streams. The data unit in Kafka is called a message, and a collection of messages is organized into topics. Each topic can be divided into multiple partitions, which are the basic units of parallel processing, and the messages in each partition are ordered.

[0060] Specifically, first determine the serial attributes of each request. Based on business requirements, define one or more attributes as serial attributes. These attributes are usually unique identifiers, such as user ID, order number, session ID, etc. For example, if you need to ensure that each user's operations are processed in sequence, then the user ID is used as a serial attribute. If you need to ensure that all updates to the same order are processed in sequence, then the order number is used as a serial attribute. If you need to keep all events within a session in order, then the session ID is used as a serial attribute.

[0061] Once the serial attribute is determined, it is used as the partition key of the request so that Kafka can assign the request to the correct processing partition based on this partition key.

[0062] Step S22, distributing requests with the same serial attribute to the same processing partition based on the partition key;

[0063] Since messages on a Kafka partition will only be consumed exclusively by one consumer instance, requests with the same serial attributes will be processed exclusively by the same consumer instance, that is, requests with the same serial attributes will be distributed to the same Kafka processing partition for processing.

[0064] Specifically, when sending a message, the Kafka producer calculates a hash value based on the requested partition key, and then uses this hash value modulo the number of partitions in the topic to determine which specific partition the request should be written to.

[0065] Subsequently, all requests with the same serial attributes (such as user ID, order number, etc.) are sent to the same partition, thereby ensuring that the requests are ordered within the partition.

[0066] Step S23: randomly distribute the requests with different serial attributes to different processing partitions based on the partition key.

[0067] In this embodiment, for messages that do not need to be processed in strict order, they can be dispersed into multiple partitions of Kafka through different serial attributes so as to be processed in parallel and improve throughput.

[0068] Specifically, when the partition key values ​​of the requests are different, Kafka uses a hash algorithm to determine the processing partition to which the request belongs. Since the partition key values ​​of different serial attribute requests are different, the hash results will also be different, so requests with different serial attributes will be randomly assigned to different processing partitions.

[0069] By using keys to randomly distribute requests with different serial attributes to different processing partitions of Kafka, requests with different serial attributes can be evenly distributed among the partitions, thereby making full use of cluster resources and improving processing efficiency.

[0070] Through the above mechanism, requests with the same serial attributes are distributed to the same processing partition in Kafka, and requests with different attributes are distributed to different processing partitions in Kafka, so that requests that need to be processed serially are accepted in the same processing partition, and requests that are allowed to be processed in parallel are accepted in different processing partitions.

[0071] Take the red envelope grabbing activity as an example: User A grabs 2 red envelopes, User B grabs 1 red envelope, and User C grabs 1 red envelope. After the inventory logic of the 4 requests is processed online, they are transferred to Kafka for asynchronous accounting processing. According to the serial attribute (in this scenario, the serial attribute is the account entry account) as the Kafka partition key, the 2 requests (Req1~Req2) of account A are routed to partition 1 in Kafka, and the messages in partition 1 of Kafka are processed by consumer instance Consumer1; the request (Req3) of account B is routed to partition 1 of Kafka, and the messages in partition 1 of Kafka are processed by consumer instance Consumer1; the request (Req4) of account C is routed to partition 3 of Kafka, and the messages in partition 3 of Kafka are processed by consumer instance Consumer3.

[0072] Step S30: In the corresponding processing partition, the lock management strategy and queuing mechanism are used to process the different types of requests.

[0073] It should be noted that the lock management strategy refers to controlling access to shared resources through locking mechanisms in a multi-threaded or multi-process environment to avoid race conditions and data inconsistency. Common locks include but are not limited to mutex locks, read-write locks, semaphore locks, etc.

[0074] In Kafka consumer applications, lock management strategies can be used to ensure that only one consumer instance processes requests for a specific key value at a time, thereby ensuring the order and consistency of these requests.

[0075] The queuing mechanism manages and schedules the processing order of requests by maintaining one or more queues. The queuing mechanism ensures that requests with the same serial attributes are processed in order, and temporarily stores requests when the lock is not available, waiting for the lock to be released before processing.

[0076] It is worth noting that in order to achieve serial processing of requests of the same type and parallel processing of requests of different types, the concurrency range is finely controlled, so step S30 is executed to improve the correctness of request processing, system throughput and efficient use of database resources.

[0077] In a feasible implementation, step S30 may include steps S31 to S34:

[0078] Step S31, in the same processing partition, obtaining a lock corresponding to the request with the same serial attribute;

[0079] Optionally, after request routing in step S20, requests with the same serial attributes are distributed to the same partition in Kafka, and requests with different serial attributes are randomly distributed to different partitions in Kafka.

[0080] When multiple requests with the same serial attribute are routed to the same partition in Kafka, the consumer instance in Kafka first attempts to acquire the lock corresponding to the serial attribute. For example, for a certain account, only one accounting request for the account is allowed to hold the lock at the same time.

[0081] Step S32, when the lock corresponding to the request with the same serial attribute is acquired successfully, executing the business logic corresponding to the request with the same serial attribute;

[0082] Optionally, after acquiring the lock, the business logic code corresponding to the request is executed. Regardless of whether the processing is successful or not, the lock must be released to avoid deadlock.

[0083] Among them, when performing business logic processing on requests with the same serial attributes, for requests that need to be processed serially, the lock can ensure that these messages or requests are processed in the expected order. For example, for all operations with the same user ID, the lock can be obtained by using the user ID as the key to ensure that these operations are executed in sequence.

[0084] Step S33, obtaining locks corresponding to requests of various serial attributes in the different processing partitions;

[0085] Optionally, in different processing partitions of Kafka, requests with different serial attributes can be processed in parallel, while ensuring that requests for each serial attribute are processed in order.

[0086] In this embodiment, an independent lock is acquired for each serial attribute request. The lock corresponding to each serial attribute is stored by using a global and local lock manager. Multiple threads or multiple consumer instances are used to process requests in different partitions. Each consumer thread attempts to acquire the lock corresponding to the serial attribute before processing the request.

[0087] Step S34: when the locks corresponding to the requests for the respective serial attributes are acquired successfully, the business logics corresponding to the requests for the respective serial attributes are executed in parallel.

[0088] Optionally, if the lock is acquired successfully, the business logic is executed in parallel; otherwise, the requests for each serial attribute are added to a waiting queue to wait for processing.

[0089] It should be noted that there can be different implementation strategies for serial locks, and various functions can be customized according to needs. A simple implementation method is to use ConcurrentHashMap (a concurrent and safe hash table in a multi-threaded environment). The serial attribute is used as the hash key of the hash table, and the corresponding value is an object containing detailed information about the lock behavior, such as the lock timestamp, the thread ID holding the lock, and related business data. Using this information, features such as mutually exclusive access, reentrant operations, and automatic unlocking after timeout can be implemented.

[0090] Through the above steps, after multiple requests of the same type are routed to the same consumer instance, they will be executed serially according to the order in which the locks are acquired. Multiple requests of different types can be executed in parallel after being routed to the same consumer instance or different consumer instances.

[0091] In the above-mentioned embodiment method, different types of requests are obtained; the serial attributes corresponding to the different types of requests are determined, and the different types of requests are routed to corresponding processing partitions based on the serial attributes, wherein the serial attributes are the standard for classifying serial processing requests of the same type; in the corresponding processing partitions, the different types of requests are processed using lock management strategies and queuing mechanisms. This solution utilizes the partitioning characteristics of Kafka to route requests with the same serial attributes to the same processing partition, and requests with different serial attributes are randomly routed to different processing partitions, thereby achieving concurrency control, which is independent of the database, and has lightweight concurrency control and high processing performance. In addition, lock management strategies and queuing mechanisms are used to avoid request blocking or even timeout errors.

[0092] Based on the first embodiment of the present application, in the second embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 2 , step S30 further includes steps A1 to A2:

[0093] Step A1, in the same processing partition, if requests with different serial attributes are detected, then acquiring locks corresponding to the requests with each serial attribute;

[0094] Optionally, when multiple requests with different serial attributes are routed to the same consumer instance, each request can independently acquire the corresponding lock. For example, a request to deposit to account A holds the lock of account A, while a request to deposit to account B holds the lock of account B.

[0095] Step A2: when the locks corresponding to the requests of the respective serial attributes are acquired successfully, the business logics corresponding to the requests of the respective serial attributes are executed in parallel.

[0096] Optionally, if the locks corresponding to the requests of various serial attributes are acquired successfully, the business logic codes corresponding to the various requests are executed in parallel without conflict and are processed in parallel.

[0097] Through the above embodiment method, requests with different serial attributes are processed in parallel in the same consumer instance, while ensuring that messages with each serial attribute are processed in sequence, which not only improves the throughput of the system but also ensures the consistency and sequence of data.

[0098] Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 3 , after step S32, further comprising steps B1 to B2:

[0099] Step B1, releasing the lock corresponding to the current request with the same serial attribute;

[0100] Optionally, after the business logic processing of the current request is completed, the currently held lock is released immediately to ensure that after the current request processing is completed, other waiting requests with the same serial attribute can continue to be processed.

[0101] Step B2: asynchronously process the next request for the same serial attribute.

[0102] Optionally, use a thread pool to manage asynchronous processing of requests. Maintain a waiting queue to store unprocessed requests. After releasing the lock, check whether the waiting queue is empty. If it is not empty, take the next request with the same serial attribute from the waiting queue and submit a new task to the thread pool for processing. This step ensures that requests with the same serial attribute are processed in order and that the next request can be processed in time after releasing the lock.

[0103] Through the above embodiment method, requests with the same serial attribute are processed in sequence in the same consumer instance, and after the lock is released, the next request in the waiting queue is automatically processed, which not only ensures the consistency and sequence of data, but also improves the concurrent processing capability of the system.

[0104] Based on the first embodiment of the present application, in the third embodiment of the present application, the same or similar contents as those in the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following. Figure 4 , step S30 further includes step C1:

[0105] Step C1, when the lock acquisition corresponding to the request with the same serial attribute fails, the request with the same serial attribute is added to a waiting queue, and the processing of the request is terminated.

[0106] Optionally, before processing a request, if an attempt to obtain a lock corresponding to a serial attribute fails, the request is added to a waiting queue and processing of the current request ends.

[0107] When the lock acquisition fails, the request is added to the waiting queue, thus avoiding the thread from being blocked due to waiting for the lock. This not only ensures the consistency and order of data, but also improves the concurrent processing capability of the system.

[0108] For example, to help understand the implementation process of the request processing method obtained by combining this embodiment with the above-mentioned embodiment 1, please refer to Figure 5 , Figure 5 A brief flowchart of a request processing method is provided, specifically:

[0109] This embodiment adopts Kafka's partitioning strategy based on hash keys, and messages with the same key will be assigned to the same partition. When the request is transferred to Kafka for asynchronous processing, the serial attribute is used as the partition key, so that requests with the same serial attributes that need to be processed serially are routed to the same partition, and requests with different serial attributes are randomly scattered to different partitions.

[0110] Messages on a partition of Kafka will only be consumed exclusively by one consumer instance, so requests with the same serial attributes will be processed exclusively by the same consumer instance, and requests with different serial attributes will be randomly allocated in the consumer instance.

[0111] Through the above mechanism, requests with the same serial attributes are distributed to the same processing partition, and requests with different attributes are distributed to different processing partitions, so that requests that need to be processed serially are accepted in the same processing partition, and requests that allow parallel processing are accepted in different processing partitions.

[0112] After requests with different serial attributes are routed, requests with the same serial attributes are distributed to the same consumer instance, and requests with different serial attributes are randomly distributed to different consumer instances.

[0113] When multiple requests with the same serial attribute are routed to the same consumer instance, the instance first attempts to obtain a fine-grained lock specific to the attribute (for example, for a certain account entry, only one accounting request for the account is allowed to hold the lock at the same time). If the acquisition fails, the request is added to the waiting queue and the processing ends; if the acquisition succeeds, the business logic code is executed, and after completion, the next task is selected from the waiting queue and asynchronous processing is switched again.

[0114] When multiple requests with different serial attributes are routed to the same consumer instance, each request can independently acquire the corresponding lock without conflicting with each other, and execute the business logic code corresponding to each request in parallel.

[0115] Through the above mechanism, multiple requests of the same type are routed to the same consumer instance and executed serially according to the order in which the locks are acquired. Multiple requests of different types can be executed in parallel after being routed to the same consumer instance or different consumer instances.

[0116] Take the user red envelope grabbing activity as an example: Consumer instance Consumer1 receives and processes three requests Req1 to Req3 from accounts A and B. The timing is as follows:

[0117] (a) Req1 obtains the lock of account A and executes the entry logic;

[0118] (b) Req2 is added to the waiting queue because the lock of account A has been acquired by Req1, and the request ends;

[0119] (c) Req3 obtains the lock of account B and executes the entry logic;

[0120] (d) After Req1 is recorded, Req2 is found in the waiting queue, and it is woken up and switched to asynchronous execution, and the request ends;

[0121] (e) After Req3 is recorded, it is found that there is no task in the waiting queue, and the request ends;

[0122] (f) Req2 obtains the lock of account A and executes the entry logic;

[0123] (g) After Req2 is recorded, it is found that there is no task in the waiting queue, and the request ends.

[0124] Consumer instance Consumer2 receives and processes request Req4 from account C. The timing is as follows:

[0125] (a) Req4 obtains the lock of account C and executes the entry logic;

[0126] (b) After Req4 is recorded, it is found that there is no task in the waiting queue, and the request ends.

[0127] As can be seen from the above, this embodiment uses Kafka to convert online requests into asynchronous processing. Through Kafka's partitioning strategy, requests of the same type are routed to the same processing partition, and requests of different types are routed to different processing partitions. In combination with the lock management and queuing mechanism within the processing partition, serial processing of requests of the same type and parallel processing of requests of different types are realized, and the concurrency range is finely controlled, so as to achieve a balance between request processing correctness, system throughput capacity, and database resource concentration.

[0128] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the processing method requested by the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0129] This application also provides a request processing device, please refer to Figure 6 , the request processing device includes:

[0130] An acquisition module 10, used to acquire different types of requests;

[0131] A partitioning module 20, configured to determine serial attributes corresponding to the different types of requests, and to route the different types of requests to corresponding processing partitions based on the serial attributes, wherein the serial attributes are criteria for classifying serial processing requests of the same type;

[0132] The processing module 30 is used to process different types of requests in the corresponding processing partition using a lock management strategy and a queuing mechanism.

[0133] The request processing device provided by the present application adopts the request processing method in the above embodiment, which can solve the technical problem of how to effectively control concurrent requests to minimize lock contention. Compared with the prior art, the beneficial effects of the request processing device provided by the present application are the same as the beneficial effects of the request processing method provided by the above embodiment, and other technical features in the request processing device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0134] The present application provides a request processing device, which includes: at least one processor; and a memory that is communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the request processing method in the above-mentioned embodiment one.

[0135] Reference below Figure 7 , which shows a schematic diagram of the structure of a request processing device suitable for implementing the embodiment of the present application. The request processing device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 7The request processing device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0136] like Figure 7 As shown, the requested processing device may include a processing device 1001 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. In RAM1004, various programs and data required for the operation of the requested processing device are also stored. The processing device 1001, ROM1002, and RAM1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: an input device 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; an output device 1008 including, for example, a liquid crystal display (LCD: Liquid Crystal Display), a speaker, a vibrator, etc.; a storage device 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 1009. The communication device 1009 can allow the request processing device to communicate with other devices wirelessly or by wire to exchange data. Although the figure shows the request processing device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0137] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0138] The request processing device provided by the present application adopts the request processing method in the above embodiment, which can solve the technical problem of how to effectively control concurrent requests to minimize lock contention. Compared with the prior art, the beneficial effects of the request processing device provided by the present application are the same as the beneficial effects of the request processing method provided by the above embodiment, and other technical features in the request processing device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0139] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0140] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0141] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the request processing method in the above-mentioned embodiment.

[0142] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: 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 embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0143] The computer-readable storage medium may be included in the requested processing device; or may exist independently without being installed in the requested processing device.

[0144] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the requested processing device, the requested processing device: obtains different types of requests; determines the serial attributes corresponding to the different types of requests, and routes the different types of requests to corresponding processing partitions based on the serial attributes, wherein the serial attributes are the standards for classifying serial processing requests of the same type; and uses lock management strategies and queuing mechanisms in the corresponding processing partitions to process different types of requests.

[0145] Computer program code for performing the operations of the present application 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., via the Internet using an Internet service provider).

[0146] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0147] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0148] The readable storage medium provided by the present application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned request processing method, and can solve the technical problem of how to effectively control concurrent requests to minimize lock contention. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided by the present application are the same as the beneficial effects of the request processing method provided by the above-mentioned embodiment, and will not be repeated here.

[0149] The present application also provides a computer program product, including a computer program, which implements the steps of the request processing method as described above when the computer program is executed by a processor.

[0150] The computer program product provided by the present application can solve the technical problem of how to effectively control concurrent requests to minimize lock contention. Compared with the prior art, the beneficial effects of the computer program product provided by the present application are the same as the beneficial effects of the request processing method provided by the above embodiment, which will not be repeated here.

[0151] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for processing a request, characterized in that: The method comprises: Get different types of requests; Determining serial attributes corresponding to the different types of requests, and routing the different types of requests to corresponding processing partitions based on the serial attributes, wherein the serial attributes are a standard for classifying serial processing requests of the same type; In the corresponding processing partition, the different types of requests are processed using a lock management strategy and a queuing mechanism.

2. The method according to claim 1, characterized in that The step of determining the serial attributes corresponding to the different types of requests and routing the different types of requests to the corresponding processing partitions based on the serial attributes includes: Determine serial attributes corresponding to different types of requests, and use the serial attributes as partition keys; Distributing requests with the same serial attribute to the same processing partition based on the partition key; and Requests with different serial attributes are randomly distributed to different processing partitions based on the partition key.

3. The method according to claim 2, characterized in that The steps of processing the different types of requests in the corresponding processing partition using a lock management strategy and a queuing mechanism include: In the same processing partition, acquiring a lock corresponding to the request with the same serial attribute; When the lock corresponding to the request with the same serial attribute is acquired successfully, executing the business logic corresponding to the request with the same serial attribute; or In the different processing partitions, acquiring locks corresponding to requests for each serial attribute; When the locks corresponding to the requests for the various serial attributes are acquired successfully, the business logics corresponding to the requests for the various serial attributes are executed in parallel.

4. The method according to any one of claims 2 to 3, characterized in that The step of processing the different types of requests in the corresponding processing partition using a lock management strategy and a queuing mechanism also includes: In the same processing partition, if requests with different serial attributes are detected, then a lock corresponding to each request with the serial attribute is acquired; When the locks corresponding to the requests for the various serial attributes are acquired successfully, the business logics corresponding to the requests for the various serial attributes are executed in parallel.

5. The method according to claim 3, characterized in that After the step of executing the business logic corresponding to the request with the same serial attribute when the lock corresponding to the request with the same serial attribute is successfully acquired, the method further includes: Release the lock corresponding to the current request with the same serial attribute; The next request for the same serial attribute is processed asynchronously.

6. A method according to claim 3, characterized in that The step of processing the different types of requests in the corresponding processing partition using a lock management strategy and a queuing mechanism also includes: When the lock acquisition corresponding to the request with the same serial attribute fails, the request with the same serial attribute is added to the waiting queue, and the processing of the request is terminated.

7. A request processing device, characterized in that: The device comprises: The acquisition module is used to obtain different types of requests; A partitioning module, configured to determine serial attributes corresponding to the different types of requests, and to route the different types of requests to corresponding processing partitions based on the serial attributes, wherein the serial attributes are criteria for classifying serial processing requests of the same type; The processing module is used to process different types of requests in the corresponding processing partition using a lock management strategy and a queuing mechanism.

8. A request processing device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the request processing method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the request processing method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the request processing method according to any one of claims 1 to 6 are implemented.

Images