Service request processing method and device, medium, equipment and program product

Abstract

The invention discloses a service request processing method and device, a medium, equipment and a program product, and relates to the technical field of smart home / smart home. According to the method, a first service request is received, the first service request comprises at least one target resource, a lock identifier is generated for the first service request, the lock identifier comprises a serial number used for identifying the receiving sequence of the first service request, and the lock identifier of the first service request is added into distributed queues corresponding to the at least one target resource. Under the condition that the lock identifier of the first service request is arranged at the head in the distributed queue corresponding to the at least one target resource, requesting to allocate a respective resource lock of the at least one target resource for the first service request; according to the method, the uniform lock identifier containing the serial number is generated for the service request, and resource lock coordination is performed based on the distributed queue, so that the consistency of a multi-resource locking sequence is ensured, deadlock is effectively avoided, and the stability and reliability of service processing in a high-concurrency scene are improved.

Description

Technical Field

[0001] This application relates to the field of smart home / intelligent home technology, and more specifically, to a method, apparatus, medium, device, and program product for processing business requests. Background Technology

[0002] With the rapid development of internet technology, distributed system architecture has become the mainstream choice for enterprise applications. In this architecture, multiple service instances run simultaneously, requiring coordinated access control of shared resources to avoid data contention and inconsistency issues. Ensuring the order and consistency of resource access in high-concurrency scenarios is crucial.

[0003] In existing technologies, the processing method for business requests is based on locks in relational databases. When a business request triggers a database transaction, the database first determines the scope of the data to be operated on and requests a lock of the corresponding granularity according to the transaction isolation level and operation type. If the target resource has been locked by other transactions, the current request will enter a waiting queue until the lock is released or a timeout occurs. When the transaction is completed (committed or rolled back), the database will immediately release the lock it holds, allowing requests in the waiting queue to acquire locks in order and continue execution.

[0004] However, when a business needs to operate on multiple resources simultaneously, if a step-by-step locking strategy is adopted, different transactions may request to lock the same batch of resources in reverse order, causing each transaction to hold partial resource locks and wait for the other to release them, resulting in a deadlock and affecting the stability of business processing. Summary of the Invention

[0005] This application provides a method, apparatus, medium, device, and program product for processing business requests, in order to solve the problem of low stability in business processing.

[0006] Firstly, this application provides a method for processing business requests, including:

[0007] Receive a first service request, wherein the first service request contains at least one target resource;

[0008] Generate a lock identifier for the first service request, the lock identifier including a sequence number used to identify the receiving order of the first service request;

[0009] Add the lock identifier of the first service request to the distributed queue corresponding to each of the at least one target resource;

[0010] If the lock identifier of the first service request is at the head of the distributed queue corresponding to each of the at least one target resource, the request is made to allocate the resource lock of each of the at least one target resource to the first service request.

[0011] In one possible implementation, after the request allocates resource locks for each of the at least one target resource for the first service request, it further includes:

[0012] Determine whether the resource lock for each target resource has been successfully acquired;

[0013] If all target resource locks are successfully acquired, a lock record corresponding to the first service request is generated, and a lock holding certificate is returned to the client that sent the first service request. The lock holding certificate contains the lock identifier.

[0014] If the acquisition of the resource lock for any target resource fails, the resource lock for the target resource is released, and a lock conflict exception is returned to the client.

[0015] In one possible implementation, after returning a lock conflict exception to the first service request, the method further includes:

[0016] Determine whether the current time exceeds the timeout period of the first service request and whether the number of retries has reached a preset threshold;

[0017] If the current time has not exceeded the timeout period and the number of retries has not reached the preset threshold, then after the first preset time, a new request is made to allocate resource locks for each of the at least one target resource for the first service request.

[0018] In one possible implementation, the method further includes:

[0019] If the current time exceeds the timeout period or the number of retries reaches a preset threshold, the lock identifier record in the distributed queue is deleted, and a lock allocation timeout notification is sent to the client.

[0020] In one possible implementation, the method further includes:

[0021] If the sequence number of the first service request is not at the head of the distributed queue corresponding to each of the at least one target resource, then after a second preset time, it is re-determined whether the sequence number of the first service request is at the head of the distributed queue corresponding to each of the at least one target resource, until the sequence number of the first service request is at the head of the distributed queue corresponding to each of the at least one target resource, or the current time exceeds the timeout period of the first service request.

[0022] In one possible implementation, the lock identifier includes an identity identifier, and after requesting the first service to return the lock holding certificate, the method further includes:

[0023] Receive a lock release instruction from the first service request, wherein the lock release instruction includes the at least one target resource and the lock holding certificate;

[0024] Determine whether the lock identifier and the identity identifier match the lock holding certificate;

[0025] If both the lock identifier and the identity identifier match the lock holding certificate, then delete the lock record and the record of the sequence number in the distributed queue;

[0026] If the lock identifier of any target resource does not match the sequence number, a lock release exception is returned to the client.

[0027] Secondly, this application provides a service request processing apparatus, comprising:

[0028] A receiving module is configured to receive a first service request, wherein the first service request contains at least one target resource;

[0029] A generation module is used to generate a lock identifier for the first service request, wherein the lock identifier includes a sequence number used to identify the receiving order of the first service request;

[0030] The processing module is used to add the lock identifier of the first service request to the distributed queue corresponding to each of the at least one target resource;

[0031] The request module is configured to request the allocation of resource locks for the first service request for each of the at least one target resource, provided that the lock identifier of the first service request is at the head of the distributed queue corresponding to each of the at least one target resource.

