Resource access method, computer equipment and computer readable storage medium

Abstract

The invention discloses a resource access method based on a distributed lock, computer equipment and a computer readable storage medium. The method comprises the steps that under the condition that a current thread initiates an access request for a first target resource, first lock information corresponding to the current thread is opened, the first lock information is used for recording historical state information, obtained by the current thread, of a lock, and according to the first lock information, the access permission of the current thread for the first target resource is determined; under the condition that the access permission exists, the current thread obtains the first distributed lock and accesses the first target resource. Thus, it is ensured that only one thread can access the first target resource at the same time, the multiple threads on the multiple virtual machines can safely access and operate the first target resource, and therefore the concurrency problem is processed.

Description

Technical Field

[0001] The present application relates to the field of distributed systems, and more specifically, to a resource access method based on distributed locks, a computer device, and a computer-readable storage medium. Background Art

[0002] In the related art, with the rapid growth of application system users and access volume, the system architecture has been transformed from a monolithic architecture to a microservice architecture. A microservice architecture can usually include multiple services, and a service can usually include multiple threads. In the process of processing actual tasks under the microservice architecture, it may happen that multiple threads initiate access requests to the same resource in a short period of time. This can easily cause various concurrency problems such as data inconsistency and deadlock. Summary of the invention

[0003] The present application provides a resource access method based on a distributed lock, a computer device, and a computer-readable storage medium.

[0004] The present application embodiment provides a resource access method based on a distributed lock, the method comprising:

[0005] When the current thread initiates an access request to the first target resource, first lock information corresponding to the current thread is opened, where the first lock information is used to record historical status information of the lock acquired by the current thread;

[0006] The access rights of the current thread to the first target resource are determined according to the first lock information, so that the current thread acquires a first distributed lock and accesses the first target resource if the current thread has the access rights.

[0007] Thus, in this application, in order to handle the situation where multiple threads initiating access requests to the first target resource in a microservice structure across multiple virtual machines easily cause concurrency problems, the following processing is performed on one of the multiple threads accessing the first target resource. The first lock information corresponding to the current thread is opened. The first lock information is used to record the historical information of the current thread obtaining the lock, and then the access rights of the current thread to the first target resource are determined according to the first lock information. If the access rights are granted, the first distributed lock is obtained to access the first target resource. In this way, it is ensured that only one thread can access the first target resource at the same time, so that multiple threads on multiple virtual machines can safely access and operate the first target resource, thereby achieving the handling of concurrency problems.

[0008] In some implementations, determining, according to the first lock information, the access right of the current thread for the first target resource, so that the current thread acquires the first distributed lock and accesses the first target resource if the current thread has the access right, includes:

[0009] Confirming first historical acquisition status information of the first distributed lock of the current thread according to the first lock information;

[0010] In a case where the first historical acquisition state information exists, it is determined that the current thread has access rights to the first target resource.

[0011] In this way, the first historical acquisition status information of the first distributed lock of the current thread is confirmed according to the first lock information. If the current thread has acquired the first distributed lock and has not released the first distributed lock, the first historical acquisition status information exists in the first lock information. In the case of the existence of the first historical acquisition status information, it is determined that the current thread has access rights to the first target resource. After determining that the current thread has access rights to the first target resource, the current thread can directly access the first target resource, reduce the number of acquisitions of the first distributed lock, and improve the operating efficiency of the system.

[0012] In some implementations, determining, according to the first lock information, the access right of the current thread for the first target resource, so that the current thread acquires the first distributed lock and accesses the first target resource if the current thread has the access right, includes:

[0013] In the absence of the first historical acquisition status information, performing value writing processing on the first distributed lock;

[0014] In a case where a value can be written to the first distributed lock, it is determined that the current thread has access rights to the first target resource.

[0015] In this way, in the absence of the first historical acquisition status information, in order to enable the current thread to have access to the first target resource, the first distributed lock is processed for value writing. In the case where the value can be written to the first distributed lock, it is determined that the current thread has access to the first target resource. In this way, the value writing process is successful, and the current thread can obtain the first distributed lock to access the first target resource, ensuring that only the thread that has obtained the first distributed lock can access the first target resource, avoiding concurrency problems such as data inconsistency caused by multiple threads accessing the same public resource.

[0016] In some embodiments, the resource access method further includes:

[0017] When the value writing to the first distributed lock is successful, the acquisition status information of the first distributed lock acquired by the current thread is written into the first lock information.

[0018] In this way, when the value of the first distributed lock is written successfully, the acquisition status information of the first distributed lock acquired by the current thread is written into the first lock information. In this way, the acquisition status information of the first distributed lock is recorded in the first lock information, so that when the current thread needs to access the first target resource in the subsequent operation, the first target resource can be directly accessed by querying the first lock information.

[0019] In some implementations, determining, according to the first lock information, the access right of the current thread for the first target resource, so that the current thread acquires the first distributed lock and accesses the first target resource if the current thread has the access right, includes:

[0020] In the case where writing a value to the first distributed lock fails, determining that the current thread does not have access rights to the first target resource;

[0021] The access request of the current thread to the first target resource is rejected, and the current thread is stopped.

[0022] In this way, the value writing to the first distributed lock fails, which means that the first distributed lock has been acquired by other threads and the first distributed lock has not been released, and it is determined that the current thread does not have access rights to the first target resource. In the case that the current thread does not have an access request to the first target resource, that is, the current thread cannot obtain the first distributed lock, the access request of the current thread to the first target resource is rejected, and the current thread is stopped. This ensures that only one thread that has acquired the first distributed lock can access the first target resource protected by the first distributed lock at the same time, thereby avoiding problems such as data inconsistency and deadlock.

[0023] In some embodiments, the resource access method further includes:

[0024] When the current thread is finished running, the first distributed lock is released.

[0025] In this way, when the current thread is finished running, the first distributed lock is released, so that the first distributed lock can be released in time, that is, other threads can obtain the first distributed lock in time to access the first target resource, thereby avoiding the occurrence of deadlock, effectively managing system resources, and improving system performance.

[0026] In some embodiments, the resource access method further includes:

