Concurrent request processing method and apparatus, electronic device, and storage medium
By determining the target queue for concurrent requests in the message middleware and utilizing consumer threads for processing, write conflicts of concurrent requests are resolved, thereby improving database performance and service throughput.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHANGHAI ZHONG YUAN NETWORK CO LTD
- Filing Date
- 2022-09-28
- Publication Date
- 2026-07-03
AI Technical Summary
While existing technologies solve the data overwrite problem by using distributed locks when handling multiple concurrent requests, they are inefficient, leading to decreased database performance and reduced service throughput.
By receiving concurrent requests, determining their target object identifier, and writing them into the target message queue of the message middleware, these requests are processed sequentially by consumer threads, avoiding write conflicts and improving processing efficiency.
This approach improves database performance and service throughput while resolving concurrent write conflicts.
Smart Images
Figure CN115774724B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer technology, and in particular to a method, apparatus, electronic device and storage medium for processing concurrent requests. Background Technology
[0002] Nowadays, updating data in a database (such as adding, deleting, or modifying data) generally involves three steps: querying data, updating data, and writing data.
[0003] In practical applications, multiple update requests often exist for the same database simultaneously. In such cases, these requests are typically interleaved. During this process, when querying and writing data, it's possible that one update request might not be updating the data in time, resulting in one request retrieving outdated data. For example, while one update request is updating the database, another update request has already updated it. In this case, the write operation of the first update request will overwrite the write operation of the second, leading to the loss of the updated data corresponding to the second update request.
[0004] To address this issue, existing technologies employ distributed locks. Specifically, a distributed lock is added to the database before data is queried, and then released after the data is updated and written. This ensures that the data in the database is not updated by other update requests during the query-update-write process. However, this distributed lock solution is inefficient for scenarios with frequent concurrent updates, as it processes only one update request at a time, leading to decreased database performance and consequently, a drop in overall service throughput. Summary of the Invention
[0005] In view of this, in order to solve the above-mentioned technical problem that the low efficiency caused by processing only one update request at a time leads to a decrease in database performance and thus a decrease in the throughput of the entire service, the present invention provides a method, apparatus, electronic device and storage medium for processing concurrent requests.
[0006] In a first aspect, embodiments of the present invention provide a method for processing concurrent requests, the method comprising:
[0007] Receive multiple concurrent requests and determine the target object identifier for each concurrent request;
[0008] For each concurrent request, the target message queue is determined from the message middleware based on the target object identifier of the concurrent request, and the concurrent request is written to the target message queue;
[0009] For each message queue in the message middleware, the consumer thread corresponding to the message queue is invoked to process multiple concurrent requests in the message queue in sequence.
[0010] In one possible implementation, determining the target identifier for each of the concurrent requests includes:
[0011] For each of the concurrent requests, perform the following processing:
[0012] Parse the value of the target field from the concurrent requests;
[0013] The value of the target field is determined as the identifier of the object to which the concurrent request is applied.
[0014] In one possible implementation, determining the target message queue from the message middleware based on the target identifier of the concurrent request includes:
[0015] Determine whether there exists a message queue in the message middleware whose queue identifier matches the target identifier of the concurrent request;
[0016] If it exists, the message queue whose queue identifier matches the target object identifier of the concurrent request will be identified as the target message queue;
[0017] If the message queue does not exist, the currently empty message queue in the message middleware will be identified as the target message queue.
[0018] The method further includes:
[0019] After identifying an empty message queue in the message middleware as the target message queue, the queue identifier of the target message queue is set as the target object identifier of the concurrent request.
[0020] In one possible implementation, determining the target message queue from the message middleware based on the target identifier of the concurrent request includes:
[0021] Using the number of message queues in the message middleware as the divisor, perform a modulo operation on the object identifier of the concurrent request to obtain the modulo operation result;
[0022] The message queue in the message middleware whose number matches the result of the modulo operation is identified as the target message queue.
[0023] In one possible implementation, determining the target message queue from the message middleware based on the target identifier of the concurrent request includes:
[0024] The target priority of the concurrent request is determined based on the target object identifier of the concurrent request;
[0025] In the message middleware, the message queue whose queue priority is consistent with the target priority is determined as the target message queue.
[0026] In one possible implementation, one consumer thread corresponds to at least two message queues; the step of calling the consumer thread corresponding to the message queue to sequentially process multiple concurrent requests in the message queue includes:
[0027] The consumer thread corresponding to the message queue is invoked to read concurrent requests sequentially from the message queue. After reading a concurrent request, the consumer thread determines the target thread instance from the corresponding thread pool according to the target object identifier of the concurrent request, and invokes the target thread instance to process the read concurrent request.
[0028] In one possible implementation, determining the target thread instance from the corresponding thread pool based on the object identifier of the concurrent request read includes:
[0029] The modulo operation is performed on the object identifier of the concurrent request read by using the number of thread instances in the corresponding thread pool as the divisor to obtain the modulo operation result.
[0030] The thread instance in the thread pool whose number matches the result of the modulo operation is identified as the target thread instance.
[0031] Secondly, embodiments of the present invention provide a processing apparatus for concurrent requests, the apparatus comprising:
[0032] The first determining module is used to receive multiple concurrent requests and determine the target object identifier of each concurrent request;
[0033] The second determining module is used to determine the target message queue from the message middleware for each concurrent request based on the target object identifier of the concurrent request, and write the concurrent request into the target message queue;
[0034] The calling module is used to call the consumer thread corresponding to each message queue in the message middleware to process multiple concurrent requests in the message queue in sequence.
[0035] In one possible implementation, the first determining module is specifically used for:
[0036] For each of the concurrent requests, perform the following processing:
[0037] Parse the value of the target field from the concurrent requests;
[0038] The value of the target field is determined as the identifier of the object to which the concurrent request is applied.
[0039] As one possible implementation, the second determining module is specifically used for:
[0040] Determine whether there exists a message queue in the message middleware whose queue identifier matches the target identifier of the concurrent request;
[0041] If it exists, the message queue whose queue identifier matches the target object identifier of the concurrent request will be identified as the target message queue;
[0042] If the message queue does not exist, the currently empty message queue in the message middleware will be identified as the target message queue.
[0043] The device further includes:
[0044] The setting module is used to set the queue identifier of the target message queue as the target object identifier of the concurrent request after determining that a currently empty message queue in the message middleware is the target message queue.
[0045] In one possible implementation, the second determining module is specifically used for:
[0046] Using the number of message queues in the message middleware as the divisor, perform a modulo operation on the object identifier of the concurrent request to obtain the modulo operation result;
[0047] The message queue in the message middleware whose number matches the result of the modulo operation is identified as the target message queue.
[0048] In one possible implementation, the second determining module is specifically used for:
[0049] The target priority of the concurrent request is determined based on the target object identifier of the concurrent request;
[0050] In the message middleware, the message queue whose queue priority is consistent with the target priority is determined as the target message queue.
[0051] In one possible implementation, one consumer thread corresponds to at least two message queues; the invocation module includes:
[0052] The calling submodule is used to call the consumer thread corresponding to the message queue to read concurrent requests sequentially from the message queue. After reading a concurrent request, the consumer thread determines the target thread instance from the corresponding thread pool according to the target object identifier of the concurrent request, and calls the target thread instance to process the read concurrent request.
[0053] In one possible implementation, the calling submodule is specifically used for:
[0054] The modulo operation is performed on the object identifier of the concurrent request read by using the number of thread instances in the corresponding thread pool as the divisor to obtain the modulo operation result.
[0055] The thread instance in the thread pool whose number matches the result of the modulo operation is identified as the target thread instance.
[0056] Thirdly, embodiments of the present invention provide an electronic device, including: a processor and a memory, wherein the processor is configured to execute a concurrent request processing program stored in the memory to implement the concurrent request processing method described in any one of the first aspects.
[0057] Fourthly, embodiments of the present invention provide a storage medium storing one or more programs, which can be executed by one or more processors to implement the concurrent request processing method described in any one aspect.
[0058] The technical solution provided by this invention receives multiple concurrent requests, determines the target object identifier for each concurrent request, and for each concurrent request, determines the target message queue from the message middleware based on the target object identifier, and writes the concurrent request to the target message queue. This process, by writing concurrent requests with the same target object identifier to the same message queue, avoids the situation where the write operation of one concurrent request overwrites the write operation of another concurrent request when processing concurrent requests with the same target object simultaneously, thus preventing the loss of updated data corresponding to the other concurrent request. Furthermore, by having a single consumer thread process two or more message queues simultaneously, the processing efficiency of concurrent requests can be improved. This achieves the goal of resolving write conflicts of multiple concurrent requests while improving the processing efficiency of concurrent requests, improving database performance, and thereby increasing the throughput of the entire service. Attached Figure Description
[0059] Figure 1 This is a diagram illustrating how to handle concurrent requests.
[0060] Figure 2 This is a diagram illustrating another method for handling concurrent requests.
[0061] Figure 3 A flowchart illustrating an embodiment of a concurrent request processing method provided by an embodiment of the present invention;
[0062] Figure 4 A flowchart illustrating an embodiment of another concurrent request processing method provided by an embodiment of the present invention;
[0063] Figure 5 A flowchart illustrating an embodiment of another concurrent request processing method provided by the present invention;
[0064] Figure 6 A flowchart illustrating another embodiment of a concurrent request processing method provided by an embodiment of the present invention;
[0065] Figure 7 A flowchart illustrating an embodiment of a concurrent request processing method provided by an embodiment of the present invention;
[0066] Figure 8 A flowchart illustrating an embodiment of a concurrent request processing method provided by an embodiment of the present invention;
[0067] Figure 9 A block diagram illustrating an embodiment of a concurrent request processing apparatus provided in this invention;
[0068] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0069] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0070] To facilitate understanding of the embodiments of the present invention, the background technology involved in the embodiments of the present invention will be described in detail below.
[0071] Nowadays, updating data in a database generally involves three steps: querying data, updating data, and writing data.
[0072] In practical applications, there are often multiple update requests (hereinafter referred to as concurrent requests) for the same database. That is, multiple concurrent requests update the same database at the same time. In this case, the multiple concurrent requests are usually processed in an interleaved manner.
[0073] However, in the above process, when querying and writing data, there is often a situation where a concurrent request's data update is not timely, resulting in one of the concurrent requests retrieving outdated data. For example, if concurrent request A is updating the database while concurrent request B has already updated the database, then concurrent request A's write operation will overwrite concurrent request B's write operation, leading to the loss of the updated data corresponding to concurrent request B.
[0074] To better understand the specific process by which updated data is lost in the context of the concurrent requests mentioned above, the following example illustrates the situation:
[0075] For example, suppose there are two concurrent requests: Request1 and Request2, each handled by a separate thread. The objects targeted by these requests are {"id": 123", "name": "alan", "age": 25}. Request1 updates the "name" field in the target object from "alan" to "peter"; Request2 updates the "age" field in the target object from 25 to 30.
[0076] As a possible implementation, the processing procedure for the two concurrent requests mentioned above can be found in [reference needed]. Figure 1 .like Figure 1 The diagram shown illustrates how concurrent requests are handled. Figure 1 As shown in the process, the data retrieved by Request1 and Request2 simultaneously is {"id": 123", "name": "alan", "age": 25}.
[0077] Then, Request1 and Request2 update the data they retrieved. Request1's updated data is {"id": 123", "name": "peter", "age": 25}, and Request2's updated data is {"id": 123", "name": "alan", "age": 30}.
[0078] Finally, Request1 and Request2 write their updated data to the database. Among them, [the data is written by...]. Figure 1It can be seen that during the respective write operations of Request1 and Request2, when Request2 completes its write operation, that is, after Request2 changes the “age” field of the target object from 25 to 30 and writes it to the database, Request1 also completes its write operation, that is, after Request1 changes the “name” field of the target object from “alan” to “peter” and writes it to the database.
[0079] In this process, because Request1 and Request2 target the same object, the data written by Request1 will overwrite the data written by Request2, causing the updated data 30 in Request2 to be lost, while the "age" field in the target object remains 25. In other words, the write operation of Request1 overwrites the write operation of Request2, resulting in the loss of the updated data corresponding to Request2.
[0080] As another possible implementation, the processing procedure for the two concurrent requests mentioned above can be found in [reference needed]. Figure 2 .like Figure 2 The diagram shown illustrates another method for handling concurrent requests. Figure 2 As shown in the process, the data retrieved by Request1 and Request2 simultaneously is {"id": 123", "name": "alan", "age": 25}.
[0081] Then, Request1 and Request2 update the data they retrieved. Request1's updated data is {"id": 123", "name": "peter", "age": 25}, and Request2's updated data is {"id": 123", "name": "alan", "age": 30}.
[0082] Finally, Request1 and Request2 write their updated data to the database. Among them, [the data is written by...]. Figure 1 It can be seen that during the respective write operations of Request1 and Request2, when Request1 completes its write operation, that is, changes the “name” field of the target object from “alan” to “peter” and writes it to the database, Request2 also completes its write operation, that is, changes the “age” field of the target object from 25 to 30 and writes it to the database.
[0083] In this process, since Request1 and Request2 target the same object, the data written by Request2 will overwrite the data written by Request1. This causes the updated data "peter" in Request1 to be lost, while the "name" field in the target object remains "alan". In other words, the write operation of Request2 overwrites the write operation of Request1, resulting in the loss of the updated data corresponding to Request1.
[0084] To address the aforementioned issues, existing technologies solve these problems by adding distributed locks. Specifically, a distributed lock is added to the database before querying data, and the lock is released after updating and writing the data. This ensures that the data in the database will not be updated by other update requests during the query-update-write process.
[0085] For example, in the example above, a distributed lock can be added to the database containing the target object when executing Request1, and then released after Request1 completes the data write operation. Afterwards, Request2 can be executed following the same steps as Request1, thus preventing the loss of updated data corresponding to Request1 or Request2.
[0086] However, the aforementioned distributed lock scheme is inefficient in scenarios with frequent concurrent updates because it only processes one concurrent request at a time, leading to a decrease in database performance and consequently a decrease in the throughput of the entire service.
[0087] In response, this invention provides a method for handling concurrent requests, which resolves write conflicts between multiple concurrent requests, improves the efficiency of handling concurrent requests, enhances database performance, and thereby increases the throughput of the entire service.
[0088] The concurrent request processing method provided by the present invention will be further explained and described below with reference to the accompanying drawings and specific embodiments. The embodiments do not constitute a limitation on the embodiments of the present invention.
[0089] See Figure 3 This is a flowchart illustrating an embodiment of a concurrent request processing method provided by an embodiment of the present invention. Figure 3 As shown, the process may include the following steps:
[0090] Step 301: Receive multiple concurrent requests and determine the target object identifier for each concurrent request.
[0091] The aforementioned concurrent requests can be update requests for data in the database. The updates mentioned here can include operations such as adding, deleting, and modifying data.
[0092] The aforementioned target identifier can be used to characterize the target object corresponding to each concurrent request. Each concurrent request corresponds to a unique target identifier. If the target identifiers are the same in different concurrent requests, it means that the concurrent requests are acting on the same object.
[0093] In one embodiment, when the execution subject of this invention receives multiple concurrent requests, it can determine the target identifier corresponding to each concurrent request.
[0094] Specifically, the following processing can be performed for each concurrent request: First, parse the value of the target field from the concurrent request. Then, the value of the target field can be used as the identifier of the target object of the concurrent request. The target field includes, but is not limited to: user id (Identity document) as the target field when the target object of the concurrent request is a user information table, the table name or database name corresponding to the concurrent request, etc.
[0095] Step 302: For each concurrent request, determine the target message queue from the message middleware based on the target object identifier of the concurrent request, and write the concurrent request into the target message queue.
[0096] The aforementioned message middleware can be RocketMQ (Rocket Message Queue, an open-source message middleware) or RabbitMQ (Rabbit Message Queue, a message-oriented middleware), and this embodiment of the invention does not limit it in this way.
[0097] In this embodiment of the invention, the message middleware includes multiple message queues, each of which can be used to store two or more concurrent requests.
[0098] Based on this, concurrent requests with the same target object identifier can be written to the same message queue. Specifically, for each concurrent request, the target message queue can be determined from the message middleware according to the target object identifier of the concurrent request, and the concurrent request can be written to the target message queue.
[0099] As for how the target message queue is determined from the message middleware based on the target object identifier of the concurrent request, this will be explained in detail below. Figure 4 , Figure 5 as well as Figure 6 The process shown will be explained in detail here.
[0100] Step 303: For each message queue in the above message middleware, call the consumer thread corresponding to the message queue to process multiple concurrent requests in the message queue in sequence.
[0101] The aforementioned consumer threads can be used to handle at least one concurrent request. Each consumer thread can handle concurrent requests from at least one message queue in the message broker.
[0102] In one embodiment, for a message middleware, each message queue can correspond to a consumer thread, which can be used to process concurrent requests in the message queue. Since concurrent requests with the same target object are written to the same message queue, and the message queue is a "first-in, first-out" data structure, the consumer thread can process multiple concurrent requests in the message queue sequentially. This avoids the situation where the write operation of one concurrent request overwrites the write operation of another concurrent request when processing concurrent requests with the same target object simultaneously, thus preventing the loss of updated data corresponding to the other concurrent request.
[0103] As for how the consumer thread processes multiple concurrent requests in the message queue sequentially, this will be explained below. Figure 7 The process shown will be explained in detail here.
[0104] The technical solution provided by this invention receives multiple concurrent requests, determines the target object identifier of each concurrent request, and for each concurrent request, determines the target message queue from the message middleware based on the target object identifier, and writes the concurrent request to the target message queue. For each message queue in the message middleware, the corresponding consumer thread is invoked to process multiple concurrent requests in the message queue sequentially. This process, by writing concurrent requests with the same target object identifier to the same message queue and processing multiple concurrent requests in the message queue sequentially, avoids the situation where the write operation of one concurrent request overwrites the write operation of another concurrent request when processing concurrent requests with the same target object simultaneously, thus preventing the loss of updated data corresponding to the other concurrent request. Furthermore, each message queue can have a corresponding consumer thread to process multiple concurrent requests in the message queue sequentially, which improves the processing efficiency of concurrent requests. This achieves the goal of resolving write conflicts of multiple concurrent requests while improving the processing efficiency of concurrent requests, improving database performance, and thus increasing the throughput of the entire service.
[0105] See Figure 4 This is a flowchart of an embodiment of another concurrent request processing method provided by the present invention. Figure 4 The process shown is in Figure 3 Based on the illustrated process, this section describes how the target message queue is determined from the message middleware according to the target object identifier of the concurrent requests. For example... Figure 4 As shown, the process may include the following steps:
[0106] Step 401: Determine whether there is a message queue in the message middleware whose queue identifier matches the target identifier of the concurrent request mentioned above. If it exists, proceed to step 402; otherwise, proceed to step 403.
[0107] Step 402: Determine the message queue whose queue identifier matches the target object identifier of the concurrent request as the target message queue.
[0108] Step 403: Identify the currently empty message queue in the message middleware as the target message queue, and proceed to step 404.
[0109] Step 404: Set the queue identifier of the above message queue to the target identifier of the concurrent request.
[0110] The following provides a unified explanation of steps 401 to 404:
[0111] The queue identifier mentioned above is the queue identifier corresponding to each message queue in the message middleware.
[0112] Optionally, when the number of message queues in the message middleware is greater than or equal to the number of concurrent requests received from different target identifiers, each message queue may correspond to one queue identifier; when the number of message queues in the message middleware is less than the number of concurrent requests received from different target identifiers, each message queue may correspond to multiple queue identifiers. This embodiment of the invention does not impose any restrictions on this.
[0113] Optionally, when the message queue in the message middleware is empty, the queue identifier of the message queue can be set to empty, or set to a first value (e.g., 0 or 1). This embodiment of the invention does not impose any restrictions on this.
[0114] In this embodiment of the invention, when determining whether a target message queue exists in the message middleware, it can be determined whether a message queue with a queue identifier that matches the target object identifier of the concurrent request exists in the message middleware. If it exists, it means that a concurrent request with the target object identifier that matches the concurrent request has already been written to the message middleware. Therefore, in order to write concurrent requests with the same target object identifier to the same message queue, the message queue with a queue identifier that matches the target object identifier of the concurrent request can be determined as the target message queue.
[0115] Conversely, if there is no message queue in the message middleware whose queue identifier matches the target identifier of the concurrent request, it means that no concurrent request matching the target identifier of the concurrent request was written before. In this case, the currently empty message queue in the message middleware can be identified as the target message queue.
[0116] Then, the queue identifier of the target message queue can be set to the target object identifier of the concurrent request written to the target message queue.
[0117] The technical solution provided by this invention determines whether a message queue exists in the message middleware whose queue identifier matches the target identifier of the concurrent request. If such a message queue exists, it is identified as the target message queue. If not, an empty message queue in the message middleware is identified as the target message queue. Then, the queue identifier of the target message queue is used as the target identifier of the concurrent request. This process, by determining whether the queue identifier in the message queue matches the target identifier of the concurrent request, quickly identifies the target message queue from the message middleware, achieving fast and accurate identification of the target message queue from the message middleware.
[0118] See Figure 5 This is a flowchart of an embodiment of another concurrent request processing method provided by the present invention. Figure 5 The process shown is in Figure 3 Based on the illustrated process, this section describes how the target message queue is determined from the message middleware according to the target object identifier of the concurrent requests. For example... Figure 5 As shown, the process may include the following steps:
[0119] Step 501: Using the number of message queues in the message middleware as the divisor, perform a modulo operation on the target identifier of the concurrent request to obtain the modulo operation result.
[0120] Step 502: Identify the message queue in the message middleware whose number matches the result of the modulo operation as the target message queue.
[0121] The following provides a unified explanation of steps 501 and 502:
[0122] In this embodiment of the invention, each message queue in the message middleware can be numbered according to a preset arrangement order. For example, each message queue in the message middleware can be numbered sequentially from front to back as 0, 1, 2, 3...
[0123] Based on this, a modulo operation can be performed on the target identifier of concurrent requests to obtain the modulo operation result, and the message queue in the message middleware whose number matches the modulo operation result can be identified as the target message queue.
[0124] Furthermore, in order to prevent the accumulation of concurrent requests and the resulting reduction in the processing efficiency of concurrent requests when the number of message queues in the message middleware is less than the number of different target identifiers of concurrent requests, the execution subject of this embodiment of the invention can use the number of message queues in the message middleware as a divisor to perform a modulo operation on the target identifier of the concurrent request.
[0125] For example, suppose there are four message queues in the message middleware, numbered 0, 1, 2, and 3, and the different target identifiers of multiple concurrent requests are 1000, 1001, 1002, 1003, 1004, and 1005. Then, after performing a modulo operation on these target identifiers with 4 as the divisor, the modulo results are 0, 1, 2, 3, 0, and 1, respectively.
[0126] Then, concurrent requests with a modulo operation result of 0 are written to message queue number 0, concurrent requests with a modulo operation result of 1 are written to message queue number 1, concurrent requests with a modulo operation result of 2 are written to message queue number 2, and concurrent requests with a modulo operation result of 3 are written to message queue number 3. That is, concurrent requests with target identifiers 1000 and 1004 are written to message queue number 0, concurrent requests with target identifiers 1001 and 1005 are written to message queue number 1, concurrent requests with target identifier 1002 are written to message queue number 2, and concurrent requests with target identifier 1003 are written to message queue number 3.
[0127] The technical solution provided by this invention involves using the number of message queues in the message middleware as a divisor to perform a modulo operation on the object identifier of concurrent requests. The message queue in the message middleware whose number matches the modulo operation result is then identified as the target message queue. This process, by writing concurrent requests whose modulo operation result matches the message queue number, can quickly determine the target message queue based on the object identifier of the concurrent request. Simultaneously, it avoids the accumulation of concurrent requests when the number of message queues in the message middleware is less than the number of different object identifiers of concurrent requests, thus preventing a decrease in the processing efficiency of concurrent requests.
[0128] See Figure 6 This is a flowchart of another embodiment of the concurrent request processing method provided by the present invention. Figure 6 The process shown is in Figure 3 Based on the illustrated process, this section describes how the target message queue is determined from the message middleware according to the target object identifier of the concurrent requests. For example... Figure 6 As shown, the process may include the following steps:
[0129] Step 601: Determine the target priority of the concurrent request based on the target identifier of the concurrent request.
[0130] Step 602: In the message middleware, the message queue whose queue priority is consistent with the target priority is determined as the target message queue.
[0131] The following provides a unified explanation of steps 601 and 602:
[0132] In this embodiment of the invention, the priority of each message queue in the message middleware can be determined according to a preset arrangement order. For example, the priority of each message queue in the message middleware can be determined as level 1, level 2, level 3, etc. in a forward-backward order, or every N message queues can be grouped together, and the priority of each group can be determined as level 1, level 2, level 3, etc. in a forward-backward order.
[0133] Based on this, the priority of a concurrent request can be determined according to the target object identifier of the concurrent request (hereinafter referred to as the target priority for ease of description).
[0134] As one possible implementation, the execution entity of this embodiment can pre-store the correspondence between each target object and its priority. Based on this, the target object of the concurrent request can be determined according to the target object identifier of the concurrent request. Then, by looking up the pre-stored correspondence between each target object and its priority, the priority of the target object can be determined, and the priority of the target object can be set as the target priority of the concurrent request corresponding to that target object.
[0135] As another possible implementation, it can be determined whether the target object identifier of the aforementioned concurrent request is consistent with a preset important target object identifier. If they are consistent, the target priority of the concurrent request can be determined as level one; if they are inconsistent, the target priority of the concurrent request can be further determined as level two, level three, level four, etc., based on the number of identical target object identifiers. For example, the more identical target object identifiers there are, the higher the target priority of the concurrent request corresponding to that target object identifier.
[0136] Then, the message queue in the message middleware whose queue priority matches the target priority can be identified as the target message queue.
[0137] Optionally, if each queue priority corresponds to a message queue group, the message queue group whose priority matches the target priority can be determined as the target message queue group. Further, by... Figure 4 The process shown determines the target message queue based on the target object identifier of each concurrent request.
[0138] The technical solution provided by this invention determines the target priority of concurrent requests based on the target object identifier, and identifies the message queue in the message middleware whose queue priority matches the target priority as the target message queue. This solution, by determining the target priority of concurrent requests and identifying the message queue with the same queue priority as the target message queue, can quickly and accurately determine the target message queue from the message middleware.
[0139] See Figure 7 The following is a flowchart of an embodiment of a concurrent request processing method provided by an embodiment of the present invention. Figure 7 The process shown is in Figure 3 Based on the illustrated process, this section describes how the consumer thread corresponding to the message queue sequentially processes multiple concurrent requests in the message queue. For example... Figure 7 As shown, the process may include the following steps:
[0140] Step 701: Receive multiple concurrent requests and determine the target object identifier for each concurrent request.
[0141] Step 702: For each concurrent request, determine the target message queue from the message middleware based on the target object identifier of the concurrent request, and write the concurrent request to the target message queue.
[0142] For a detailed description of steps 701 and 702, please refer to the descriptions in steps 301 and 302, which will not be repeated here.
[0143] Step 703: For each message queue in the above message middleware, call the consumer thread corresponding to the message queue to read concurrent requests sequentially from the message queue.
[0144] Step 704: After reading the concurrent request, the consumer thread determines the target thread instance from the corresponding thread pool based on the target object identifier of the concurrent request, and calls the target thread instance to process the concurrent request.
[0145] The following provides a unified explanation of steps 703 and 704:
[0146] The aforementioned consumer thread can correspond to a thread pool, which may include multiple thread instances.
[0147] In one embodiment, for each message queue in the message middleware, the consumer thread corresponding to the message queue can be invoked to read concurrent requests sequentially from the message queue, and the target thread instance can be determined from the corresponding thread pool according to the target object identifier of the read concurrent request, and the target thread instance can be invoked to process the read concurrent request.
[0148] Optionally, as a possible implementation, when determining the target thread instance, the consumer thread can determine the target thread instance based on the target object identifier of the concurrent request when it first reads a concurrent request from the message queue, and store the correspondence between the target object identifier and the target thread instance. Subsequently, when a concurrent request with the same target object identifier as the first concurrent request read is read, the consumer thread can directly write the read concurrent request to the target thread instance based on the aforementioned correspondence between the target object identifier and the target thread instance.
[0149] As another possible implementation, the consumer thread can determine the target thread instance based on the target object identifier corresponding to the concurrent request each time it reads a concurrent request, and then write the concurrent request to the target thread instance.
[0150] Optionally, when determining the target thread instance from the corresponding thread pool based on the object identifier of the concurrent request, the number of thread instances in the corresponding thread pool can be used as a divisor to perform a modulo operation on the object identifier of the concurrent request. The thread instance in the thread pool whose number matches the modulo operation result can then be identified as the target thread instance.
[0151] For a specific example of determining the target thread instance based on the object identifier of the concurrent request, please refer to the example of determining the target message queue in steps 501 and 502. The implementation principle of both is the same.
[0152] The technical solution provided in this embodiment of the invention further involves, for each message queue in the aforementioned message middleware, calling the corresponding consumer thread to sequentially read concurrent requests from the message queue, and determining a target thread instance from the corresponding thread pool based on the target object identifier of the read concurrent request, and then calling that target thread instance to process the read concurrent request. This process, by having the consumer thread write the concurrent request into the target thread instance corresponding to the target object identifier of the concurrent request, allows the target thread instance to process the concurrent request, ensuring the correctness of processing concurrent requests for the same target object while improving the efficiency of concurrent request processing and enhancing database performance.
[0153] See Figure 8 The following is a flowchart illustrating an embodiment of a concurrent request processing method provided by an embodiment of the present invention. Figure 8 As shown, the process may include the following steps:
[0154] First, concurrent requests Request1 and Request2 can be encapsulated into messages and sent to the message middleware RocketMQ. The uid field is used as the identifier of the concurrent request's target object; therefore, the target object identifier for both Request1 and Request2 is 1001.
[0155] Then, the message middleware places Request1 and Request2 into message queue Queue2 based on the target identifiers of Request1 and Request2.
[0156] It is known that consumer threads may include Consumer1 and Consumer2, and the consumer thread corresponding to Queue2 is Consumer2. According to the descriptions in steps 603 and 604, after reading a concurrent request from Queue2, Consumer2 can determine the thread instance ThreadPool1 in Consumer2 as the target thread instance based on the target object identifier of the concurrent request. Then, it sends the concurrent request to ThreadPool1 for processing.
[0157] See Figure 9 This is a block diagram illustrating an embodiment of a concurrent request processing apparatus provided by an embodiment of the present invention. Figure 9 As shown, the device includes:
[0158] The first determining module 91 is used to receive multiple concurrent requests and determine the target identifier of each concurrent request;
[0159] The second determining module 92 is used to determine the target message queue from the message middleware according to the target object identifier of the concurrent request for each concurrent request, and write the concurrent request into the target message queue;
[0160] Module 93 is invoked to sequentially process multiple concurrent requests in each message queue in the message middleware by calling the consumer thread corresponding to that message queue.
[0161] In one possible implementation, the first determining module 91 is specifically used for:
[0162] For each of the concurrent requests, perform the following processing:
[0163] Parse the value of the target field from the concurrent requests;
[0164] The value of the target field is determined as the identifier of the object to which the concurrent request is applied.
[0165] As one possible implementation, the second determining module 92 is specifically used for:
[0166] Determine whether there exists a message queue in the message middleware whose queue identifier matches the target identifier of the concurrent request;
[0167] If it exists, the message queue whose queue identifier matches the target object identifier of the concurrent request will be identified as the target message queue;
[0168] If the message queue does not exist, the currently empty message queue in the message middleware will be identified as the target message queue.
[0169] The device also includes (not shown in the figure):
[0170] The setting module is used to set the queue identifier of the target message queue as the target object identifier of the concurrent request after determining that a currently empty message queue in the message middleware is the target message queue.
[0171] In one possible implementation, the second determining module 92 is specifically used for:
[0172] Using the number of message queues in the message middleware as the divisor, perform a modulo operation on the object identifier of the concurrent request to obtain the modulo operation result;
[0173] The message queue in the message middleware whose number matches the result of the modulo operation is identified as the target message queue.
[0174] In one possible implementation, the second determining module 92 is specifically used for:
[0175] The target priority of the concurrent request is determined based on the target object identifier of the concurrent request;
[0176] In the message middleware, the message queue whose queue priority is consistent with the target priority is determined as the target message queue.
[0177] In one possible implementation, one consumer thread corresponds to at least two message queues; the calling module 93 includes (not shown in the figure):
[0178] The calling submodule is used to call the consumer thread corresponding to the message queue to read concurrent requests sequentially from the message queue. After reading a concurrent request, the consumer thread determines the target thread instance from the corresponding thread pool according to the target object identifier of the concurrent request, and calls the target thread instance to process the read concurrent request.
[0179] In one possible implementation, the calling submodule is specifically used for:
[0180] The modulo operation is performed on the object identifier of the concurrent request read by using the number of thread instances in the corresponding thread pool as the divisor to obtain the modulo operation result.
[0181] The thread instance in the thread pool whose number matches the result of the modulo operation is identified as the target thread instance.
[0182] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Figure 10 The illustrated electronic device 1000 includes at least one processor 1001, a memory 1002, at least one network interface 1004, and a user interface 1003. The various components in the electronic device 1000 are coupled together via a bus system 1005. It is understood that the bus system 1005 is used to implement communication between these components. In addition to a data bus, the bus system 1005 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 10 The general labeled all buses as Bus System 1005.
[0183] The user interface 1003 may include a display, keyboard, or clicking device (e.g., mouse, trackball, touchpad, or touch screen).
[0184] It is understood that the memory 1002 in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate Synchronous DRAM (DDRSDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 1002 described herein is intended to include, but is not limited to, these and any other suitable types of memory.
[0185] In some implementations, memory 1002 stores elements, executable units or data structures, or subsets thereof, or extended sets thereof: operating system 10021 and application programs 10022.
[0186] The operating system 10021 includes various system programs, such as the framework layer, core library layer, and driver layer, used to implement various basic business functions and handle hardware-based tasks. The application program 10022 includes various applications, such as a media player and a browser, used to implement various application functions. The program implementing the method of this embodiment can be included in the application program 10022.
[0187] In this embodiment of the invention, by calling the program or instructions stored in the memory 1002, specifically the program or instructions stored in the application program 10022, the processor 1001 executes the method steps provided in each method embodiment, including, for example:
[0188] Receive multiple concurrent requests and determine the target object identifier for each concurrent request;
[0189] For each concurrent request, the target message queue is determined from the message middleware based on the target object identifier of the concurrent request, and the concurrent request is written to the target message queue;
[0190] For each message queue in the message middleware, the consumer thread corresponding to the message queue is invoked to process multiple concurrent requests in the message queue in sequence.
[0191] The methods disclosed in the above embodiments of the present invention can be applied to or implemented by processor 1001. Processor 1001 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit of the hardware in processor 1001 or by instructions in the form of software. The processor 1001 may be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of the present invention can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software units in the decoding processor. The software units may be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 1002. Processor 1001 reads the information in memory 1002 and, in conjunction with its hardware, completes the steps of the above method.
[0192] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described herein, or combinations thereof.
[0193] For software implementation, the techniques described herein can be implemented by units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented in the processor or external to the processor.
[0194] The electronic device provided in this embodiment may be as follows: Figure 10 The electronic device shown can perform the following: Figures 3-8 All steps of the concurrent request handling method are implemented to achieve... Figures 3-8 For details on the technical effectiveness of the concurrent request handling method shown, please refer to [link / reference]. Figures 3-8 The relevant descriptions are presented concisely and will not be elaborated upon here.
[0195] This invention also provides a storage medium (computer-readable storage medium). This storage medium stores one or more programs. The storage medium may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, hard disk, or solid-state drive; the memory may also include combinations of the above types of memory.
[0196] When one or more programs in the storage medium can be executed by one or more processors, the above-described method for handling concurrent requests executed on the electronic device side can be implemented.
[0197] The processor is used to execute a concurrent request processing program stored in memory to implement the steps of the concurrent request processing method executed on the electronic device side:
[0198] Receive multiple concurrent requests and determine the target object identifier for each concurrent request;
[0199] For each concurrent request, the target message queue is determined from the message middleware based on the target object identifier of the concurrent request, and the concurrent request is written to the target message queue;
[0200] For each message queue in the message middleware, the consumer thread corresponding to the message queue is invoked to process multiple concurrent requests in the message queue in sequence.
[0201] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.
[0202] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented in hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.
[0203] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A method for processing concurrent requests, characterized in that, The method includes: Receive multiple concurrent requests and determine the target object identifier for each concurrent request; For each concurrent request, the target message queue is determined from the message middleware based on the target object identifier of the concurrent request, and the concurrent request is written to the target message queue; For each message queue in the message middleware, the consumer thread corresponding to the message queue is invoked to process multiple concurrent requests in the message queue in sequence; Wherein, one consumer thread corresponds to at least two message queues, and the step of calling the consumer thread corresponding to the message queue to sequentially process multiple concurrent requests in the message queue includes: The consumer thread corresponding to the message queue is invoked to read concurrent requests sequentially from the message queue. After reading a concurrent request, the consumer thread determines the target thread instance from the corresponding thread pool according to the target object identifier of the concurrent request, and invokes the target thread instance to process the read concurrent request.
2. The method according to claim 1, characterized in that, The determination of the target object identifier for each concurrent request includes: For each of the concurrent requests, perform the following processing: Parse the value of the target field from the concurrent requests; The value of the target field is determined as the identifier of the object to which the concurrent request is applied.
3. The method according to claim 1, characterized in that, The step of determining the target message queue from the message middleware based on the target object identifier of the concurrent request includes: Determine whether there exists a message queue in the message middleware whose queue identifier matches the target identifier of the concurrent request; If it exists, the message queue whose queue identifier matches the target object identifier of the concurrent request will be identified as the target message queue; If the message queue does not exist, the currently empty message queue in the message middleware will be identified as the target message queue. The method further includes: After identifying an empty message queue in the message middleware as the target message queue, the queue identifier of the target message queue is set as the target object identifier of the concurrent request.
4. The method according to claim 1, characterized in that, The step of determining the target message queue from the message middleware based on the target object identifier of the concurrent request includes: Using the number of message queues in the message middleware as the divisor, perform a modulo operation on the object identifier of the concurrent request to obtain the modulo operation result; The message queue in the message middleware whose number matches the result of the modulo operation is identified as the target message queue.
5. The method according to claim 1, characterized in that, The step of determining the target message queue from the message middleware based on the target object identifier of the concurrent request includes: The target priority of the concurrent request is determined based on the target object identifier of the concurrent request; In the message middleware, the message queue whose queue priority is consistent with the target priority is determined as the target message queue.
6. The method according to claim 1, characterized in that, The step of determining the target thread instance from the corresponding thread pool based on the object identifier of the concurrent request read includes: The modulo operation is performed on the object identifier of the concurrent request read by using the number of thread instances in the corresponding thread pool as the divisor to obtain the modulo operation result. The thread instance in the thread pool whose number matches the result of the modulo operation is identified as the target thread instance.
7. A processing apparatus for concurrent requests, characterized in that, The device includes: The first determining module is used to receive multiple concurrent requests and determine the target object identifier of each concurrent request; The second determining module is used to determine the target message queue from the message middleware for each concurrent request based on the target object identifier of the concurrent request, and write the concurrent request into the target message queue; The calling module is used to call the consumer thread corresponding to each message queue in the message middleware to process multiple concurrent requests in the message queue in sequence. Wherein, one consumer thread corresponds to at least two message queues, and the step of calling the consumer thread corresponding to the message queue to sequentially process multiple concurrent requests in the message queue includes: The consumer thread corresponding to the message queue is invoked to read concurrent requests sequentially from the message queue. After reading a concurrent request, the consumer thread determines the target thread instance from the corresponding thread pool according to the target object identifier of the concurrent request, and invokes the target thread instance to process the read concurrent request.
8. An electronic device, characterized in that, include: A processor and a memory, the processor being configured to execute a concurrent request processing program stored in the memory to implement the concurrent request processing method according to any one of claims 1 to 6.
9. A storage medium, characterized in that, The storage medium stores one or more programs, which can be executed by one or more processors to implement the concurrent request processing method according to any one of claims 1 to 6.