[0032] In one possible implementation, the service request processing apparatus further includes: a determining module, a sending module, and a returning module;

[0033] The determining module is used to determine whether the resource lock for each target resource has been successfully acquired;

[0034] The sending module is configured to generate a lock record corresponding to the first service request if all resource locks of the target resources are successfully acquired, and return a lock holding certificate to the client that sent the first service request, wherein the lock holding certificate contains the lock identifier.

[0035] The return module is configured to release the resource lock of any target resource and return a lock conflict exception to the client if the acquisition of the resource lock of any target resource fails.

[0036] In one possible implementation, the determining module is further configured to determine whether the current time exceeds the timeout period of the first service request and whether the number of retries reaches a preset threshold.

[0037] The request module is further configured to, if the current time has not exceeded the timeout period and the number of retries has not reached a preset threshold, re-request the allocation of resource locks for the at least one target resource for the first service request after a first preset time.

[0038] In one possible implementation, the sending module is further configured to delete the record of the lock identifier in the distributed queue and send a lock allocation timeout prompt to the client if the current time exceeds the timeout period or the number of retries reaches a preset threshold.

[0039] In one possible implementation, the determining module is further configured to, if the sequence number of the first service request is not at the head of the distributed queue corresponding to each of the at least one target resource, then after a second preset time, re-determine whether the sequence number of the first service request is at the head of the distributed queue corresponding to each of the at least one target resource, until the sequence number of the first service request is at the head of the distributed queue corresponding to each of the at least one target resource, or the current time exceeds the timeout period of the first service request.

[0040] In one possible implementation, the service request processing device further includes: a deletion module;

[0041] The receiving module is further configured to receive a lock release instruction from the first service request, wherein the lock release instruction includes the at least one target resource and the lock holding certificate;

[0042] The determining module is further configured to determine whether the lock identifier and the identity identifier match the lock holding certificate;

[0043] The deletion module is further configured to delete the lock record and the sequence number record in the distributed queue if both the lock identifier and the identity identifier match the lock holding certificate.

[0044] The return module is also configured to return a lock release exception to the client if the lock identifier of any target resource does not match the sequence number.

[0045] Thirdly, this application provides a service request processing device, comprising:

[0046] Memory;

[0047] processor;

[0048] The memory stores computer-executed instructions;

[0049] The processor executes computer execution instructions stored in the memory to implement the service request processing method as described in the first aspect and various possible implementations of the first aspect.

[0050] Fourthly, this application provides a computer storage medium storing computer execution instructions, which, when executed by a processor, are used to implement the processing method for the business request described in the first aspect and various possible implementations of the first aspect.

[0051] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the first aspect and / or various possible implementations of the first aspect.

[0052] The business request processing method provided in this application generates a unique lock identifier containing a global sequence number for each business request and synchronously adds it to the distributed queue corresponding to each target resource. By utilizing the first-in-first-out characteristic of the queue, it ensures that all requests are queued in the same order on each resource, thereby forcing a globally unified locking sequence. This mechanism fundamentally avoids deadlock problems caused by multiple transactions requesting multiple resource locks in different orders, improving the robustness of the system. At the same time, all locks can only be acquired when the request is at the head of all relevant resource queues, ensuring the atomicity and coordination of resource allocation, effectively preventing resource hanging or contention caused by partial locking, improving system throughput and response efficiency in high-concurrency scenarios, and enhancing the stability, predictability, and overall reliability of business processing in a distributed environment. Attached Figure Description

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

[0054] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0055] Figure 1 This is a schematic diagram of the hardware environment for the interaction method of the smart device provided in this application;

[0056] Figure 2 This application provides a flowchart of the business request processing method. Figure 1 ;

[0057] Figure 3 This application provides a flowchart of the business request processing method. Figure 2 ;

[0058] Figure 4 This is a schematic diagram of the structure of the service request processing device provided in this application;

[0059] Figure 5 This is a schematic diagram of the structure of the service request processing device provided in this application. Detailed Implementation

[0060] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0061] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0062] Figure 1 This is a schematic diagram of the hardware environment for the interaction method of the smart device provided in this application. This smart home device interaction method is widely used in whole-house intelligent digital control application scenarios such as smart homes, smart home ecosystems, and intelligence house ecosystems. Optionally, in this embodiment, the above-mentioned smart home device interaction method can be applied to, for example... Figure 1 The hardware environment shown consists of terminal device 102 and server 104. For example... Figure 1As shown, server 104 is connected to terminal device 102 via a network and can be used to provide services (such as application services) to the terminal or clients installed on the terminal. A database can be set up on the server or independently of the server to provide data storage services for server 104. Cloud computing and / or edge computing services can be configured on the server or independently of the server to provide data processing services for server 104.

[0063] The aforementioned network may include, but is not limited to, at least one of the following: wired network, wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network, metropolitan area network, local area network. The aforementioned wireless network may include, but is not limited to, at least one of the following: Wi-Fi (Wireless Fidelity), Bluetooth. The terminal device 102 may not be limited to PC, mobile phone, tablet computer, smart air conditioner, smart range hood, smart refrigerator, smart oven, smart stove, smart washing machine, smart water heater, smart washing equipment, smart dishwasher, smart projector, smart TV, smart clothes rack, smart curtains, smart audio-visual equipment, smart socket, smart speaker, smart speaker box, smart fresh air equipment, smart kitchen and bathroom equipment, smart bathroom equipment, smart robot vacuum cleaner, smart window cleaning robot, smart mopping robot, smart air purifier, smart steam oven, smart microwave oven, smart water heater, smart air purifier, smart water dispenser, smart door lock, etc.