[0027] Set the waiting time for automatically releasing the first distributed lock;

[0028] When the current thread is finished running, releasing the first distributed lock includes:

[0029] When an exception occurs in releasing the first distributed lock and the duration reaches the waiting time, the first distributed lock is released.

[0030] In this way, when writing a value to the first distributed lock, the waiting time for automatically releasing the first distributed lock is set, and the waiting time is calculated from the time when the current thread is finished running. In the case where an exception occurs when releasing the first distributed lock and the duration reaches the waiting time, that is, when the current thread is finished running but the first distributed lock is not released in time, the first distributed lock will be released. This can effectively manage system resources and prevent the lock from being occupied for a long time. By releasing the lock, the system can improve its stability and reliability, and ensure the rational use of resources even in the event of an exception.

[0031] In some embodiments, the resource access method further includes:

[0032] In the process of running the current thread, in response to a response thread being called by the current thread, opening second lock information corresponding to the response thread, where the second lock information is used to record historical status information of the lock acquired by the response thread;

[0033] fusing the first lock information and the second lock information to obtain third lock information;

[0034] The access rights of the response thread to the second target resource are determined according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if it has the access rights to the second target resource.

[0035] In this way, in the process of running the current thread, in response to the response thread being called by the current thread, the second lock information corresponding to the response thread is opened, and the second lock information is used to record the historical status information of the lock acquired by the response thread. The first lock information and the second lock information are then fused to obtain the third lock information, which is used to control the response thread's access to the second target resource. Then, according to the third lock information, the access rights of the response thread for the second target resource are determined, so that the response thread can obtain the second distributed lock and access the second target resource when it has the access rights to the second target resource. In this way, by fusing the first lock information and the second lock information, the first lock information of the current thread is recorded in the second lock information to obtain the third lock information, and then the access rights of the response thread for the second target resource are determined according to the third lock information, and the lock transfer and resource access control between threads are realized, which can reduce the number of times the response thread re-acquires the distributed lock and improve the efficiency of the system.

[0036] In some implementations, determining the access right of the response thread to the second target resource according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if the response thread has the access right, includes:

[0037] Confirming second historical acquisition status information of the second distributed lock of the response thread according to the third lock information;

[0038] In a case where the second historical acquisition status information exists, it is determined that the response thread has access rights to the second target resource.

[0039] In this way, the second historical acquisition status information of the second distributed lock of the response thread is confirmed according to the third lock information. If the response thread or the current thread has acquired the second distributed lock and has not released the second distributed lock, the second historical acquisition status information exists in the third lock information. In the case of the existence of the second historical acquisition status information, it is determined that the response thread has access rights to the second target resource. After determining that the response thread has access rights to the second target resource, the response thread can directly access the second target resource, reduce the number of acquisitions of the second distributed lock, and improve the operating efficiency of the system.

[0040] In some implementations, determining the access right of the response thread to the second target resource according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if the response thread has the access right, includes:

[0041] In the absence of the second historical acquisition status information, performing value writing processing on the second distributed lock;

[0042] In a case where a value can be written to the second distributed lock, it is determined that the response thread has access rights to the second target resource.

[0043] In this way, in the absence of the second historical acquisition status information, in order to enable the responding thread to have access rights to the second target resource, the second distributed lock is processed for value writing. In the case where the value can be written to the second distributed lock, it is determined that the responding thread has access rights to the second target resource. After successfully determining that the responding thread has access rights to the second target resource through the value writing process, the responding thread can acquire the second distributed lock to access the second target resource.

[0044] In some embodiments, the resource access method further includes:

[0045] When the value is written to the second distributed lock successfully, the acquisition status information of the second distributed lock acquired by the response thread is written into the third lock information, and the acquisition status information of the second distributed lock includes the second identifier of the response thread.

[0046] In this way, when the value of the second distributed lock is written successfully, the acquisition status information of the second distributed lock acquired by the response thread is written into the third lock information, and the acquisition status information of the second distributed lock includes the second identifier of the response thread. In this way, the acquisition status information of the second distributed lock is recorded in the third lock information, so that when the subsequent running response thread needs to access the second target resource, it can directly access the second target resource by querying the third lock information.

[0047] In some implementations, determining the access right of the response thread to the second target resource according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if the response thread has the access right, includes:

[0048] In the case where writing a value to the second distributed lock fails, determining that the response thread does not have access rights to the second target resource;

[0049] The access request of the response thread to the second target resource is rejected, and the operation of the response thread is stopped.

[0050] In this way, when the value writing to the second distributed lock fails, it means that the second distributed lock has been acquired by other threads and has not been released, and it is determined that the responding thread does not have access rights to the second target resource. In the case where the responding thread does not have an access request to the second target resource, that is, the responding thread cannot obtain the second distributed lock, the responding thread's access request to the second target resource is rejected, and the responding thread is stopped. This ensures that only one thread that has acquired the second distributed lock can access the second target resource protected by the second distributed lock at the same time, thereby avoiding problems such as data inconsistency and deadlock.

[0051] In some implementations, the third information includes that the resource access method further includes:

[0052] In a case where the third lock information includes the second identifier of the response thread, releasing the second distributed lock after the response thread finishes running;

[0053] When the third lock information does not include the second identifier of the response thread, the second distributed lock is released after the current thread finishes running.

[0054] In this way, when the third lock information includes the second identifier of the responding thread, that is, when the responding thread obtains the second distributed lock by writing a value, the second distributed lock is released after the responding thread is finished running. In the case where the third lock information does not include the second identifier of the responding thread, that is, when the responding thread obtains the third lock information by querying the fusion of the first lock information and the second lock information, and determines that there is historical acquisition status information of the second distributed lock in the third lock information, and directly accesses the second target resource, the second distributed lock is released after the current thread is finished running. In this way, by querying the third lock information, it is determined whether the second distributed lock is acquired by the current thread or the responding thread. If it is the second distributed lock acquired by the responding thread, the second distributed lock is released after the response thread is finished running. If it is the second distributed lock acquired by the current thread, the second distributed lock needs to be released after the current thread is finished running. In this way, concurrency problems such as waste of resources and data inconsistency can be avoided.