[0064] With the rapid development of internet technology, distributed system architecture has become the mainstream choice for enterprise applications. In this type of architecture, multiple service instances run in parallel, requiring coordinated access control of shared resources to avoid data contention and inconsistency issues. Especially in high-concurrency scenarios, ensuring the order of resource access and data consistency is crucial.

[0065] In existing technologies, the processing of business requests typically relies on the locking mechanism of relational databases to achieve concurrency control. Specifically, when a business request triggers a database transaction, the database system determines the scope of data involved based on the transaction isolation level and operation type, and automatically requests locks of appropriate granularity. If the target resource is already locked by another transaction, the current request will be blocked and enter a waiting queue; after the transaction holding the lock completes (commits or rolls back), the database releases the relevant lock resources, and the waiting transactions acquire locks in sequence and continue execution, thereby achieving secure access to shared resources.

[0066] However, this mechanism has significant drawbacks in scenarios involving concurrent operations on multiple resources. When multiple transactions need to access a set of shared resources simultaneously, if each transaction acquires locks in a different order, a circular wait may occur: that is, transaction A holds a lock on resource X and waits for a lock on resource Y, while transaction B holds a lock on resource Y and waits for a lock on resource X. In this situation, neither transaction can proceed, resulting in a deadlock. Although database systems typically have deadlock detection and timeout rollback mechanisms, frequent deadlocks reduce system throughput, increase response latency, and impact business continuity.

[0067] To address the aforementioned issues, the business request processing method provided in this application generates a unique lock identifier for a first business request containing multiple target resources. This lock identifier embeds a sequence number reflecting the arrival time of the request. Subsequently, the lock identifier is simultaneously added to the distributed queues corresponding to each target resource. Utilizing the first-in, first-out (FIFO) characteristic of queues, the request is deemed eligible to acquire all resource locks only when the lock identifier is at the head of the queue for each target resource. This mechanism forces all business requests to follow the same locking order across all resources, fundamentally eliminating the risk of deadlocks caused by inconsistent locking orders. It achieves atomic lock coordination across multiple resources, thereby improving the stability of business processing and the overall reliability of the system in complex, high-concurrency, distributed environments.

[0068] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0069] Figure 2 This application provides a flowchart of the business request processing method. Figure 1 The execution entity in this embodiment is, for example, a business request processing system. Figure 2 As shown, the service request processing method provided in this embodiment includes:

[0070] S201: Receive a first service request, the first service request containing at least one target resource.

[0071] The target resource is the specific object that needs to be operated or controlled, as clearly defined in the first business request, such as equipment, data, and services.

[0072] Receive operation instructions (i.e., the first business request) initiated by users or downstream systems, and parse the specific object information to be operated (such as device ID and resource identifier) ​​from the request parameters and data messages of the operation instructions to determine at least one target resource that the request needs to be associated with.

[0073] For example, a user sends a "home mode" activation command (the first business request) to the smart home control system (i.e., the business request processing system) via a mobile app. This command includes the target resources: "living room main light, entryway curtains, and master bedroom air conditioner." After receiving the "home mode" activation command, the smart home control system first extracts these three target resources: "living room main light, entryway curtains, and master bedroom air conditioner."

[0074] S202: Generate a lock identifier for the first service request, the lock identifier including a sequence number used to identify the receiving order of the first service request.

[0075] The sequence number identifies the order in which requests are received, ensuring that the system processes requests according to the "first come, first served" rule and preventing later requests from jumping the queue and causing resource contention conflicts.

[0076] Specifically, after receiving the first business request, the system generates a sequence number containing a timestamp, node identifier, and auto-incrementing sequence through a distributed generator.

[0077] For example, when a user sends a "home mode" activation command (i.e., the first service request) via a mobile app, and this command includes three target resources: "living room main light, entryway curtains, and master bedroom air conditioner," the smart home control system will generate a lock identifier for this request. Specifically, the system generates a globally unique sequence number (e.g., "SEQ_20250615183001_001," where "20230615183001" is the reception time accurate to the second, and "001" is the first request within that second, used to identify the reception order).

[0078] S203: Add the lock identifier of the first business request to the distributed queue corresponding to at least one target resource.

[0079] Specifically, an association is established between the first business request and the target resource to ensure the order and security of operations in multi-resource concurrent scenarios. By maintaining a separate queue for each target resource, all requests for the target resource are queued according to the sequence number in the lock identifier, avoiding unordered contention for the same resource by different requests.

[0080] For example, when the smart home control system generates a lock identifier (such as containing the serial number "SEQ_20250615183001_001") for the "Home Mode" linkage command, it adds this lock identifier to the distributed queues corresponding to the three target resources: In the "Living Room Main Light Resource Queue," the lock identifier is ordered by serial number after the previously received "SEQ_20250615182959_001" (such as the request to turn off the living room light in "Away Mode"); in the "Entrance Curtain Resource Queue," since there are no other unprocessed requests, the lock identifier directly becomes the head of the queue; in the "Master Bedroom Air Conditioner Resource Queue," it is ordered after "SEQ_20250615183000_001" (such as the separate command to turn on the air conditioner in advance). In this way, each target resource's queue separately records the order of all requests involving it.

[0081] S204: If the lock identifier of the first service request is at the head of the distributed queue corresponding to at least one target resource, request to allocate resource locks for at least one target resource for the first service request.

[0082] Resource locks are a synchronization control mechanism used in distributed systems to control access permissions of multiple requests to the same target resource (such as devices, data, or services), preventing disorderly contention from causing operational conflicts or data inconsistencies.

[0083] Specifically, only when a request is at the front of all queues involving resources can it be proven that no other requests are occupying or waiting for these resources, and only then can the resource lock lock all target resources at once.

[0084] For example, after the lock identifier (serial number: SEQ_20250615183001_001) of the "Home Mode" linkage command has been waiting in each resource queue, if the previous request "SEQ_20250615182959_001" in the "Living Room Main Light Resource Queue" has been processed and the lock identifier has risen to the head of the queue, and the request "SEQ_20250615183000_001" in the "Master Bedroom Air Conditioner Resource Queue" has also been executed and the lock identifier has also become the head of the queue, and it always maintains the head position in the "Entrance Curtain Resource Queue", at this time the smart home control system will determine that the lock identifier is at the head of the distributed queues of the three target resources, and then request the system to allocate resource locks for the living room main light, entrance curtains, and master bedroom air conditioner respectively for the "Home Mode" command, so as to ensure that the three devices can synchronously perform the linkage operation of "open", "pull open" and "start" without conflict.

[0085] The service request processing method provided in this embodiment receives a first service request, which includes at least one target resource. A lock identifier is generated for the first service request, including a sequence number that identifies the receiving order of the first service request. The lock identifier of the first service request is added to the distributed queues corresponding to each of the at least one target resource. If the lock identifier of the first service request is at the head of all the distributed queues corresponding to the at least one target resource, a request is made to allocate resource locks for the at least one target resource to the first service request. This method ensures consistent locking order for multiple resources by generating a unified lock identifier containing a sequence number for the service request and coordinating resource locks based on distributed queues, thereby effectively avoiding deadlocks and improving the stability and reliability of service processing in high-concurrency scenarios.

[0086] Figure 3 This application provides a flowchart of the business request processing method. Figure 2 .like Figure 3 As shown, in this embodiment... Figure 2 Based on the embodiments, the method for processing business requests is described in detail, including:

[0087] S301: Receive a first service request, the first service request containing at least one target resource.

[0088] Step S301 is similar to step S201, and will not be described again here.

[0089] S302: Generate a lock identifier for the first service request, the lock identifier including a sequence number used to identify the receiving order of the first service request.

[0090] Step S302 is similar to step S202, and will not be described again here.

[0091] S303: Add the lock identifier of the first business request to the distributed queue corresponding to at least one target resource.

[0092] Step S303 is similar to step S203, and will not be described again here.

[0093] S304: If the lock identifier of the first service request is at the head of the distributed queue corresponding to at least one target resource, the request is made to allocate resource locks for at least one target resource for the first service request.

[0094] Step S304 is similar to step S204, and will not be described again here.

[0095] S305: If the sequence number of the first service request is not at the head in the distributed queue corresponding to at least one target resource, then after a second preset time, it is re-determined whether the sequence number of the first service request is at the head in the distributed queue corresponding to at least one target resource, until the sequence number of the first service request is at the head in the distributed queue corresponding to at least one target resource, or the current time exceeds the timeout period of the first service request.

[0096] Specifically, when the sequence number of the first business request is not fully in the header, it indicates that some target resources are still occupied by previous requests. Directly requesting resource locks at this time will lead to conflicts. However, by using interval retry detection, processing time can be given to previous requests, and the queue status changes can be tracked in real time to avoid consuming too many system resources due to continuous polling. At the same time, timeout limits prevent a single request from waiting indefinitely and occupying resources, ensuring the smoothness of the overall system process.

[0097] For example, if the lock identifier (serial number: SEQ_20250615183001_001) of the "Home Mode" linkage command is still ranked after "SEQ_20250615182959_001" in the "Living Room Main Light Resource Queue" and after "SEQ_20250615183000_001" in the "Master Bedroom Air Conditioner Resource Queue" in the initial state (i.e., it is not ranked at the head), the smart home control system will recheck the position of each queue after a second preset time interval (e.g., 5 seconds). If the previous request in the "Living Room Main Light Resource Queue" has been processed but the "Master Bedroom Air Conditioner Resource Queue" has not yet been reached during the first retry, the system will continue to wait for 5 seconds and check again. This cycle continues until the serial number is ranked at the head of all three resource queues (at which point a resource lock is requested), or if the conditions are not met after more than 30 seconds (timeout period) since the command was initiated, the retry will be terminated and the user will be notified that "command execution timed out".

[0098] S306: Determine whether the resource lock for each target resource has been successfully acquired.

[0099] Specifically, after requesting the allocation of a resource lock for the target resource in the first business request, the system checks the lock status of each target resource one by one through a distributed lock service (such as the RedLock mechanism based on Redis): it sends a query request containing the lock identifier to the lock service to verify whether the current lock identifier is consistent with the holder identifier of the target resource; if all target resources return confirmation information that "the lock has been allocated and the holder is the current lock identifier", it is determined that all resource locks have been successfully acquired; if any target resource returns the result of "the lock is held by another identifier" or "the lock has not been allocated", it is determined that the acquisition has failed, and the identifier of the failed resource and the reason are recorded.