[0055] An embodiment of the present application provides a computer device, which includes a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the resource access method described above is implemented.

[0056] An embodiment of the present application provides a computer-readable storage medium, wherein the computer-readable storage medium memory stores a computer program, and when the computer program is executed by one or more processors, the above-mentioned resource access method is implemented.

[0057] Additional aspects and advantages of the embodiments of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through the practice of the embodiments of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the description of the embodiments in conjunction with the following drawings, in which:

[0059] Figure 1 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0060] Figure 2 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0061] Figure 3 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0062] Figure 4 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0063] Figure 5It is a flowchart of a resource access method according to an implementation mode of the present application;

[0064] Figure 6 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0065] Figure 7 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0066] Figure 8 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0067] Fig. 9 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0068] Fig.10 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0069] Fig.11 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0070] Fig.12 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0071] Fig.13 It is a flowchart of a resource access method according to an implementation mode of the present application;

[0072] Fig.14 It is a scenario diagram of a resource access method according to an implementation mode of the present application;

[0073] Fig.15 It is a scenario diagram of a resource access method according to an implementation mode of the present application;

[0074] Fig.16 It is a scenario diagram of the resource access method of the implementation mode of the present application. DETAILED DESCRIPTION

[0075] The embodiments of the present application are described in detail below, and examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals represent the same or similar elements or elements having the same or similar functions from beginning to end. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the embodiments of the present application, and cannot be understood as limiting the embodiments of the present application.

[0076] In the current software engineering field, with the rapid growth of application system users and access volume, the system architecture has been transformed from a monolithic architecture to a microservice architecture. The microservice architecture usually includes multiple services, and a service usually includes multiple threads. In the actual task processing process, multiple threads may initiate access requests to the same resource, which can easily cause data inconsistency, deadlock and other concurrency problems.

[0077] For example, in an online shopping website, multiple services need to access the same inventory database to process orders. These services may include order processing services, inventory management services, payment services, logistics services, etc. The order processing service needs to read order information from the inventory database and update the order status. The inventory management service needs to regularly read the product inventory information from the inventory database and update the inventory quantity. The payment service needs to verify the payment information, update the user account and order payment status, and confirm the inventory status of the order to ensure that the order can be shipped. The logistics service needs to update the logistics status of the order, such as confirming the inventory status and shipping quantity of the product from the inventory database.

[0078] When the order processing thread in the order processing service receives a new order, it checks the inventory level of the product by accessing the inventory database. If the inventory is sufficient and the user successfully places an order, the order processing service will call the inventory management service to update the inventory. The inventory management thread of the inventory management service reduces the inventory quantity of the corresponding product by accessing the inventory database. In addition, the inventory management thread of the inventory management service needs to check the inventory database regularly to replenish the inventory or handle out-of-stock situations in a timely manner. The order processing thread and the inventory management thread each obtain the lock that protects the inventory database multiple times to access the inventory database, which affects the efficiency of the online shopping website and easily causes instability of the online shopping website. And because the online shopping website involves multiple virtual machines, the locks provided by the Java Development Kit (JDK) provided in the traditional Java programming language are no longer applicable.

[0079] Based on the above questions, please refer to Figure 1 The embodiment of the present application provides a resource access method based on a distributed lock, the method comprising:

[0080] 011: when the current thread initiates an access request to the first target resource, the first lock information corresponding to the current thread is opened, where the first lock information is used to record the historical status information of the lock acquired by the current thread;

[0081] 012: Determine the access rights of the current thread to the first target resource according to the first lock information, so that the current thread acquires the first distributed lock and accesses the first target resource if it has the access rights.

[0082] The embodiment of the present application also provides a computer device, including a memory and a processor. The resource access method of the embodiment of the present application can be implemented by the computer device of the embodiment of the present application. Specifically, a computer program is stored in the memory, and the processor is used to open the first lock information corresponding to the current thread when the current thread initiates an access request to the first target resource. The first lock information is used to record the historical status information of the lock acquired by the current thread, and determine the access rights of the current thread to the first target resource according to the first lock information, so that the current thread can obtain the first distributed lock and access the first target resource if it has the access rights.

[0083] The embodiment of the present application also provides a resource access device. The resource access method of the embodiment of the present application can be implemented by the resource access device of the embodiment of the present application. Specifically, the resource access device includes an opening module and a determination module. The opening module is used to open the first lock information corresponding to the current thread when the current thread initiates an access request to the first target resource. The first lock information is used to record the historical status information of the lock acquired by the current thread. The determination module is used to determine the access rights of the current thread for the first target resource based on the first lock information, so that the current thread can obtain the first distributed lock and access the first target resource if it has the access rights.

[0084] It should be noted that the resource access method provided in the implementation mode of the present application is applicable to the situation where multiple threads across multiple virtual machines initiate access requests to the same shared resource in a short period of time under the microservice architecture, thereby avoiding concurrency problems. For example, an online shopping website deployed on multiple virtual machines or servers, when a user enters the website to complete a product purchase, requires multiple services to access the same inventory database, such as order processing services, inventory management services, payment services, logistics services, etc. The order processing service needs to read order information from the inventory database and update the order status. The inventory management service needs to regularly read the inventory information of the goods from the inventory database and update the inventory quantity, and the inventory management service also needs to access the user database to update the user's account information and points. The payment service needs to verify the payment information, update the user account and order payment status, and confirm the inventory status of the order to ensure that the order can be shipped. The logistics service needs to update the logistics status of the order, such as confirming the inventory status and shipment quantity of the goods from the inventory database.

[0085] Specifically, the current thread is one of the multiple threads that initiate an access request to the first target resource. The first lock information includes the historical status information of the distributed lock in the current thread. The historical status information of the distributed lock includes the business type, business name and thread identifier of the acquired lock, which is used to confirm whether the thread has acquired a certain distributed lock. The target resource is a shared resource that needs to be accessed, including but not limited to database resources, file systems, and message queues. The first target resource is a shared resource that the current thread needs to access. The access right indicates whether the current thread can access the first target resource. The cases with access rights include obtaining the first distributed lock and being able to obtain the first distributed lock by value writing. The case without access rights is that the first distributed lock has not been obtained and the lock cannot be obtained by value writing. The first distributed lock is a distributed lock that protects the first target resource, which is used to ensure that only one thread can access the first target resource at the same time.