[0100] For example, after the smart home control system requests the allocation of resource locks for the living room main light, entryway curtains, and master bedroom air conditioner for the "Home Mode" command (lock identifier includes serial number "SEQ_20250615183001_001"), it will verify each lock status one by one through the system's built-in lock status query module: First, it sends a query request to the lock management unit of the living room main light to confirm whether the identifier currently holding the resource lock for that light is "SEQ_20250615183001_001", and receives a "successful holding" feedback; then it queries the lock status of the entryway curtains, which is also verified; finally, it checks the lock identifier holding status of the master bedroom air conditioner, and after confirming that there are no other requests occupying it, the system combines the results of the three queries and determines that it has successfully acquired all the resource locks of the three target resources, and then triggers the subsequent device linkage execution command.

[0101] S307: If all target resource locks are successfully acquired, a lock record corresponding to the first service request is generated, and a lock holding certificate is returned to the client that sent the first service request. The lock holding certificate contains a lock identifier.

[0102] Specifically, after confirming successful acquisition of resource locks for all target resources, the system initiates a lock record generation process: First, it extracts key information such as lock identifier, target resource list, request initiation time, and lock validity period from the metadata of the first business request. This information is then combined into a structured lock record according to a preset data format (such as JSON format) and stored in a distributed database (such as a MySQL cluster) or a high-availability cache (such as Redis). Simultaneously, an expiration time consistent with the lock validity period is set for the lock record. Subsequently, the system generates a lock holding credential containing the lock identifier, lock validity period, and a unique request ID. This credential is then fed back to the client that sent the request through the response channel of the original business request (such as an HTTP / HTTPS interface or an MQ message queue), ensuring that the client can use this credential to prove its lock holding rights for the target resources in subsequent operations.

[0103] For example, once the smart home control system confirms that it has successfully acquired all the resource locks for the living room main light, the entryway curtains, and the master bedroom air conditioner, it will immediately generate a lock record corresponding to the "Home Mode" command. This record includes the lock identifier (including the serial number "SEQ_20250615183001_001"), the device IDs of the three target resources, the lock acquisition time (e.g., "2025-06-15 18:30:08"), and the lock validity period (e.g., 10 minutes), and stores the record in the system's lock management database. At the same time, the system will return a lock holding certificate to the client that sent the "Home Mode" command through the communication interface of the mobile APP. The lock holding certificate is presented in JSON format and includes the lock identifier "SEQ_20250615183001_001", the certificate's effective time, and the validity period.

[0104] S308: Receive the lock release instruction of the first service request. The lock release instruction includes at least one target resource and a lock holding certificate.

[0105] Lock release refers to the process by which a business request holding a resource lock, after completing its operation, releases the occupancy of the target resource by submitting an instruction containing the lock holding certificate and the target resource, making the resource available for use by other requests. The lock identifier includes an identity identifier.

[0106] For example, after all the device operations corresponding to the "Home Mode" linkage command (turning on the main living room light, opening the entryway curtains, and starting the master bedroom air conditioner) have been executed, the user can click the "Confirm Release Resource" button through the mobile APP to trigger the lock release command. This command will be transmitted through the communication link (such as HTTPS protocol) between the APP and the smart home control system. It contains the identifiers of the three target resources: "main living room light (device ID: L001), entryway curtains (device ID: C001), and master bedroom air conditioner (device ID: A001)," as well as the lock holding certificate previously returned by the system (including the lock identifier "SEQ_20250615183001_001" and the certificate effective time "2025-06-15 18:30:08"). After receiving the command, the lock management module of the smart home control system first checks the integrity of the resource identifiers and lock holding certificate in the command and preliminarily confirms that it meets the format requirements of the lock release command.

[0107] S309: Determine whether the lock identifier and identity identifier match the lock holding certificate.

[0108] Specifically, after receiving a lock release command, the system extracts the lock identifier and the requester's identity identifier from the lock holding credential. At the same time, it queries the distributed database for the lock record corresponding to the lock identifier to obtain the original lock identifier and the bound identity information stored in the record. Subsequently, it uses a preset comparison algorithm (such as exact string matching or cryptographic hash value comparison) to verify whether the lock identifier in the credential matches the original lock identifier in the record, and whether the identity identifier carried by the credential matches the identity information bound to the lock record.

[0109] For example, after receiving a lock release command from the "Home Mode" instruction, the smart home control system first extracts the lock identifier "SEQ_20250615183001_001" and the requester's identity identifier (such as the device ID "DEV_89AB" from the lock holding certificate carried in the command). Then, it retrieves the lock record corresponding to the "Home Mode" instruction from the lock management database, obtaining the original lock identifier "SEQ_20250615183001_001" and the bound identity identifier "DEV_89AB" stored in the record. Subsequently, the system confirms through precise string comparison that the lock identifier in the certificate is completely consistent with the original lock identifier in the record, and that the device ID carried in the certificate also completely matches the identity identifier bound to the lock record. Finally, it determines that the lock identifier and identity identifier match the lock holding certificate, confirming that the current requester has the right to release the resource locks of the living room main light, the entryway curtains, and the master bedroom air conditioner.

[0110] S310: If both the lock identifier and the identity identifier match the lock holding certificate, then delete the lock record and the sequence number record in the distributed queue.

[0111] Specifically, when both the lock identifier and the identity identifier match the lock holding credential, the system initiates a dual cleanup process: First, it locates and deletes the complete lock record (containing information such as the resource list and expiration date) corresponding to the lock identifier from the distributed database (such as a MySQL cluster); simultaneously, it sends a deletion command to the distributed queue (such as a List structure based on Redis) corresponding to each target resource, removing the record with that sequence number from the queue and releasing the queue position; the operation uses a transaction mechanism to ensure atomicity, and if any step fails, a rollback is triggered to ensure that the lock record and queue record are either deleted simultaneously or remain unchanged, avoiding data residue or inconsistency, and finally completing the complete release of the resource lock.