[0086] In the implementation mode of the present application, when the current thread initiates an access request to the first target resource, the present application opens the first lock information corresponding to the current thread, and the first lock information is used to record the historical status information of the lock acquired by the current thread. Then, according to the first lock information, the access right of the current thread to the first target resource is determined, so that the current thread acquires the first distributed lock and accesses the first target resource if it has the access right.

[0087] In summary, in the resource access application and computer device based on distributed locks of the implementation mode of the present application, in order to handle the situation where multiple threads initiating access requests to the first target resource in a microservice structure across multiple virtual machines easily cause concurrency problems, the following processing is performed on one of the multiple threads accessing the first target resource. The first lock information corresponding to the current thread is opened. The first lock information is used to record the historical information of the current thread obtaining the lock, and then the access rights of the current thread to the first target resource are determined according to the first lock information. If the access rights are obtained, the first distributed lock is obtained to access the first target resource. In this way, it is ensured that only one thread can access the first target resource at the same time, so that threads on multiple virtual machines can safely access and operate the first target resource, thereby realizing the handling of concurrency problems.

[0088] See also Figure 2 In some implementations, step 012 (determining the access right of the current thread to the first target resource according to the first lock information, so that the current thread acquires the first distributed lock and accesses the first target resource if it has the access right) includes:

[0089] 0121: confirm the first historical acquisition status information of the first distributed lock of the current thread according to the first lock information;

[0090] 0122: In the presence of first historical acquisition status information, it is determined that the current thread has access rights to the first target resource.

[0091] In some embodiments, the confirmation module is further used to confirm the first historical acquisition status information of the first distributed lock of the current thread according to the first lock information, and determine that the current thread has access rights to the first target resource if the first historical acquisition status information exists.

[0092] In some embodiments, the processor is further configured to confirm first historical acquisition status information of a first distributed lock of the current thread according to the first lock information, and determine that the current thread has access rights to the first target resource if the first historical acquisition status information exists.

[0093] Specifically, if the current thread has acquired the first distributed lock and has not released the first distributed lock at this time, then the first historical acquisition status information exists in the first lock information. The implementation method of the present application confirms the first historical acquisition status information of the first distributed lock of the current thread based on the first lock information. If the current thread has acquired the first distributed lock during operation and has not released the first distributed lock, then the first historical acquisition status information exists in the first lock information. In the case where the first historical acquisition status information exists, that is, the current thread has acquired the first distributed lock during operation and has not released the first distributed lock, the present application determines that the current thread has access rights to the first target resource.

[0094] In this way, after the implementation method of the present application determines that the current thread has access rights to the first target resource, the current thread can directly access the first target resource, thereby reducing the number of times the first distributed lock is acquired and improving the operating efficiency of the system.

[0095] See also Figure 3 In some implementations, step 012 (determining the access right of the current thread to the first target resource according to the first lock information, so that the current thread acquires the first distributed lock and accesses the first target resource if it has the access right) includes:

[0096] 0123: In the absence of the first historical acquisition status information, write a value to the first distributed lock;

[0097] 0124: When it is possible to write a value to the first distributed lock, it is determined that the current thread has access rights to the first target resource.

[0098] In some embodiments, the writing module is used to write a value to the first distributed lock when the first historical acquisition state information does not exist. The confirmation module is also used to determine that the current thread has access rights to the first target resource when the value can be written to the first distributed lock.

[0099] In some embodiments, the processor is further used to perform value writing processing on the first distributed lock in the absence of the first historical acquisition status information, and to determine whether the current thread has access rights to the first target resource when the value can be written to the first distributed lock.

[0100] Specifically, Redis is a type of cache database. The value writing process is to set a value in a distributed lock. The cache database is used to control access to shared resources and store access data. In the implementation of the present application, in the absence of the first historical acquisition status information, in order to enable the current thread to have access rights to the first target resource, a value writing process is performed on the first distributed lock in the cache database. One implementation method of the value writing process in Redis is: using the putifabsent command of redis, the putifabsent command determines whether the key of the distributed lock has a value. If not, it is directly inserted and true is returned; if there is a value, it will not be inserted and false is returned. The ability to write a value to the first distributed lock indicates that the first distributed lock has not been acquired by other threads, and the current thread can acquire the first distributed lock. When the value can be written to the first distributed lock, it is determined that the current thread has access rights to the first target resource.

[0101] In this way, the implementation method of the present application successfully completes the value writing process, so that the current thread successfully acquires the first distributed lock to access the first target resource, ensuring that only the thread that has acquired the first distributed lock can access the first target resource, avoiding concurrency problems such as data inconsistency caused by multiple threads accessing the same common resource.

[0102] See also Figure 4 In some implementations, the resource access method further includes:

[0103] 0125: When the value is written to the first distributed lock successfully, the acquisition status information of the first distributed lock acquired by the current thread is written into the first lock information.

[0104] In some embodiments, the writing module is further configured to write acquisition status information of the first distributed lock acquired by the current thread into the first lock information when the value of the first distributed lock is successfully written.

[0105] In some embodiments, the processor is further configured to write acquisition status information of the first distributed lock acquired by the current thread into the first lock information when the value is written to the first distributed lock successfully.

[0106] Specifically, the acquisition status information of the first distributed lock includes the thread identifier that acquires the first distributed lock, the business type and business name of the first distributed lock. The thread identifier is the name of the thread that acquires the distributed lock. When the value of the first distributed lock is successfully written, the implementation method of the present application writes the acquisition status information of the first distributed lock acquired by the current thread into the first lock information.

[0107] In this way, the first lock information records the acquisition status information of the first distributed lock, so that when the current thread needs to access the first target resource in subsequent operation, the first target resource can be directly accessed by querying the first lock information.