[0112] For example, once the smart home control system confirms that the lock identifier "SEQ_20250615183001_001" and the user identity identifier completely match the lock holding certificate, it will perform a double deletion operation: on the one hand, it will permanently delete the lock record corresponding to the "Home Mode" instruction (containing information such as the three target resource IDs and the lock acquisition time) from the lock management database; on the other hand, it will send removal instructions to the "Living Room Main Light Resource Queue", "Entrance Hall Curtain Resource Queue", and "Master Bedroom Air Conditioner Resource Queue" respectively, deleting the record with the sequence number "SEQ_20250615183001_001" in the queue. The entire process ensures synchronization through a transaction mechanism, ensuring that the lock record and the queue record are cleared at the same time, so that the three resources are completely released, and subsequent requests can enter the queue in sequence to wait for processing.

[0113] S311: If the lock identifier and sequence number of any target resource do not match, return a lock release exception to the client.

[0114] Specifically, when processing a lock release command, the system will traverse all target resources and compare the currently registered lock identifier of each resource with the sequence number carried in the command. If the lock identifier and sequence number of at least one target resource are found to be inconsistent, the subsequent operation will be terminated immediately, and a lock release exception information will be returned to the client in a preset response format.

[0115] For example, when a user initiates a lock release operation via a mobile app using the "Home Mode" command, with the serial number "SEQ_20250615183001_001" in the command, and requests to release the resource locks of the living room main light, entryway curtains, and master bedroom air conditioner, the smart home control system will check the currently registered lock identifiers of the three target resources one by one. If the check finds that the lock identifiers of the living room main light and entryway curtains are both "SEQ_20250615183001_001", but the current lock identifier of the master bedroom air conditioner has changed to "SEQ_20250615183001_002" due to temporary system scheduling (which does not match the serial number in the command), the system will immediately terminate the lock release process, return a lock release error message to the user via the app, including the error reason "the current lock identifier of the master bedroom air conditioner does not match the requested serial number" and the abnormal resource identifier, and record the error information in the system log.

[0116] S312: If the acquisition of the resource lock for any target resource fails, the resource lock for the target resource is released, and a lock conflict exception is returned to the client.

[0117] Specifically, during the process of allocating resource locks for target resources for the first business request, if the system detects that the acquisition of any target resource lock has failed (e.g., the resource has been occupied by another lock identifier), it will immediately trigger a rollback mechanism: the distributed transaction coordinator will send lock release instructions to all target resources that have successfully acquired resource locks, clearing the lock identifiers and corresponding holding records on these resources; after confirming that all acquired resource locks have been released, the system will generate lock conflict exception information containing the failed resource identifier and the reason for the conflict, and feed it back to the client that initiated the request according to the preset response protocol, ensuring that the resource state is restored to consistency and that the client can be aware of the conflict situation in a timely manner.

[0118] For example, when the "Homecoming Mode" linkage command (lock identifier "SEQ_20250615183001_001") requests the allocation of resource locks for the living room main light, entryway curtains, and master bedroom air conditioner, if the system successfully acquires the resource locks for the living room main light and entryway curtains, but fails to acquire the master bedroom air conditioner resource lock due to it being occupied by a sudden emergency command (lock identifier "SEQ_20250615183001_002"), the smart home control system will immediately trigger a rollback mechanism. This will release the acquired resource locks for the living room main light and entryway curtains, clear the lock identifier records on these two devices, and then return a lock conflict exception message to the user via the mobile app, stating that "the master bedroom air conditioner resource is occupied by another command, and Homecoming Mode failed to start," and suggesting that the user try again later.

[0119] S313: Determine whether the current time exceeds the timeout period of the first business request and whether the number of retries has reached the preset threshold.

[0120] Specifically, on the one hand, a timestamp comparison mechanism is used to calculate the difference between the current system time and the initial time recorded when the business request was initiated, to determine whether the preset timeout period (such as 30 seconds) has been exceeded; on the other hand, a counter is used to record the number of request retries and compare it with the preset threshold configured by the system (such as 5 times).

[0121] For example, when a smart home control system processes a "home mode" linkage command (lock identifier "SEQ_20250615183001_001") to acquire a resource lock, the system first compares the current time (e.g., 2025-06-15 18:30:31) with the command initiation time (2025-06-15 18:30:01), calculates that 30 seconds have elapsed, and determines whether the preset 30-second timeout period has been exceeded. At the same time, it checks the number of retries made for acquiring the resource lock (e.g., the 5th time) and compares it with the system's set threshold of 5 retries.

[0122] S314: If the current time has not exceeded the timeout period and the number of retries has not reached the preset threshold, then after the first preset time, a new request is made to allocate at least one resource lock for each of the target resources for the first service request.

[0123] Specifically, after determining that the current time of the first business request has not exceeded the preset timeout and the number of retries has not reached the threshold, the system will start a timed retry mechanism: starting from the current time, a countdown timer is set according to the first preset time. After the countdown ends, the resource lock reallocation process is automatically triggered, that is, the lock request is sent to the lock management unit of each target resource using the original lock identifier, and the local retry counter (number of times + 1) and request timestamp (updated to the current time) are updated synchronously to ensure that each retry carries the latest status information; at the same time, the connection with the client is maintained and no result is returned until the lock is successfully acquired, the timeout occurs, or the number of retries is exhausted.

[0124] For example, when the "Home Mode" linkage command (lock identifier "SEQ_20250615183001_001") requests the allocation of resource locks for the first time, if the request fails due to the temporary occupation of the master bedroom air conditioner resource, the system will check the current time (e.g., 10 seconds, not exceeding the 30-second timeout period) and the number of retries (e.g., 1 time, not reaching the 5-time preset threshold). Then, a timed mechanism will be started, and the retry process will be automatically triggered after the first preset time (e.g., 2 seconds): the lock allocation request will be resent to the resource management modules of the living room main light, the entrance curtain, and the master bedroom air conditioner using the original lock identifier. The number of retries will be updated to 2 and the current timestamp will be recorded to ensure that retries are carried out in an orderly manner at intervals before the timeout, until all resource locks are successfully acquired or the termination condition is triggered.

[0125] S315: If the current time exceeds the timeout period or the number of retries reaches the preset threshold, delete the lock identifier record in the distributed queue and send a lock allocation timeout prompt to the client.

[0126] Specifically, when the system determines that the current time of the first business request has exceeded the preset timeout period, or the number of retries has reached the set threshold, it will initiate the termination process: First, a deletion command is sent to the distributed queue corresponding to each target resource to accurately remove the lock identifier record of the business request from the queue and release the queue position; then, a lock allocation timeout prompt containing the timeout reason is generated and fed back to the client through the original communication link; at the same time, the termination time, lock identifier and termination reason are recorded in the system log.

[0127] For example, if the "Home Mode" linkage command (lock identifier "SEQ_20250615183001_001") fails to acquire a resource lock after multiple retries (e.g., reaching a preset threshold of 5 times), or if the timeout period from the command initiation time (18:30:01) to the current time (18:30:32) exceeds 30 seconds, the smart home control system will perform a cleanup and notification operation: send removal commands to the "Living Room Main Light Resource Queue," "Entrance Hall Curtain Resource Queue," and "Master Bedroom Air Conditioner Resource Queue" respectively, delete the record of the lock identifier in the queue, and release the queue position; at the same time, push a lock allocation timeout prompt to the user through the mobile APP, with the content "Home Mode startup timeout, please try again later," and record the timeout details in the system background (including the termination reason, lock identifier, and cleanup results of each queue).

[0128] The service request processing method provided in this embodiment receives a first service request containing at least one target resource, generates a lock identifier containing a sequence number indicating the receiving order, and adds the lock identifier to the distributed queue corresponding to each target resource. If the lock identifier is first in all queues, a request is made to allocate resource locks for each target resource. If there is a case where the lock identifier is not first in the queue, the request is rechecked after a second preset time until all locks are first in the queue or a timeout occurs. Then, it is determined whether all resource locks have been successfully acquired. If all are successful, a corresponding lock record is generated and a lock holding certificate containing the lock identifier is returned to the client. Afterward, a lock release command containing the target resource and the lock holding certificate is received, and the lock identifier, identity identifier, and certificate are verified to match. If they all match, the lock record and the record with the sequence number in the queue are deleted. If there is a lock release command, the lock release command is not executed. If the lock identifier and sequence number of any target resource do not match, a lock release exception is returned. If acquiring a resource lock fails for any target resource, the acquired resource lock is released and a lock conflict exception is returned. Simultaneously, the system monitors whether the current time has exceeded the timeout period and whether the number of retries has reached the threshold. If neither has been reached, the system re-requests the allocation of the resource lock after a first preset time. If a timeout or the number of retries exceeds the limit, the lock identifier record in the queue is deleted and a lock allocation timeout prompt is sent. This method achieves global consistency of the locking order of multiple resources by introducing ordered lock identifiers, distributed queue coordination, and retry timeout control mechanisms, effectively avoiding deadlocks. Furthermore, it ensures the security and reliability of resource operations through lock holding certificate verification and atomic release, thereby improving the stability and fault tolerance of business request processing in a high-concurrency distributed environment.

[0129] Figure 4 This is a schematic diagram of the structure of the service request processing device provided in this application. For example... Figure 4 As shown, this application provides a service request processing apparatus 400, which includes:

[0130] Receiving module 401 is used to receive a first service request, the first service request containing at least one target resource;

[0131] The generation module 402 is used to generate a lock identifier for the first service request, wherein the lock identifier includes a sequence number used to identify the receiving order of the first service request;

[0132] Processing module 403 is used to add the lock identifier of the first business request to at least one distributed queue corresponding to each of the target resources;

[0133] Request module 404 is used to request the allocation of resource locks for at least one target resource for the first business request, provided that the lock identifier of the first business request is at the head of the distributed queue corresponding to at least one target resource.

[0134] In one possible implementation, the service request processing apparatus further includes: a determining module 405, a sending module 406, and a returning module 407;

[0135] The determination module 405 is used to determine whether the resource lock for each target resource has been successfully acquired;

[0136] The sending module 406 is used to generate a lock record corresponding to the first business request if all target resource locks are successfully acquired, and return a lock holding certificate to the client that sent the first business request. The lock holding certificate contains a lock identifier.

[0137] Return module 407 is used to release the resource lock of the target resource and return a lock conflict exception to the client if the acquisition of the resource lock of any target resource fails.

[0138] In one possible implementation, the determining module 405 is further configured to determine whether the current time exceeds the timeout period of the first service request and whether the number of retries reaches a preset threshold.

[0139] The request module 404 is also configured to, if the current time has not exceeded the timeout period and the number of retries has not reached the preset threshold, re-request the allocation of at least one resource lock for each of the target resources for the first business request after the first preset time.