[0108] See also Figure 5 In some implementations, step 012 (determining the access right of the current thread to the first target resource according to the first lock information, so that the current thread acquires the first distributed lock and accesses the first target resource if it has the access right) includes:

[0109] 0126: when writing a value to the first distributed lock fails, determining that the current thread does not have access rights to the first target resource;

[0110] 0127: Reject the current thread's access request to the first target resource and stop running the current thread.

[0111] In some embodiments, the confirmation module is further used to determine that the current thread does not have access rights to the first target resource when writing a value to the first distributed lock fails. The rejection module is used to reject the current thread's access request to the first target resource and stop running the current thread.

[0112] In some embodiments, the processor is further configured to, when writing a value to the first distributed lock fails, determine that the current thread does not have access rights to the first target resource, reject the current thread's access request to the first target resource, and stop running the current thread.

[0113] Specifically, the implementation method of the present application fails to write a value to the first distributed lock, which means that the first distributed lock has been acquired by other threads and the first distributed lock has not been released, and it is determined that the current thread does not have access rights to the first target resource. In the case that the current thread does not have an access request to the first target resource, that is, the current thread cannot obtain the first distributed lock, the current thread's access request to the first target resource is rejected, and the current thread is stopped.

[0114] In this way, it is ensured that only one thread that has acquired the first distributed lock can access the first target resource protected by the first distributed lock at the same time, thereby avoiding concurrency problems such as data inconsistency and deadlock.

[0115] See also Figure 6 In some implementations, the resource access method further includes:

[0116] 013: When the current thread is finished running, release the first distributed lock.

[0117] In some implementations, the release module is used to release the first distributed lock when the current thread completes execution.

[0118] In some implementations, the processor is further configured to release the first distributed lock when the current thread completes execution.

[0119] Specifically, when the current thread finishes running, the current thread releases the first distributed lock.

[0120] In this way, the first distributed lock can be released in time, that is, other threads waiting to access the first target resource can obtain the first distributed lock in time to access the first target resource, thereby avoiding deadlock, effectively managing system resources and improving system performance.

[0121] See also Figure 7 In some implementations, the resource access method further includes:

[0122] 014: Set the waiting time for automatically releasing the first distributed lock;

[0123] Step 013 (releasing the first distributed lock when the current thread is finished running) includes:

[0124] 0131: When an exception occurs in releasing the first distributed lock and the duration reaches the waiting time, the first distributed lock is released.

[0125] In some embodiments, the setting module is used to set the waiting time for automatically releasing the first distributed lock. The releasing module is also used to release the first distributed lock when an exception occurs in releasing the first distributed lock and the duration reaches the waiting time.

[0126] In some embodiments, the processor is further configured to set a waiting time for automatically releasing the first distributed lock, and automatically release the first distributed lock when an exception occurs in releasing the first distributed lock and the duration reaches the waiting time.

[0127] Specifically, the waiting time is used to automatically release the distributed lock when an exception occurs in the thread operation, and the waiting time is calculated from the time when the current thread is completed. When writing a value to the first distributed lock, the implementation method of the present application sets the waiting time for automatically releasing the first distributed lock. In the case where an exception occurs in releasing the first distributed lock and the duration reaches the waiting time, that is, when the current thread is completed but the first distributed lock is not released in time, the first distributed lock is automatically released.

[0128] In this way, the implementation method of the present application can effectively manage system resources and prevent locks from being occupied for a long time. By automatically releasing locks through the cache database, the system can improve its stability and reliability and ensure the rational use of resources even in the event of an abnormality.

[0129] See also Figure 8 In some implementations, the resource access method further includes:

[0130] 015: in the process of running the current thread, in response to the response thread being called by the current thread, opening the second lock information corresponding to the response thread, where the second lock information is used to record the historical status information of the lock acquired by the response thread;

[0131] 016: The first lock information and the second lock information are merged to obtain the third lock information;

[0132] 017: Determine the access rights of the response thread to the second target resource according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if it has the access rights to the second target resource.

[0133] In some embodiments, the opening module is also used to open the second lock information corresponding to the response thread in response to the response thread being called by the current thread during the running of the current thread, and the second lock information is used to record the historical status information of the lock acquired by the response thread. The fusion module is used to fuse the first lock information and the second lock information to obtain the third lock information. The confirmation module is used to determine the access rights of the response thread to the second target resource based on the third lock information, so that the response thread can obtain the second distributed lock and access the second target resource if it has the access rights to the second target resource.

[0134] In certain embodiments, the processor is also used to, during the running of the current thread, enable second lock information corresponding to the response thread in response to the response thread being called by the current thread, the second lock information being used to record historical status information of the lock acquired by the response thread, and to fuse the first lock information and the second lock information to obtain third lock information, and to determine the access rights of the response thread to the second target resource based on the third lock information, so that the response thread can acquire the second distributed lock and access the second target resource if it has access rights to the second target resource.

[0135] Specifically, the response thread is another thread called by the current thread. The second lock information includes the historical information of the distributed lock in the response thread and the historical status information of the distributed lock. The third lock information includes the historical information of the distributed lock in the response thread and the historical status information of the distributed lock, the historical information of the distributed lock in the current thread and the historical status information of the distributed lock. The second target resource is a shared resource that the response thread needs to access, which may be consistent with the shared resource accessed by the current thread, or inconsistent with the shared resource accessed by the previous thread. The second distributed lock is a distributed lock that protects the second target resource, which is used to ensure that only one thread can access the second target resource at the same time. In the process of running the current thread, if the response thread is called by the current thread, then the implementation method of the present application opens the second lock information corresponding to the response thread, and the second lock information is used to record the historical status information of the lock obtained by the response thread. The first lock information and the second lock information are then merged to obtain the third lock information for controlling the response thread's access to the second target resource. One fusion method is: the current thread places the first lock information into the header of the HyperText Transfer Protocol (Http) request and response, and then passes it to the response thread. The response thread copies the first lock information in the header of the HyperText Transfer Protocol request and response to the second lock information of the response thread to obtain the third lock information.

[0136] Next, according to the third lock information, the access rights of the response thread to the second target resource are determined, so that the response thread can obtain the second distributed lock and access the second target resource when it has the access rights to the second target resource. If the shared resource that the response thread needs to access is consistent with the shared resource accessed by the current thread, that is, the second target resource is consistent with the first target resource, the second distributed lock is the first distributed lock corresponding to the first target resource. If the shared resource that the response thread needs to access is inconsistent with the shared resource accessed by the current thread, that is, the second target resource is inconsistent with the first target resource, the second distributed lock is the lock corresponding to the shared resource that the response thread needs to access.

[0137] In this way, the implementation mode of the present application integrates the first lock information and the second lock information, records the first lock information of the current thread in the second lock information to obtain the third lock information, and then determines the access rights of the responding thread to the second target resource based on the third lock information, thereby realizing distributed lock transfer and resource access control between threads, and can reduce the number of times the responding thread re-acquires the distributed lock, thereby improving the efficiency of the system.

[0138] See also Fig. 9 In some implementations, step 017 (determining the access rights of the response thread to the second target resource according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if it has the access rights) includes:

[0139] 0171: confirm the second historical acquisition status information of the second distributed lock of the response thread according to the third lock information;

[0140] 0172: When the second historical acquisition status information exists, determine that the response thread has access rights to the second target resource.

[0141] In some embodiments, the confirmation module is further used to confirm the second historical acquisition status information of the second distributed lock of the response thread according to the third lock information, and determine that the response thread has access rights to the second target resource if the second historical acquisition status information exists.

[0142] In some embodiments, the processor is further configured to confirm second historical acquisition status information of a second distributed lock of the response thread according to the third lock information, and determine that the response thread has access rights to the second target resource if the second historical acquisition status information exists.

[0143] Specifically, if the current thread has acquired the second distributed lock and has not released the second distributed lock at this time, then the second historical acquisition status information exists in the first lock information. The implementation method of the present application confirms the second historical acquisition status information of the second distributed lock of the response thread according to the third lock information. If the response thread or the current thread has acquired the second distributed lock and has not released the second distributed lock, then the second historical acquisition status information exists in the third lock information. In the case of the existence of the second historical acquisition status information, it is determined that the response thread has access rights to the second target resource.

[0144] In this way, after the implementation method of the present application determines that the response thread has access rights to the second target resource, the response thread can directly access the second target resource, thereby reducing the number of times the second distributed lock is acquired and improving the operating efficiency of the system.

[0145] See also Fig.10In some implementations, step 017 (determining the access rights of the response thread to the second target resource according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if it has the access rights) includes:

[0146] 0173: In the absence of the second historical acquisition status information, write the value to the second distributed lock;

[0147] 0174: When it is possible to write a value to the second distributed lock, determine that the response thread has access rights to the second target resource.

[0148] In some embodiments, the writing module is used to write a value to the second distributed lock when the second historical acquisition state information does not exist. The confirmation module is used to determine that the response thread has access rights to the second target resource when the value can be written to the second distributed lock.

[0149] In some embodiments, the processor is further used to perform value writing processing on the second distributed lock in the absence of second historical acquisition status information, and to determine that the response thread has access rights to the second target resource when the value can be written to the second distributed lock.

[0150] Specifically, in the absence of the second historical acquisition status information, in order to enable the responding thread to have access rights to the second target resource, the implementation method of the present application performs value writing processing on the second distributed lock in the cache database. When the value can be written to the second distributed lock, it is determined that the responding thread has access rights to the second target resource.

[0151] In this way, after the implementation mode of the present application successfully determines through value writing processing that the responding thread has access rights to the second target resource, the responding thread can obtain the second distributed lock to access the second target resource, ensuring that only the thread that has obtained the second distributed lock can access the second target resource, avoiding concurrency problems such as data inconsistency caused by multiple threads accessing the same shared resource.

[0152] See also Fig.11 In some implementations, the resource access method further includes:

[0153] 0175: When the value is written to the second distributed lock successfully, the acquisition status information of the second distributed lock acquired by the response thread is written into the third lock information, and the acquisition status information of the second distributed lock includes the second identifier of the response thread.

[0154] In some embodiments, the writing module is also used to write the acquisition status information of the second distributed lock acquired by the responding thread into the third lock information when the value of the second distributed lock is successfully written, and the acquisition status information of the second distributed lock includes the second identifier of the responding thread.

[0155] In some embodiments, the processor is further used to write the acquisition status information of the second distributed lock acquired by the response thread into the third lock information when the value of the second distributed lock is successfully written, and the acquisition status information of the second distributed lock includes the second identifier of the response thread.

[0156] Specifically, the acquisition status information of the second distributed lock includes the thread identifier that acquired the second distributed lock, the business type and business name of the second distributed lock. When the value is written to the second distributed lock successfully, the implementation method of the present application writes the acquisition status information of the second distributed lock acquired by the response thread into the third lock information.

[0157] In this way, the acquisition status information of the second distributed lock is recorded in the third lock information, so that when the subsequent running response thread needs to access the second target resource, the second target resource can be directly accessed by querying the third lock information.

[0158] See also Fig.12 In some implementations, step 017 (determining the access rights of the response thread to the second target resource according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if it has the access rights) includes:

[0159] 0176: when writing a value to the second distributed lock fails, determining that the response thread does not have access rights to the second target resource;

[0160] 0177: Reject the response thread's access request to the second target resource, and stop running the response thread.

[0161] In some embodiments, the confirmation module is used to determine that the response thread does not have access rights to the second target resource when writing a value to the second distributed lock fails. The rejection module is also used to reject the response thread's access request to the second target resource and stop running the response thread.

[0162] In some embodiments, the processor is further configured to, when writing a value to the second distributed lock fails, determine that the response thread does not have access rights to the second target resource, reject the response thread's access request to the second target resource, and stop running the response thread.

[0163] Specifically, in the case where the value writing to the second distributed lock fails, it means that the second distributed lock has been acquired by other threads and has not been released. The implementation method of the present application determines that the response thread does not have access rights to the second target resource. In the case where the response thread does not have an access request to the second target resource, that is, the response thread cannot obtain the second distributed lock, the implementation method of the present application rejects the response thread's access request to the second target resource and stops running the response thread.