[0140] In one possible implementation, the sending module 406 is further configured to delete the lock identifier record in the distributed queue and send a lock allocation timeout prompt to the client if the current time exceeds the timeout period or the number of retries reaches a preset threshold.

[0141] In one possible implementation, the determining module 405 is further configured to, if the sequence number of the first service request is not at the head in the distributed queue corresponding to at least one target resource, then after a second preset time, re-determine whether the sequence number of the first service request is at the head in the distributed queue corresponding to at least one target resource, until the sequence number of the first service request is at the head in the distributed queue corresponding to at least one target resource, or the current time exceeds the timeout period of the first service request.

[0142] In one possible implementation, the service request processing device further includes: a deletion module 408;

[0143] The receiving module 401 is also used to receive a lock release instruction from the first service request, wherein the lock release instruction includes at least one target resource and a lock holding certificate;

[0144] The determination module 405 is also used to determine whether the lock identifier and identity identifier match the lock holding certificate;

[0145] The deletion module 408 is also used to delete the lock record and the sequence number record in the distributed queue if both the lock identifier and the identity identifier match the lock holding certificate.

[0146] Return module 407 is also used to return a lock release exception to the client if the lock identifier and sequence number of any target resource do not match.

[0147] The business recommendation device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0148] Figure 5 This is a schematic diagram of the structure of the service request processing device provided in this application. For example... Figure 5 As shown, this application provides a service request processing device 500, which includes: a receiver 501, a transmitter 502, a processor 503, and a memory 504.

[0149] Receiver 501 is used to receive instructions and data;

[0150] Transmitter 502 is used to send commands and data;

[0151] Memory 504 is used to store instructions executed by the computer;

[0152] The processor 503 is used to execute computer execution instructions stored in the memory 504 to implement the various steps of the service request processing method in the above embodiments. For details, please refer to the relevant descriptions in the foregoing embodiments of the service request processing method.

[0153] Alternatively, the memory 504 can be either standalone or integrated with the processor 503.

[0154] When the memory 504 is set up independently, the electronic device also includes a bus for connecting the memory 504 and the processor 503.

[0155] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the processing method of the service request executed by the processing device for the aforementioned service request.

[0156] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in any of the foregoing embodiments.

[0157] The above are merely preferred embodiments of this application. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for processing business requests, characterized in that, include: Receive a first service request, wherein the first service request contains at least one target resource; Generate a lock identifier for the first service request, the lock identifier including a sequence number used to identify the receiving order of the first service request; Add the lock identifier of the first service request to the distributed queue corresponding to each of the at least one target resource; If the lock identifier of the first service request is at the head of the distributed queue corresponding to each of the at least one target resource, the request is made to allocate the resource lock of each of the at least one target resource to the first service request.

2. The method according to claim 1, characterized in that, After the request allocates resource locks for each of the at least one target resource for the first service request, it further includes: Determine whether the resource lock for each target resource has been successfully acquired; If all target resource locks are successfully acquired, a lock record corresponding to the first service request is generated, and a lock holding certificate is returned to the client that sent the first service request. The lock holding certificate contains the lock identifier. If the acquisition of the resource lock for any target resource fails, the resource lock for the target resource is released, and a lock conflict exception is returned to the client.

3. The method according to claim 2, characterized in that, After returning a lock conflict exception to the first service request, the process also includes: Determine whether the current time exceeds the timeout period of the first service request and whether the number of retries has reached a preset threshold; If the current time has not exceeded the timeout period and the number of retries has not reached the preset threshold, then after the first preset time, a new request is made to allocate resource locks for each of the at least one target resource for the first service request.

4. The method according to claim 3, characterized in that, The method further includes: If the current time exceeds the timeout period or the number of retries reaches a preset threshold, the lock identifier record in the distributed queue is deleted, and a lock allocation timeout notification is sent to the client.

5. The method according to claim 1, characterized in that, The method further includes: If the sequence number of the first service request is not at the head of the distributed queue corresponding to each of the at least one target resource, then after a second preset time, it is re-determined whether the sequence number of the first service request is at the head of the distributed queue corresponding to each of the at least one target resource, until the sequence number of the first service request is at the head of the distributed queue corresponding to each of the at least one target resource, or the current time exceeds the timeout period of the first service request.

6. The method according to claim 2, characterized in that, The lock identifier includes an identity identifier. After requesting the first service to return the lock holding certificate, the process further includes: Receive a lock release instruction from the first service request, wherein the lock release instruction includes the at least one target resource and the lock holding certificate; Determine whether the lock identifier and the identity identifier match the lock holding certificate; If both the lock identifier and the identity identifier match the lock holding certificate, then delete the lock record and the record of the sequence number in the distributed queue; If the lock identifier of any target resource does not match the sequence number, a lock release exception is returned to the client.

7. A service request processing apparatus, characterized in that, include: A receiving module is configured to receive a first service request, wherein the first service request contains at least one target resource; A generation module is used to generate a lock identifier for the first service request, wherein the lock identifier includes a sequence number used to identify the receiving order of the first service request; The processing module is used to add the lock identifier of the first business request to the distributed queue corresponding to each of the at least one target resource; The request module is configured to request the allocation of resource locks for the first service request for each of the at least one target resource, provided that the lock identifier of the first service request is at the head of the distributed queue corresponding to each of the at least one target resource.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored program, wherein the program, when executed, performs the method of any one of claims 1 to 6.

9. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method of any one of claims 1 to 6 through the computer program.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images