[0164] In this way, it is ensured that only the thread that has acquired the second distributed lock can access the second target resource protected by the second distributed lock at the same time, thereby avoiding problems such as data inconsistency and deadlock.

[0165] See also Fig.13 In some implementations, the third information includes that the resource access method further includes:

[0166] 018: when the third lock information includes the second identifier of the response thread, releasing the second distributed lock after the response thread finishes running;

[0167] 019: When the third lock information does not include the second identifier of the response thread, release the second distributed lock after the current thread finishes running.

[0168] In some embodiments, the release module is also used to release the second distributed lock after the response thread has completed execution when the third lock information includes the second identifier of the response thread, and to release the second distributed lock after the current thread has completed execution when the third lock information does not include the second identifier of the response thread.

[0169] In some embodiments, the processor is also used to release the second distributed lock after the response thread completes execution when the third lock information includes the second identifier of the response thread, and to release the second distributed lock after the current thread completes execution when the third lock information does not include the second identifier of the response thread.

[0170] Specifically, the second identifier is the name of the responding thread. In the case where the third lock information includes the second identifier of the responding thread, that is, the responding thread obtains the second distributed lock by writing a value, the implementation method of the present application releases the second distributed lock after the responding thread is finished running. In the case where the third lock information does not include the second identifier of the responding thread, that is, the responding thread obtains the third lock information by querying and fusing the first lock information and the second lock information, and determines that there is historical acquisition status information of the second distributed lock in the third lock information, and directly accesses the second target resource, the implementation method of the present application releases the second distributed lock after the current thread is finished running.

[0171] In this way, by querying the third lock information, the implementation method of the present application determines whether the second distributed lock is acquired by the current thread or the response thread. If it is the second distributed lock acquired by the response thread, the second distributed lock is released after the response thread is finished running. If it is the second distributed lock acquired by the current thread, the second distributed lock needs to be released after the current thread is finished running. In this way, concurrency problems such as waste of resources and data inconsistency can be avoided.

[0172] The following is an example to illustrate the resource access method of the implementation method of this application:

[0173] The user buys a water cup on the online shopping website in the above example. Among them, the order processing thread is the current thread, and the order thread context is the first lock information. Distributed lock A is the first distributed lock, and distributed lock A is used to protect the inventory database. The cache database Redis is the cache database. Lock data A is the first historical acquisition status information. Lock data A1 is the acquisition status information of the first distributed lock.

[0174] See also Fig.14 , when a user completes a water cup purchase, the order processing service first needs to query the inventory database to see if there are enough water cups. The order processing thread in the order processing service opens the order thread context of the order processing thread. One method of opening the thread context is to use Java's ThreadLocal technology to open the thread context. The order processing thread queries the order thread context to confirm whether the order processing thread has already acquired distributed lock A. If the order thread context includes the lock data A of distributed lock A, it means that the order processing thread does not need to reacquire distributed lock A in the cache database Redis. The order processing thread can directly use distributed lock A to access the inventory database to query whether the inventory of water cups is sufficient. If the order thread context does not include the lock data A of distributed lock A, that is, the order processing thread has not acquired distributed lock A before, it means that the order processing thread needs to acquire distributed lock A in the cache database Redis.

[0175] The order processing thread obtains distributed lock A by writing a value to distributed lock A. If the value can be written to distributed lock A, it means that distributed lock A has not been acquired by other threads at this time. The order processing thread accesses the inventory database through the obtained distributed lock A. When writing a value to distributed lock A, the order processing thread sets the time limit of the written value. The time limit is used to automatically release distributed lock A after the order processing thread is completed. One way to release the distributed lock is to directly delete the written value. The time limit set in this example is 5 seconds. After the order processing thread obtains distributed lock A, the lock data A1 of distributed lock A is recorded in the context of the order thread. If the value cannot be written to distributed lock A, it means that distributed lock A has been acquired by other threads. The program throws a business exception and the order processing thread stops running until it obtains distributed lock A. When the order processing thread is completed, the distributed lock A is released from the cache database Redis and all lock data related to distributed lock A in the context of the order thread is deleted. If the order processing thread is completed, the order processing thread has exceeded the set time limit and has not deleted the written value to release the distributed lock, the cache database Redis will automatically clear the written value to release the lock.

[0176] Following the above example, the resource access method of the implementation mode of the present application is described. In the embodiment of the present application, the inventory management thread is the response thread, the temporary inventory thread context B1 is the second lock information, and the inventory thread context B2 is the third lock information. Fig.15 After the user successfully places an order for a water cup, the order processing service needs to call the inventory management service to update the number of water cups in the inventory database. The inventory management thread in the inventory management service first opens the temporary inventory thread context B1. Then, the order thread context and the temporary inventory thread context B1 are merged to obtain the inventory thread context B2. The fusion method is: before the order processing service calls the inventory management service, the order processing thread places the lock data in the order thread context into the header of the HyperText Transfer Protocol (Http) request and response, and passes it to the inventory management service. The inventory management thread in the inventory management service copies the lock data in the header of the HyperText Transfer Protocol (Http) request and response to the temporary inventory thread context B1 of the inventory management thread to obtain the inventory thread context B2.

[0177] Then, in this case, the second target resource is the same as the first target resource, that is, the second target resource is the inventory database, and the second distributed lock is distributed lock A. The inventory management thread can obtain distributed lock A with reference to the explanation of the order processing thread obtaining distributed lock A in the aforementioned implementation example, which will not be repeated here. After the inventory management thread is completed, since the thread ID recorded in the lock data of distributed lock A is the order processing thread, which does not include the inventory management thread, distributed lock A will not be released after the inventory management thread is completed, but needs to be released after the order processing thread is completed.

[0178] Following the above example, the resource access method of the implementation mode of the present application is described. Fig.16 , after the inventory management thread accesses the inventory database to update the water cup inventory, the inventory management thread needs to access the user database to update the user's account information and points. In this case, the second target resource is not the first target resource, that is, the second target resource is not the inventory database, but the user database, and the second distributed lock is the distributed lock B corresponding to the user database. The inventory management thread confirms whether the inventory management thread has obtained the distributed lock B by querying the inventory thread context B2. In the case of confirming that the inventory management thread has not obtained the distributed lock B, the distributed lock B is obtained by obtaining it in the cache database Redis, and the value is written to the distributed lock B to obtain the distributed lock B, and the lock data of the distributed lock B is recorded in the inventory thread context B2. The inventory management database then accesses the user database through the distributed lock B to update the user's account information and points. After the inventory management thread is finished running, since the thread ID recorded in the lock data of the inventory thread context B2 is consistent with the inventory management thread, the inventory management thread releases the lock from the cache database Redis and deletes all data related to the distributed lock B in the inventory thread context B2.

[0179] The present application also provides a computer-readable storage medium containing a computer program. When the computer program is executed by one or more processors, the one or more processors execute the voice interaction method of the present application.

[0180] It is understood that a computer program includes computer program code. The computer program code may be in source code form, object code form, executable file or some intermediate form. Computer readable storage media may include: any entity or device capable of carrying computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), and software distribution medium.

[0181] In the description of this specification, the descriptions with reference to the terms "specifically", "further", "particularly", "understandably", etc. are intended to mean that the specific features, structures, materials or characteristics described in conjunction with the embodiments or examples are included in at least one embodiment or example of the present application. In this specification, the schematic representations of the above terms are not intended to refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, unless they are contradictory.

[0182] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may not be performed in the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by technicians in the technical field to which the embodiments of the present application belong.

[0183] Although the embodiments of the present application have been shown and described above, it can be understood that the above embodiments are exemplary and cannot be understood as limitations on the present application. Ordinary technicians in this field can change, modify, replace and modify the above embodiments within the scope of the present application.

Claims

1. A resource access method based on distributed locks, characterized in that: The method comprises: When the current thread initiates an access request to the first target resource, first lock information corresponding to the current thread is opened, where the first lock information is used to record historical status information of the lock acquired by the current thread; The access rights of the current thread to the first target resource are determined according to the first lock information, so that the current thread acquires a first distributed lock and accesses the first target resource if the current thread has the access rights.

2. The method according to claim 1, characterized in that The step of determining the access right of the current thread to the first target resource according to the first lock information, so that the current thread acquires the first distributed lock and accesses the first target resource if the current thread has the access right, includes: Confirming first historical acquisition status information of the first distributed lock of the current thread according to the first lock information; In a case where the first historical acquisition state information exists, it is determined that the current thread has access rights to the first target resource.

3. The method according to claim 1, characterized in that The step of determining the access right of the current thread to the first target resource according to the first lock information, so that the current thread acquires the first distributed lock and accesses the first target resource if the current thread has the access right, includes: In the absence of the first historical acquisition status information, performing value writing processing on the first distributed lock; In a case where a value can be written to the first distributed lock, it is determined that the current thread has access rights to the first target resource.

4. The method according to claim 3, characterized in that The resource access method further includes: When the value writing to the first distributed lock is successful, the acquisition status information of the first distributed lock acquired by the current thread is written into the first lock information.

5. The method according to claim 3, characterized in that: The step of determining the access right of the current thread to the first target resource according to the first lock information, so that the current thread acquires the first distributed lock and accesses the first target resource if the current thread has the access right, includes: In the case where writing a value to the first distributed lock fails, determining that the current thread does not have access rights to the first target resource; The access request of the current thread to the first target resource is rejected, and the current thread is stopped.

6. The method according to claim 1, characterized in that The resource access method further includes: When the current thread is finished running, the first distributed lock is released.

7. The method according to claim 6, characterized in that The resource access method further includes: Set the waiting time for automatically releasing the first distributed lock; When the current thread is finished running, releasing the first distributed lock includes: When an exception occurs in releasing the first distributed lock and the duration reaches the waiting time, the first distributed lock is released.

8. The method according to claim 1, characterized in that The resource access method further includes: In the process of running the current thread, in response to a response thread being called by the current thread, opening second lock information corresponding to the response thread, where the second lock information is used to record historical status information of the lock acquired by the response thread; fusing the first lock information and the second lock information to obtain third lock information; The access rights of the response thread to the second target resource are determined according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if it has the access rights to the second target resource.

9. The method according to claim 8, characterized in that The step of determining the access right of the response thread to the second target resource according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if the response thread has the access right, includes: Confirming second historical acquisition status information of the second distributed lock of the response thread according to the third lock information; In a case where the second historical acquisition status information exists, it is determined that the response thread has access rights to the second target resource.

10. The method according to claim 8, characterized in that The step of determining the access right of the response thread to the second target resource according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if the response thread has the access right, includes: In the absence of the second historical acquisition status information, performing value writing processing on the second distributed lock; In a case where a value can be written to the second distributed lock, it is determined that the response thread has access rights to the second target resource.

11. The method according to claim 10, characterized in that The resource access method further includes: When the value is written to the second distributed lock successfully, the acquisition status information of the second distributed lock acquired by the response thread is written into the third lock information, and the acquisition status information of the second distributed lock includes the second identifier of the response thread.

12. The method according to claim 10, characterized in that The step of determining the access right of the response thread to the second target resource according to the third lock information, so that the response thread acquires the second distributed lock and accesses the second target resource if the response thread has the access right, includes: In the case where writing a value to the second distributed lock fails, determining that the response thread does not have access rights to the second target resource; The access request of the response thread to the second target resource is rejected, and the operation of the response thread is stopped.

13. The method according to claim 8, characterized in that The resource access method further includes: In a case where the third lock information includes the second identifier of the response thread, releasing the second distributed lock after the response thread finishes running; When the third lock information does not include the second identifier of the response thread, the second distributed lock is released after the current thread finishes running.

14. A computer device, characterized in that: The computer device includes a memory and a processor, the memory stores a computer program, and when the computer program is executed by the processor, the method according to any one of claims 1 to 13 is implemented.

15. A computer-readable storage medium, characterized in that: The computer-readable storage medium memory stores a computer program, and when the computer program is executed by one or more processors, the method according to any one of claims 1 to 13 is implemented.

Images