Data update methods, apparatus, computer equipment and storage media

Abstract

This application provides a data update method, apparatus, computer device, and storage medium, relating to cloud technology, big data, cloud storage, and other technical fields. By determining an access queue based on an access index when at least two access requests trigger a data update, multiple access requests are accurately and conveniently centralized in the queue for unified management. The head request in the access queue updates the index data, and the head thread corresponding to the head request wakes up the waiting threads corresponding to the other access requests, allowing the remaining access requests to directly access the updated index data without repeating the update process. This avoids duplicate updates by a large number of access requests. Especially in high-concurrency scenarios, it prevents massive concurrent requests from penetrating the backend device, avoiding update errors, dirty data generation, operating system crashes, and other problems caused by simultaneous duplicate updates, ensuring the accuracy and reliability of the data update process.

Description

Technical Field

[0001] This application relates to the technical fields of cloud technology, big data, cloud storage, etc., and specifically to a data update method, apparatus, computer equipment, and storage medium. Background Technology

[0002] As the scale of various business operations in applications expands and business data grows explosively, caching is widely used in various business operations due to its high access speed. Proper use of caching can effectively reduce the access pressure on the server hosting the database. However, with business updates, the data in the cache often needs to be updated as well.

[0003] In related technologies, data update methods may include: when it is necessary to update a certain piece of data in the cache, first delete the data to invalidate the cache, retrieve the latest data from the database, update the cache with the latest data, and then restore access to the data in the cache after the update.

[0004] The above data update method requires interrupting and then restoring the cache. If there are a large number of concurrent access requests, the server's database can be accessed directly to update the data in the cache. This can cause the server to be overwhelmed by a large number of requests, resulting in a server system avalanche and easy update failure. Therefore, the reliability of the above data update method is poor. Summary of the Invention

[0005] This application provides a data updating method, apparatus, computer device, and storage medium, which can solve the problem of poor reliability in related technologies. The technical solution is as follows:

[0006] On the one hand, a data update method is provided, the method comprising:

[0007] In response to at least two access requests that trigger data updates, an access queue is determined based on the access indexes corresponding to the at least two access requests. The access queue includes at least two access requests, and any access request is used to access the index data corresponding to its access index.

[0008] Based on the head requests in the access queue, the index data that matches each access request in the access queue is updated. The head request refers to the access request located at the head node of the access queue.

[0009] Based on the header thread corresponding to the header request, wake up at least one waiting thread corresponding to an access request in the access queue other than the header request. The waiting thread is used to wait to execute the access operation corresponding to the access request.

[0010] Based on the threads corresponding to at least two access requests in the access queue, access the updated index data.

[0011] In one possible implementation, when the access queue includes at least two specified requests, the step of performing a specified access operation on the index data via the head thread includes:

[0012] The head thread is used to perform conflict detection on the at least two specified requests;

[0013] When there is no conflict between the at least two specified requests, at least two specified access operations of the at least two specified requests are executed through the head thread;

[0014] When a conflict exists between the at least two specified requests, the target specified operation of the request that conforms to the conflict policy among the at least two specified requests is executed through the head thread.

[0015] In one possible implementation, the at least two access requests that trigger the data update refer to: an access request that misses a cache database or an access request that accesses expired data in the cache database.

[0016] In one possible implementation, waking up at least one waiting thread in the access queue corresponding to an access request other than the header request, based on the header thread corresponding to the header request, includes:

[0017] When the index data matching each access request is successfully updated, the head thread removes at least two access requests from the access queue one by one and wakes up the waiting thread corresponding to the access request removed from the access queue.

[0018] On the other hand, a data updating apparatus is provided, the apparatus comprising:

[0019] A queue determination module is used to determine an access queue based on the access index corresponding to the at least two access requests in response to at least two access requests that trigger data updates. The access queue includes at least two access requests, and any access request is used to access index data corresponding to its access index.

[0020] The update module is used to update the index data that matches each access request in the access queue based on the head request in the access queue, wherein the head request refers to the access request located at the head node of the access queue.

[0021] The wake-up module is used to wake up at least one waiting thread corresponding to an access request in the access queue, other than the head request, based on the head thread corresponding to the head request. The waiting thread is used to wait to execute the access operation corresponding to the access request.

[0022] The access module is used to access the updated index data based on the threads corresponding to at least two access requests in the access queue.

[0023] On the other hand, a computer device is provided, the computer device comprising:

[0024] One or more processors;

[0025] Memory;

[0026] One or more computer programs, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more programs being configured to: perform the data update method described above.

[0027] On the other hand, a computer-readable storage medium is provided for storing computer instructions that, when executed on a computer, enable the computer to perform the data update method described above.

[0028] On the other hand, a computer program product is provided, characterized in that it includes a computer program or instructions, which, when executed by a processor, implement the above-described data update method.

[0029] The beneficial effects of the technical solution provided in this application are:

[0030] By determining the access queue based on the access index when at least two access requests trigger data updates, multiple access requests are accurately centralized in the queue for unified and convenient management. The head request in the access queue updates the index data matching each access request in the access queue. The head thread corresponding to the head request wakes up the waiting threads corresponding to the other access requests, so that the other access requests can directly access the index data updated by the head request without repeating the update. This avoids duplicate updates by a large number of access requests. Especially in high-concurrency scenarios, it can prevent massive concurrent requests from penetrating the backend device and avoid update errors, dirty data, operating system crashes, and other problems caused by massive requests updating repeatedly at the same time. This ensures the accuracy and improves the reliability of the data update process. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments of this application will be briefly introduced below.

[0032] Figure 1 A schematic diagram illustrating the implementation environment of a data update method provided in this application;

[0033] Figure 2A flowchart illustrating a data update method provided in an embodiment of this application;

[0034] Figure 3 A schematic diagram of a process for determining a third access queue is provided for an embodiment of this application;

[0035] Figure 4 A schematic diagram illustrating a data update process provided in an embodiment of this application;

[0036] Figure 5 This is a schematic diagram of the structure of a data update device provided in an embodiment of this application;

[0037] Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0038] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting the invention.

[0039] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0040] Cloud storage is a new concept that extends and develops from the concept of cloud computing. A distributed cloud storage system (hereinafter referred to as a storage system) refers to a storage system that uses cluster applications, grid technology and distributed storage file systems to bring together a large number of storage devices of various types in the network (storage devices are also called storage nodes) to work together through application software or application interfaces to provide data storage and business access functions to the outside world.

[0041] Currently, the storage method in storage systems is as follows: Logical volumes are created, and during creation, physical storage space is allocated to each logical volume. This physical storage space may consist of a single storage device or the disks of several storage devices. Clients store data on a logical volume, which means storing the data on the file system. The file system divides the data into many parts, each part being an object. Each object contains not only the data but also additional information such as a data identifier (ID, ID entity). The file system writes each object to the physical storage space of that logical volume and records the storage location information of each object. Therefore, when a client requests access to data, the file system can allow the client to access the data based on the storage location information of each object.

[0042] A database, simply put, can be viewed as an electronic filing cabinet—a place to store electronic files, where users can perform operations such as adding, querying, updating, and deleting data. A "database" is a collection of data stored together in a certain way, capable of being shared by multiple users, with minimal redundancy, and independent of application programs.

[0043] A Database Management System (DBMS) is a computer software system designed to manage databases, generally possessing basic functions such as storage, retrieval, security, and backup. DBMSs can be classified according to the database model they support, such as relational or XML (Extensible Markup Language); or according to the type of computer they support, such as server clusters or mobile devices; or according to the query language used, such as SQL (Structured Query Language) or XQuery; or according to performance priorities, such as maximum scale or maximum operating speed; or other classification methods. Regardless of the classification method used, some DBMSs can cross categories, for example, supporting multiple query languages ​​simultaneously.

[0044] Cloud computing refers to the delivery and usage model of IT infrastructure, meaning obtaining necessary resources in an on-demand and easily scalable manner through a network. In a broader sense, cloud computing also refers to the delivery and usage model of services, meaning obtaining necessary services in an on-demand and easily scalable manner through a network. These services can be IT and software related, internet-related, or other services. Cloud computing is a product of the development and integration of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing.

[0045] With the development of the internet, real-time data streams, and the diversification of connected devices, as well as the demands for search services, social networks, mobile commerce, and open collaboration, cloud computing has rapidly developed. Unlike previous parallel distributed computing, cloud computing will fundamentally revolutionize the entire internet model and enterprise management model.

[0046] Cloud social networking is a virtual social application model that integrates the Internet of Things, cloud computing, and mobile internet. Its purpose is to establish a well-known "resource-sharing relationship graph" to facilitate online social interaction. The main characteristic of cloud social networking is the unified integration and evaluation of a large amount of social resources, forming an effective resource pool to provide services to users on demand. The more users participate in sharing, the greater the value created.

[0047] Cloud conferencing is an efficient, convenient, and low-cost form of meeting based on cloud computing technology. Users only need to use an internet interface to quickly and efficiently share voice, data files, and video with teams and clients around the world. The complex technologies such as data transmission and processing during the meeting are handled by the cloud conferencing service provider.

[0048] Cloud conferencing systems support dynamic multi-server cluster deployment and provide multiple high-performance servers, significantly improving meeting stability, security, and availability. In recent years, video conferencing has gained popularity due to its ability to greatly improve communication efficiency, continuously reduce communication costs, and upgrade internal management, and is widely used in various fields such as government, transportation, logistics, finance, telecommunications, education, enterprises, and connected vehicles. Undoubtedly, with the application of cloud computing, video conferencing is even more attractive in terms of convenience, speed, and ease of use, which will surely usher in a new wave of video conferencing applications.

[0049] The data update method provided in this application can be implemented using the aforementioned technologies such as cloud storage, databases, and cloud computing. For example, the data update method of this application can be used to update cached data. For instance, cloud storage technology can be used to store and update cached data; for example, a file system based on cloud storage technology can allocate physical storage space for a large amount of cached data, and the storage location information of each cached data recorded by the file system can be used to access and update the cached data. For example, this application can also use database technology to perform operations such as adding, querying, updating, and deleting data in the cache database to achieve real-time management and rapid updates of cached data. This application can utilize cloud computing technology to achieve a rapid creation process for the access queue; for example, by combining cloud computing technology to enqueue threads corresponding to high-concurrency access requests, an access queue can be generated so that the cached data can be updated based on the head thread in the access queue.

[0050] The data update method provided in this application can be applied to any scenario with caching requirements. For example, it can be applied to various technical fields such as cloud social networking, cloud conferencing, medical cloud, and cloud gaming. For instance, in the field of cloud social networking, the data update method of this application can be used to maintain and update massive amounts of user data on social platforms in real time. In the field of cloud conferencing, the data update method of this application can be used to update text, voice, data files, and videos shared synchronously during meetings in real time.

[0051] Figure 1 This is a schematic diagram illustrating the implementation environment of a data update method provided in this application. For example... Figure 1 As shown, the implementation environment includes a first device 101, a second device 102, and a third device 103. The first device 101 stores cached data, and the second device 102 can access the cached data in the first device 101. The third device 103 provides the original data for the cached data to the first device 101. The third device 103 includes resources for providing the original data. The first device 101 can update the cached data stored in the first device 101 based on the resources included in the third device 103. For example, the resources included in the third device 103 can be the original data of the cached data, or a program used to provide the original data, such as a service, interface, or instance for providing the original data. The second device 102 can access data from the first device 101 based on information interaction with the first device 101. The first device 101 can retrieve data from the resources included in the third device 103 based on information interaction with the third device 103, and update the cached data stored in the first device 101 based on the retrieved data.

[0052] For example, the second device 102 can send an access request to the first device 101. The first device 101 receives the access request and runs a thread to perform the access operation for the request. When accessing cached data via the access request, if the access request triggers a data update, the running thread can pull data from the third device 103 to update the cached data, so that subsequent access requests can directly access the updated cached data. For example, the first device 101 runs a program for providing data access services. This program can provide data access services for multiple access requests through multiple threads, with each access request corresponding to one thread.

[0053] In one possible scenario, the first device 101 may integrate a cache update program, which can be executed to implement the data update process of this application. For example, the first device 101 may be equipped with a data management component for managing cached data, which includes the cache update program. When the second device 102 accesses the cached data of the first device 101, if the cached data needs to be updated, the first device 101 can update it based on the data management component. In another possible scenario, the cache update program can be integrated into the second device 102. When the second device 102 accesses the cached data stored in the first device 101, the first device 101 can return the data to be accessed to the second device 102 based on the access request of the second device 102. When the second device 102 determines that the cached data needs to be updated, the second device 102 executes the cache update program. That is, the second device 102 pulls data from the third device 102 and sends the pulled data to the first device 101. The first device 101 updates the cached data based on the received pulled data.

[0054] The first device 101 can be any computer device that stores cached data and performs data update processes, such as a server, service cluster, or terminal. For example, the first device 101 can be a backend server for an application, or a server that provides cached data access functionality to the backend server. Each of the first device 101, the second device 102, and the third device 103 can be a physical device or a virtual service node based on a physical device; the physical device can include a server, service cluster, or terminal device. For example, the first device 101, the second device 102, and the third device 103 can be located in the same service cluster or multiple service clusters.

[0055] For example, a server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server or server cluster that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms. The aforementioned networks can include, but are not limited to, wired networks and wireless networks. Wired networks include local area networks (LANs), metropolitan area networks (MANs), and wide area networks (WANs). Wireless networks include Bluetooth, Wi-Fi, and other networks that enable wireless communication. Terminals can be management terminals of an organization, smartphones (such as Android phones, iOS phones, etc.), tablets, laptops, etc. Specific requirements can be determined based on actual application scenarios and are not limited here.

[0056] The following is a description of the terms used in this application:

[0057] Access Request: Represents a request to access index data; for example, an access request may correspond to an access index, and the access request is used to access the index data corresponding to the access index; for example, the access request may carry an index key1, which may indicate access to the value1 corresponding to key1; the access operation of the access request may be executed by the thread corresponding to the access request.

[0058] Cached data: Cached data can include index information and index data; cached data can be stored in key-value format, where the key is the index key and the value is the index data; cached data can be frequently accessed hot data, such as thousands or tens of thousands of times per second; or it can include data that does not change frequently and whose read frequency is much greater than its write frequency, such as data that is only changed once every few days, weeks, or months.

[0059] The access and update logic for cached data is triggered by access requests. If an access request misses a cache database or accesses expired data in the cache database, a data update will be triggered. In this application, updates can be performed based on the header requests in the access queue. For example, if access request M accesses data a and data a expires, the update process for data a will be triggered. After data a is updated, it will be accessed by various access requests in the access queue.

[0060] Head request: refers to the access request located at the head node of the access queue. That is, the head request is located at the first position of the access queue, and the thread corresponding to the head request is the head thread.

[0061] Thread: Used to execute the access operation corresponding to the access request. For example, one access request can correspond to one thread.

[0062] Head thread: The thread used to execute the update process; it corresponds to the head request located at the head node and can be called the leader thread.

[0063] Waiting thread: Used to wait for the head thread to perform the update before accessing the data; the thread corresponding to the access request in the access queue other than the head request. After the access request corresponding to the waiting thread is enqueued, it remains in a suspended state until it is awakened by the head thread and the access operation corresponding to the access request is executed.

[0064] Access Index: The index carried in the access request, used to retrieve indexed data; the access index can include an index key or a virtual key; for example, the access request can carry a key.

[0065] Index information: The cached data includes index information used to retrieve the index of the index data; the index information may include the index key, or the data bucket to which the index key belongs; each data bucket may be used to indicate the index data corresponding to one or more index keys; for example, based on the access index carried by the access request, the index information and index data stored in the cache database can be used to query the index data corresponding to the access index in the cache database.

[0066] Index data: The cached data includes index data, which is also the actual data that needs to be accessed; in key-value data, the value is index data; one key can correspond to one value, or two or more values; the data structure type of index data can include, but is not limited to: string, hash, list, set, sorted set, etc.

[0067] Target lock: A lock structure that can lock queue operations that access the queue, used to ensure the uniqueness of the thread performing the queue operation; the queue operation can include at least one of enqueue and dequeue operations; for example, the target lock can be a mutex lock; of course, it can also be a spin lock or other locks.

[0068] Compare and swap operation: This is an atomic operation. As the name suggests, it compares two parameter values ​​and swaps them if they are the same. The comparison and swap operation involves three variables: the variable to be compared, the expected value, and the target value. If the variable to be compared is the same as the expected value, the variable to be compared and the target value are swapped, that is, the target value is assigned to the variable to be compared. This will be explained in detail in conjunction with the enqueue process in step 2012 and the dequeue process in step 203.

[0069] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0070] Figure 2This is a flowchart illustrating a data update method provided in an embodiment of this application. The method can be executed by a computer device. Figure 2 As shown, the method includes the following steps.

[0071] Step 201: In response to at least two access requests that trigger data updates, the computer device determines an access queue based on the access index corresponding to the at least two access requests.

[0072] The access queue includes at least two access requests, each request accessing index data corresponding to its access index. Triggering a data update refers to triggering the update process of the index data to be accessed by the access request. In one possible implementation, the at least two access requests that trigger a data update are: an access request that misses a cached database request or an access request that accesses expired data in the cached database. Expired data refers to data whose expiration time has reached the current time. In one possible example, for any index data, when any access request misses a cached database request or the current time reaches the expiration time of the index data, the computer device determines that the index data needs to be updated. A miss means that the index data could not be successfully accessed; for example, the index data may not exist or may be incorrect. The configuration information of the index data may be configured with an expiration time, which refers to the time when the index data becomes invalid; for example, the index data becomes invalid when the current time reaches the expiration time (year, month, day, hour). Embodiments of this application may also trigger updates to the index data based on other circumstances; embodiments of this application do not specifically limit how the data update process is triggered. For example, a user can also trigger a data update based on an update command. Upon receiving an update command, accessing the requested index data triggers the update. It should be noted that the update of the index data is triggered by the thread corresponding to the access request. In this application, the update process can be performed by the head thread in the access queue.

[0073] In one possible implementation, the cached data in the cache database can be stored in association with index information. That is, the cached data can include both index information and index data, where the index information refers to the information used to retrieve the index data. The computer device can then query the index data corresponding to the access index based on the access request, utilizing the association between the index information and index data in the cache database.

[0074] In this step, the computer device can determine the access queue corresponding to the access index based on the access request. The access queue includes at least two access requests for accessing the index data corresponding to the access index.

[0075] For example, the access index carried in the access request may also include an index key. Based on the index key carried in the access request, the index data corresponding to the index key is retrieved from the cache database. The index information in the cache data includes at least one of the index key and the data bucket to which the index key belongs. In one possible example, the index information may include the index key; one index key may correspond to one access queue. In another possible example, the index information may include the index key and the data bucket to which the index key belongs; one data bucket may correspond to one access queue. For example, the cache data may be stored in buckets, with each data bucket indicating index data corresponding to multiple index keys; for example, data bucket A includes key1, key2, and key3. In another possible example, the access index may also include a virtual key, which is an index key that does not exist in the cache database to be accessed; that is, if the index key is not hit when accessing the cache database, the computer device can configure a virtual key for the data to be accessed, and this virtual key corresponds to an associated access queue.

[0076] Based on the index information and the above-mentioned possible scenarios for accessing the index, the computer device may determine the access queue in at least the following three ways.

[0077] Method 1: The computer device determines the access queue corresponding to the index key based on the index key.

[0078] The computer device determines the access queue corresponding to the index key based on the index key carried in the access request. The access queue corresponding to the index key includes at least two access requests to access the index data corresponding to the index key; for example, the access requests include index data to be updated in the index data corresponding to the index key, which is the index data in the index data corresponding to the index key that has been triggered for updating.

[0079] Method 2: The computer device determines the access queue corresponding to the data bucket based on the data bucket to which the index key belongs.

[0080] The access queue corresponding to the data bucket includes at least two access requests for accessing the index data corresponding to any index key in the data bucket. For example, these at least two access requests could be for accessing index data to be updated within the index data corresponding to any index key in the data bucket.

[0081] Method 3: The computer device determines the access queue corresponding to the virtual key based on the virtual key.

[0082] The access queue corresponding to the virtual key includes at least two access requests for the index data corresponding to that virtual key. The virtual key refers to an index key that does not exist in the cache database; therefore, the index data corresponding to the virtual key is the index data to be updated. The computer device can determine an access queue including at least one thread based on the virtual key, and this thread is used to access the index data corresponding to the virtual key. In one possible example, if a thread accesses the cache database but does not find the index key, the computer device can configure a virtual key-associated access queue. For example, the cache database may include a portion of the original data. For access operations on another portion of the original data not included in the cache database, a corresponding virtual key-associated access queue can be established first, so that subsequent updates to the cache database can be based on the original data.

[0083] By determining access queues based on access indexes, multiple access requests can be centrally managed in a unified and convenient manner, improving management efficiency. Furthermore, each access request can be precisely divided into multiple access queues according to the access index, enabling subsequent management of access requests based on the access index. This means that an access queue can be associated with an index key, a data bucket, or even a virtual key. This flexibly meets the needs of various scenarios, improves the applicability of data update methods, and enhances the accuracy of subsequent data updates based on access queues.

[0084] It should be noted that this application only illustrates methods one to three above as examples for determining the access queue corresponding to the access index; of course, in addition to the three methods mentioned above, access queues can also be associated with index data. This application does not specifically limit the granularity of the access queue division; one access queue can correspond to one index key or one data bucket. In another possible example, the computer device can determine high-frequency data whose access frequency exceeds a target frequency from multiple index data corresponding to the index key based on the access frequency of each index data corresponding to the index key, and determine an access queue including at least one thread that needs to access the high-frequency data; especially for high-concurrency access scenarios, by determining the access queue corresponding to the high-frequency data, rapid updates of the high-frequency data can be achieved, further enabling rapid response to hot services that require access to high-frequency data.

[0085] In this step, the computer device may first create an initial queue, and then obtain an access queue based on the initial queue and the threads to be accessed. In one possible implementation, step 201 may include the following steps 2011-2012.

[0086] Step 2011: In response to at least two access requests that trigger a data update, the computer device creates an initial queue corresponding to the access index based on the access index.

[0087] The computer device can obtain an empty queue, initialize the empty queue based on its configuration information, and obtain the initial queue corresponding to the access index. This configuration information may include, but is not limited to, at least one of the following: head node, tail node, queue length, and queue memory usage. For example, the computer device can configure the queue length of the empty queue and configure the current memory usage of the queue based on the configured queue length.

[0088] For example, the computer device creates an initial queue corresponding to the access index based on the access index. Based on the above-described possible scenarios of the access index, the computer device may create an initial queue corresponding to the index key; or, create an initial queue corresponding to the data bucket; or, create an initial queue corresponding to the virtual key.

[0089] In one possible implementation, the computer device can create a queue configured with a target lock, a circular queue with its head and tail connected, or a queue in the form of a doubly linked list. In one possible example, the computer device can create a first initial queue corresponding to the access index based on queue attribute variables and the target lock for queue operations. The target lock is used to ensure the uniqueness of threads performing queue operations on the first initial queue. The queue operations include at least one of enqueue and dequeue operations, and the queue attribute variables include at least one of a queue length variable and a memory usage variable. For example, the computer device can create an empty queue and initialize it based on the queue attribute variables and the target lock to obtain the first initial queue. For instance, the computer device can configure the initial value of the queue attribute variables and the target lock for queue operations for the empty queue to obtain the first initial queue. For example, the initial value of the queue length variable can be configured to 0 or 1. Here, the enqueue operation refers to adding a thread to the queue, and the dequeue operation refers to removing a thread from the queue. The queue length variable indicates the current length of the first initial queue; the more threads join the first initial queue, the larger the value of this queue length variable becomes. The target lock can be a mutex lock, or it can be a spin lock or any lock structure capable of ensuring the uniqueness of the thread performing the queue operation.

[0090] In another possible example, the computer device can create a second initial queue corresponding to the access index based on a predetermined queue length, a head node, and a tail node, with the head and tail nodes of the second initial queue connected. For example, the computer device can create an empty queue and initialize it based on queue attributes, a head node, and a tail node to obtain a circular queue with the head and tail nodes connected as the second initial queue. For instance, the computer device can configure the queue length of the empty queue to a specified queue length and allocate memory space for the empty queue; the computer device can also configure the head and tail nodes to be connected based on the queue position of the node.

[0091] In another possible example, the computer device can create a third initial queue corresponding to the access index based on the queue attribute variable and the left pointer of the tail node. For instance, the computer device can create an empty queue and initialize it based on the queue attribute variable and the left pointer of the tail node to obtain the third initial queue. For example, the computer device can configure the initial value of the queue attribute variable for the empty queue, and configure the left pointer of the tail node to point to the empty node and the right pointer to point to the previous node. For example, in an empty queue without any added threads, the right pointer of the tail node can point to the head node or to the empty node.

[0092] It should be noted that, based on the several possible examples of the initial queue in step 2011, the computer device can use various data structures to create the corresponding initial queue. For example, the computer device can use a linked list data structure to create the first initial queue; another example is that the computer device can use an array data structure to create the second initial queue; yet another example is that the computer device can use a doubly linked list data structure to create the third initial queue.

[0093] Step 2012: The computer device adds the at least two access requests one by one to the respective queue positions of the initial queue to obtain the access queue.

[0094] The computer device can add each access request to the initial queue one by one based on the initial queue configuration information, thus obtaining the access queue. The index data corresponding to this access index can be the index data to be updated corresponding to the access index.

[0095] Based on several possible examples of the initial queue in step 2011, step 2012 can be implemented in the following three ways.

[0096] In the first method, when the initial queue is the first initial queue, the computer device adds the access requests corresponding to the successfully invoked threads to the first initial queue one by one based on the results of at least two invocations of the target lock by the threads corresponding to the two access requests, thus obtaining the first access queue.

[0097] The target lock can ensure the uniqueness of the thread performing an enqueue operation on the first initial queue. The computer device can add multiple threads one by one to the first initial queue based on the result of at least two calls to the target lock by at least one thread, with one thread performing the enqueue operation on each successful call.

[0098] For example, based on the possible scenarios of accessing the index in step 201, when one index key corresponds to one queue, the at least two access requests can be access requests to the index data corresponding to that index key; or, when one data bucket corresponds to one queue, the at least two access requests can also be access requests to the index data corresponding to any index key in the data bucket; or, when one virtual key corresponds to one queue, the at least two access requests can also be access requests to the index data corresponding to the virtual key. These correspond to scenarios one, two, and three below.

[0099] Case 1, corresponding to Method 1 in step 201, involves at least two access requests that are access requests for the index data corresponding to the index key.

[0100] This index key is the index key carried in the access request.

[0101] It should be noted that the index key can correspond to one or more index data; for example, for cached data in key-value form, the index data corresponding to key1 can include value1, value2 and value3; among them, the update events are value1 and value3; when accessing value1 is not found, the computer device creates a queue corresponding to key1, which includes at least one thread, and the at least one thread can include the thread that is accessing value1 and value3 corresponding to key1.

[0102] Case 2, corresponding to Method 2 in step 201, involves at least two access requests that are access requests for the index data corresponding to any index key in the data bucket.

[0103] This data bucket is the data bucket to which the index key carried in the access request belongs.

[0104] For example, data bucket A includes key1 and key2; the index data corresponding to key1 may include value1, value2 and value3; the index data corresponding to key2 may include value4; among them, value4, value1 and value3 are to be updated; when accessing value1 fails, the computer device creates a queue corresponding to data bucket A, which includes access requests for value1 and value3 corresponding to key1 and access requests for value4 corresponding to key2.

[0105] Case 3, corresponding to Method 3 in step 201, involves at least two access requests that are access requests for the index data corresponding to the virtual key.

[0106] This virtual key is carried in the access request. When configuring a virtual key, it can also correspond to one or more index data; case three is similar and will not be elaborated here.

[0107] It should be noted that, in addition to the cases one to three shown above, in another possible example, the at least two access requests may also be access requests for high-frequency data to be updated among multiple index data corresponding to the accessed index key, and an access queue for the high-frequency index data will be subsequently established.

[0108] In one possible implementation, the threads corresponding to the access requests can synchronously compete for the target lock to achieve a process of enqueuing access requests one by one during high-concurrency access to the cache. This step may include: the computer device, through at least one thread corresponding to an access request that has not been added to the first initial queue, performing a call operation to the target lock; in response to any thread's successful call, the computer device, based on the enqueue operation of the target lock, adds the access request corresponding to any successfully called thread to the first initial queue; the computer device repeatedly performs the call operation to the target lock and the enqueue operation until each of the at least two access requests is added to the first initial queue, thus obtaining the first access queue. For example, the enqueue operation refers to the operation of adding a thread to the first initial queue. The computer device can add each access request to the first initial queue sequentially by repeatedly executing the process. For example, the computer device can repeatedly perform the following step ac to enqueue multiple access requests one by one, which includes:

[0109] Step a: During each repeated execution, run the thread corresponding to each access request that is not currently added to the first initial queue to perform the call operation on the target lock of the first initial queue.

[0110] Computer devices can invoke the target lock through the target lock invocation interface provided by the operating system. For example, taking a mutex as an example, locking the enqueue operation with a mutex can ensure that the enqueue process of each access request is an atomic operation. That is, it can be ensured that the next access request can be enqueued only after the previous access request has been successfully enqueued, and that each queue position in the initial queue can only accommodate one access request.

[0111] For example, a mutex lock is configured with status information, which can indicate whether the mutex lock is currently being invoked. When the status information indicates that the mutex lock is in an unacquired state, that is, it is not currently being invoked, multiple threads can attempt to acquire the lock, that is, attempt to invoke the mutex lock.

[0112] Step b: When any thread successfully calls the lock, stop other threads from calling the target lock; and lock the currently running thread to perform the enqueue operation only, so as to add the access request corresponding to the thread to the first initial queue.

[0113] When any thread successfully calls the mutex, the mutex's state information can switch to the acquired state. At this time, other threads besides that thread stop calling the mutex; that is, the thread that successfully calls the mutex acquires ownership of the mutex and performs an enqueue operation to add the access request corresponding to that thread to the queue until the thread releases the mutex. When the mutex's state information switches to the unacquired state, other threads besides that thread can continue to try to call the mutex.

[0114] For example, the process of performing an enqueue operation may include: requesting storage space corresponding to a new node in the initial queue from memory, storing the access information of the access request corresponding to the thread in the new node, and updating the queue length variable and memory usage variable based on the new node; wherein, the access information may include: the access index carried by the access request and the thread identifier of the thread corresponding to the access request; wherein, the access index can be an index key or a virtual key, and the thread identifier can be a thread number. This mutex lock can guarantee the uniqueness of the thread performing the enqueue operation, that is, only one access request is currently performing the enqueue operation until the access request is enqueued and releases the mutex lock, and then the time slice is locked to run the next thread that successfully calls the mutex lock.

[0115] Step c: When the thread finishes performing the enqueue operation, release the target lock.

[0116] When the thread finishes its enqueue operation, the access request corresponding to the thread is successfully enqueued; the computer device switches the target lock's state information to the unacquired state.

[0117] By creating a first initial queue and locking the queue based on a target lock, multiple access requests are enqueued one by one. Each queue position corresponds to only one access request. The next access request can only be enqueued after the previous access request is enqueued and its corresponding thread releases the target lock, ensuring the orderliness of the enqueueing process and further guaranteeing the accuracy of the determined first access queue. Moreover, the size of this first initial queue is unlimited, and new nodes can be requested in real time based on the memory space to enqueue new threads. While ensuring the accuracy of enqueuing access requests one by one, the first access queue can also accommodate a large number of high-concurrency requests, ensuring the high availability of the determined first access queue and further improving the applicability of data updates.

[0118] In the second method, when the initial queue is the second initial queue, the computer device adds the access request corresponding to each thread to the second initial queue one by one based on the operation result of the thread corresponding to the at least two access requests on the current tail node position of the second initial queue, thus obtaining the second access queue.

[0119] Similarly to the first method, the at least two access requests can correspond to the three cases from case one to case three in the first method mentioned above.

[0120] The computer device can perform a comparison and swap operation on the current tail node using at least two threads corresponding to access requests, and add the access request corresponding to each thread that succeeds to a second initial queue, thus obtaining a second access queue. In one possible example, the process may include: the computer device comparing the memory address and the target address of the current tail node using at least one thread corresponding to an access request that has not yet been added to the second initial queue; the computer device swapping the memory address and the target address when the comparison result of any thread meets a first target condition; the computer device adding the access request corresponding to any thread whose comparison result meets the first target condition to the second initial queue based on the queue position determined by the comparison and swap operation; the computer device repeatedly performing the comparison and swap operation on the current tail node and the operation of adding to the second initial queue when the operation succeeds, until each of the at least two access requests is added to the second initial queue or until the current queue length of the second initial queue reaches a predetermined queue length, thus obtaining the second access queue. For example, the current tail node is the tail position of the queue, which can store the last access request enqueued in the second initial queue up to the current time; for example, the memory address of the current tail node is used to store the access information of the access request queued at the tail.

[0121] The first target condition can be that the memory address is the same as the expected address. For example, the memory address is the actual address of the current tail node; the expected address is the standard value expected when the compare-and-swap operation is performed, which can be the old value of the memory address before the compare-and-swap operation ends. The target value is the queue storage address corresponding to the thread currently to be added to the queue.

[0122] For example, for a request H currently waiting to be added to the queue, if the memory address is different from the expected address, it means that the actual address is different from the old value before the thread h corresponding to request H completed the comparison and swap operation. That is, another thread corresponding to a request has successfully completed the comparison and swap operation and been enqueued, so the actual value of the memory address is no longer the old value before the thread h completed the comparison and swap operation. When the memory address is the same as the expected address, it means that the actual address is the same as the old value before the thread h completed the comparison and swap operation. That is, no other request has successfully completed the comparison and swap operation, so the actual address of the memory address is still the old value before the thread h completed the comparison and swap operation. Therefore, the memory address can be swapped with the target value, and the request H waiting to be added to the queue can be added to the current tail node position after the memory address is updated; for example, the value of the memory address of the current tail node can be updated to the target value, and the access information of request H can be stored in the updated memory address accordingly. The target value can be the address following the memory address of the current tail node. For example, if the current tail node is the 13th node in the second initial queue, meaning there are already 13 requests in the queue, then the target value can be the memory address of the 14th node.

[0123] The computer device runs a thread corresponding to each access request that is not yet added to the second initial queue. This thread performs a comparison and swap operation between the memory address, expected address, and target value of the current tail node, and adds the access request corresponding to the thread that succeeds to the second initial queue. Specifically, for each thread corresponding to an access request, the process of performing the comparison and swap operation includes: the computer device running the thread to compare the memory address of the current tail node with the expected address; when the comparison result shows that the memory address and expected address are the same, the computer device swaps the memory address with the target value, which indicates the queue storage address corresponding to the access request of the thread in the queue; that is, the new memory address of the current tail node is the target value; based on this queue storage address, the computer device adds the access request corresponding to the thread to the new position of the current tail node, that is, stores the access information in the memory address of the target value. When the comparison result shows that the memory address and expected address are different, it indicates that the comparison result of an existing thread is the same and the swap was successful, and the computer device re-attempts to perform the comparison and swap operation through this thread. When the previous thread successfully enqueues the corresponding access request based on the comparison and swap operation, the computer device continues to run the threads corresponding to the remaining access requests that have not been added to the second initial queue to perform the comparison and swap operation, and enqueue the access requests corresponding to the threads that succeeded in this operation again; until each access request is added to the second initial queue, or until the current queue length of the second initial queue reaches the predetermined queue length, thus obtaining the second access queue.

[0124] It should be noted that the computer device can run multiple threads simultaneously to attempt comparison and swap operations. When the comparison result of any thread meets the first target condition, the access request corresponding to that thread is added to the second initial queue. Then, the computer device attempts to perform the comparison and swap operation through other threads that are not in the second initial queue, and again enqueues the access request corresponding to a thread whose comparison result meets the first target condition. This continues until the second initial queue is full or all access requests have been enqueued. Of course, when the second initial queue is full but there are still access requests that have not been enqueued, the unenqueued access requests can be temporarily configured as out-of-queue waiting requests. After the computer device executes step 203 to dequeue each thread in the second access queue, the out-of-queue waiting requests can be enqueued. Alternatively, the computer device can directly execute the access operation corresponding to the out-of-queue waiting request after updating the data based on the subsequent step 202.

[0125] By creating a second initial queue of predetermined length, atomic comparison and swap operations can be used to enqueue multiple access requests one by one, ensuring the orderliness of the enqueueing process and the accuracy of the second access queue. Furthermore, since the head and tail of the second initial queue are connected, when an access request is enqueued, the operation only needs to be performed based on the memory address of the tail node. The operation is convenient and simple, enabling the system to quickly execute the determination process of the second access queue while maintaining high performance, improving the system's resource utilization, and further enhancing the accuracy and usability of data updates.

[0126] The third method, when the initial queue is the third initial queue, is to add the access request corresponding to each thread to the third initial queue one by one, based on the operation result of the pointer of the current tail node of the third initial queue corresponding to the threads of the at least two access requests, so as to obtain the third access queue.

[0127] Similarly to the first method, the at least two access requests can correspond to the three cases from case one to case three in the first method mentioned above.

[0128] The computer device can perform a comparison and swap operation on the pointer address of the current tail node through the threads corresponding to at least two access requests, and add the access request corresponding to each thread that succeeds in the operation to the second initial queue, thus obtaining the second access queue. This process may include: the computer device comparing the address pointed to by the left pointer of the current tail node with the expected address pointed to by the thread corresponding to at least one access request that has not been added to the third initial queue; the computer device swapping the pointer address and the target pointer address when the comparison result of any thread meets the second target condition; the computer device adding the access request corresponding to any thread whose comparison result meets the second target condition to the third initial queue based on the target pointer address determined by the comparison and swap operation; the computer device repeatedly performing the comparison and swap operation on the current tail node and the operation of adding to the third initial queue when the operation succeeds, until each of the at least two access requests is added to the third initial queue, thus obtaining the third access queue. For example, the current tail node is the tail position of the queue and can store the last access request enqueued in the second initial queue up to the current time; the address pointed to by the left pointer of the current tail node is a null address. In this third access queue, each node is configured with a left pointer and a right pointer. For intermediate nodes other than the head and tail nodes, the left pointer of each node points to the next node after it, and the right pointer points to the previous node before it. For the head node, the right pointer points to a null address, and the left pointer points to the next node after it. For the tail node, the left pointer points to a null address, and the right pointer points to the previous node before it.

[0129] The second target condition can be that the pointed address is the same as the expected pointed address. For example, the pointed address of the left pointer is the actual pointed address stored in memory; the expected pointed address is the standard value expected when the compare-and-swap operation is performed, which can be the old value of the pointed address before the compare-and-swap operation ends, i.e., a null address. The target pointed address is the queue storage address corresponding to the access request to be added to the queue, that is, the address of the new node in the third initial queue.

[0130] For example, for a request K to be added to the queue, if the actual pointer address is different from the expected pointer address, it means that the actual pointer address is different from the old value before the thread k corresponding to request K completed the comparison and swap operation. The actual pointer address of the current tail node is not empty, that is, another thread has successfully performed the comparison and swap operation and enqueued the request, so the actual pointer address is no longer empty. When the pointer address is different from the expected pointer address, the right pointer of the new node can be readjusted to point to the address of the current tail node, and the tail node can be repositioned. Based on the repositioned tail node, the comparison and swap operation can be performed again. For example, the left pointer of the current tail node before the repositioned tail node can be used to find the node after the current tail node as the repositioned tail node. When the pointer address is the same as the expected pointer address, that is, no other thread has successfully performed the comparison and swap operation, so the actual pointer address is still empty. Therefore, the pointer address can be swapped with the target pointer address, and request K can be added to the target pointer address, so that the current tail node points to the node where the target pointer request K is located, and the node where request K is located becomes the new tail node. The target address can be the address of a new node; for example, if the current tail node is the 5th node in the third initial queue, the target address can be the address of the newly added 6th node.

[0131] The computer device creates a new node in the third initial queue. For example, it can request space for the new node from memory and use that address as the target address. The computer device runs threads corresponding to at least two access requests that are not yet in the second initial queue to perform a comparison and swap operation between the current tail node's pointer address, the expected pointer address, and the target pointer address. Threads that successfully perform the operation are added to the third initial queue. For each thread corresponding to an access request, the process of performing the comparison and swap operation may include: the computer device runs the thread to compare the current tail node's pointer address with the expected pointer address; when the comparison result shows that the pointer address and the expected pointer address are the same, the pointer address is swapped with the target pointer address, and based on the target pointer address, the access request corresponding to the thread is added to the position of the new node. The target pointer address is the queue storage address corresponding to the thread in the queue. At this time, the new node is the new current tail node, and the left pointer of the old current tail node points to the new node. When the comparison result shows that the pointer address and the expected pointer address are different, it indicates that the comparison result of an existing thread is the same and the swap was successful. The computer device then re-attempts to perform the comparison and swap operation through that thread. When the previous thread successfully enqueues the corresponding access request based on the comparison and swap operation, the computer device continues to run the threads corresponding to the remaining access requests that have not been added to the third initial queue to perform the comparison and swap operation, and enqueues the access requests corresponding to the threads that succeeded in this operation again, until each access request is added to the second initial queue, thus obtaining the third access queue.

[0132] It should be noted that, similar to the second method described above, the computer device can run multiple threads simultaneously to attempt comparison and swap operations. When the comparison result of any thread meets the second target condition, the access request corresponding to that thread is added to the second initial queue. Then, the computer device executes multiple other threads that are not yet added to the third initial thread to attempt comparison and swap operations, and enqueues the access request corresponding to the thread whose comparison result meets the second target condition; this continues until every access request is enqueued. It should also be noted that the queue lengths of the third access queue and the first access queue can be changed in real time; for example, when an access request needs to be enqueued, the queue length can be increased, and the corresponding memory address for the newly added node can be allocated.

[0133] For example, the comparison and swap operation in the second and third methods can be the operation of the CAS (compare and swap) instruction of the CPU of the computer device. The operation performed by the CAS instruction is an atomic operation, that is, it ensures that one and only one access request can be successfully enqueued. Other access requests that fail to be enqueued need to continue to try to execute the CAS operation to ensure the accuracy of determining the access queue.

[0134] Figure 3 A flowchart for determining a third access queue is provided in this application, such as Figure 3 As shown, the third access queue is a doubly linked list structure, with each node having a left pointer and a right pointer. The right pointer of the head node points to an empty node; the left pointer of the tail node also points to an empty node. When an access request needs to be enqueued, a new node can be constructed after the current tail node. Through a CAS operation, the left pointer of the current tail node is made to point to the newly constructed node, and the left pointer of the new node is updated to point to empty. That is, the new node is the new tail node, the current tail node is the old tail node, and the right pointer of the new tail node points to the old tail node.

[0135] In one possible implementation, the computer device may further identify the head request in the access queue. This process may include: the computer device identifying the thread at the head of the access queue as the head request. For example, the computer device may determine whether an access request is a head request when enqueuing access requests one by one. This process may include: for each access request, when adding the access request to the initial queue, the computer device detects access requests included in the initial queue other than the currently added access request using the thread corresponding to the currently added access request; in response to the initial queue not containing any access requests other than the currently added access request, the computer device determines the currently added access request as the head request; in response to the initial queue containing any access requests other than the currently added access request, the computer device switches the state of the thread corresponding to the currently added access request to a suspended state.

[0136] In one possible example, for the second approach described above, the computer device can calculate the number of access requests included in the initial queue based on the positions of the head and tail nodes of the initial queue when adding an access request to it. For example, the difference between the queue positions of the head and tail nodes can be used as the number of requests included in the initial queue. When the number of requests is the target number, it means that the initial queue currently only includes the access request other than the one currently added, and the computer device determines that the thread currently added is the head request. When the number of requests is not the target number, it means that the initial queue already has other requests, and the computer device determines that the thread corresponding to the currently added access request is a waiting thread and switches the state of the waiting thread to a suspended state. For example, the target number can be 1, that is, when the difference between the head and tail nodes is 1, meaning that the queue only contains the currently added request, the currently added request is the first enqueue request, and the thread corresponding to this request is the leader thread. When the difference between the queue positions of the head and tail nodes is not 1, for example, 2, the thread is a waiting thread. For the first and third methods, the computer device can determine whether the node containing the access request is the head node when adding the access request to the initial queue. If the node is the head node, the access request is determined to be a head request; otherwise, the state of the waiting thread corresponding to the access request is switched to a suspended state. For example, in the first method, if the node containing the access request is at the head of the queue, that node is the head node; otherwise, it is not. For example, in the third method, if the right pointer of the node containing the thread points to null, the access request is determined to be a head request; otherwise, the state of the waiting thread corresponding to the access request is switched to a suspended state.

[0137] By creating a third initial queue and using atomic comparison and swap operations, multiple access requests are enqueued one by one, ensuring the orderliness of the enqueueing process and the accuracy of the second access queue. Furthermore, through tail node-based operations, the left pointer of the latest tail node is kept pointing to an empty node. When an access request is enqueued, only a CAS operation on the left pointer of the tail node is needed to complete the enqueueing process of a new access request. New nodes can also be created in real time based on enqueueing needs, which is highly flexible and convenient, thus ensuring the high flexibility and accuracy of the determination process of the third access queue.

[0138] Step 202: The computer device updates the index data that matches each access request in the access queue based on the header requests in the access queue.

[0139] This header request is an access request located at the head node of the access queue. The index data matching the access request refers to the index data corresponding to its access index; for example, the index data that each access request needs to access based on an access index. The computer device can use this header request to update the index data corresponding to the access index in the cache database based on the access index that matches each access request in the access queue. For example, the computer device runs a header thread corresponding to the header request, pulls the data corresponding to the access index from the target resource, and performs the process of updating the index data. The target resource includes at least one of the target database, target service, target interface, and target instance of the index data. For example, the computer device pulls the data corresponding to the access index from the target database; or, the computer device runs a header thread, calls at least one of the target service, target interface, and target instance to obtain the data corresponding to the access index. For example, calling a weather service to obtain the latest weather data to update the cache database.

[0140] Corresponding to the three correspondences between the access index and the access queue in methods one to three of step 201 above, the corresponding methods for updating the index data corresponding to the access index in this step include the following two.

[0141] In the first method, the computer device uses the header thread corresponding to the header request to retrieve the data corresponding to the index key from the target resource based on the index key corresponding to each access request in the access queue, and updates the retrieved data corresponding to the index key in the cache database with the index data corresponding to the index key.

[0142] Corresponding to Method 1 in step 201, when one index key corresponds to one queue, each access request in the access queue corresponds to one index key; the computer device can run a head thread to execute the update process of the index data corresponding to the index key. For example, for the access queue corresponding to key1, the head thread in the access queue can pull the values11, value12, and value13 corresponding to key1 from the target database, and update the index data corresponding to key1 in the cache database to values11, value12, and value13.

[0143] In one possible example, the computer device can retrieve the data to be updated corresponding to the index key from the target resource based on the index data to be updated corresponding to the index key, and update the index data to be updated corresponding to the index key in the cache database with the retrieved data to be updated. For example, for the access queue corresponding to key1, the index data corresponding to key1 includes value1, value2, and value3, where value1 and value3 are the index data to be updated. Then, the head thread can retrieve value11 and value13 corresponding to key1 from the target database, and update value1 and value3 corresponding to key1 in the cache database with value11 and value13.

[0144] Corresponding to Method 2 in step 201, when one data bucket corresponds to one queue, each access request in the access queue can correspond to multiple index keys. The computer device can run a head thread to execute the update process of the index data corresponding to any index key in the data bucket. For example, the computer device can run a head thread to traverse the access indexes carried by each access request in the access queue, that is, the index keys. For example, for each access queue corresponding to a data bucket, the head thread in the access queue performs the following steps: the computer device obtains each index key carried by each access request in the access queue, and based on the obtained index keys, pulls the data corresponding to each index key from the target resource; and updates the index data corresponding to each index key in the cache database.

[0145] For example, data bucket A includes key1 and key2; key1 corresponds to value1, value2 and value3; key2 corresponds to value4; the computer device detects the threads corresponding to the index keys key1 and key2 of data bucket A; and pulls the data corresponding to key1 and key2 from the target resource.

[0146] In the second method, the computer device uses the head thread to retrieve the data corresponding to the virtual key from the target resource based on the virtual key corresponding to each access request in the access queue, adds the virtual key to the cache database, and updates the retrieved data corresponding to the virtual key to the index data corresponding to the virtual key in the cache database.

[0147] Corresponding to method three in step 201, the computer device can run a head thread to execute the update process of the index data corresponding to the virtual key. When the target resource does not contain the data corresponding to the virtual key, that is, when the computer device fails to retrieve the data, the computer device can delete the virtual key from the cache database and remove the access queue corresponding to the virtual key. For example, the computer device can return a prompt message indicating access failure or that the data is missing.

[0148] For example, corresponding to virtual key3, the virtual index data value01 corresponding to virtual key3 is retrieved from the target database; and the value01 corresponding to key3 is saved in the cache database.

[0149] In one possible implementation, the access request indicates an access operation for the data to be accessed. This access operation may include read operations, write operations, and operations such as add, modify, and delete. Therefore, before updating the cached data, the specified access operation may be executed first. The process of executing the specified access operation before the update process based on the head thread includes: the computer device, through the head thread corresponding to the head request, performing a search operation on the threads included in the access queue. This search operation is used to find the specified request for a specified access operation on the index data in the access queue; in response to the access queue including the specified request, the computer device, through the head thread, executes the specified access operation on the index data; wherein the specified request includes any one of: a write request for a write operation, an add request for an add operation, a modify request for a modify operation, and a delete request for a delete operation. In one possible example, when the access queue includes at least two specified requests, the computer device can selectively execute or merge executions based on a certain conflict strategy. The step of executing a specified access operation through the head thread can include: the computer device performing conflict detection on the at least two specified requests through the head thread; when there is no conflict between the at least two specified requests, the computer device executing at least two specified access operations for the at least two specified requests through the head thread; and when there is a conflict between the at least two specified requests, the computer device executing the target specified operation of the request that conforms to the conflict strategy among the at least two specified requests through the head thread. In one example, when there is no conflict between at least two specified requests, the computer device can merge the specified access operations of the at least two specified requests and execute the merged access operation. For example, for three write requests whose content is all to increment the current value by 1, the computer device can merge the three write requests, that is, merge the three increments of the current value by 1 into an operation to increment the current value by 3, and execute the operation of incrementing the current value by 3. In another example, the conflict strategy may include, but is not limited to, the request with the earliest queue position, the earliest timestamp of the access request, the latest enqueue order, and the highest configuration priority. When there is a conflict between at least two specified requests, one or more target specified access requests that meet the conflict strategy can be selected for execution. For example, write request A changes the value from the current 0 to 1, and another write request B changes the value from the current 0 to 5. There is a conflict between the requests corresponding to the two requests. Based on different strategies, the specified access operation with the earliest time, the latest enqueue order, and the highest priority can be selected for execution. It should be noted that during the process of updating the cached data based on the head thread in step 202, new access requests may still be enqueued based on step 2012. Whenever a new access request is enqueued, the thread corresponding to the new access request is switched to a suspended state so that it can be woken up by the head thread in subsequent steps based on step 203.

[0150] By having the update process executed solely by the header thread corresponding to the header request, a large number of access requests do not need to penetrate to the backend server, ensuring the stability and security of the system. Furthermore, header requests can update the index data corresponding to the index key of the access queue based on different access indexes; alternatively, header requests can update the index data corresponding to each index key within the data bucket corresponding to the access queue based on data buckets; or header requests can add or synchronize backend data to the cache database in real time based on virtual keys. This approach caters to the diverse needs and scenarios of updates, satisfying data update requirements in various situations as much as possible. Simultaneously, it avoids system crashes under high concurrency and solves problems such as easy update errors and dirty data generation caused by a large number of simultaneous repeated updates under high concurrency, ensuring the reliability, accuracy, and stability of the data update process.

[0151] Step 203: The computer device wakes up at least one waiting thread in the access queue corresponding to an access request other than the header request, based on the header thread corresponding to the header request.

[0152] In response to a successful update of index data matching each access request, the computer device, through the head thread, removes at least two access requests from the access queue one by one and wakes up the waiting threads corresponding to the removed access requests. For example, the computer device can remove each access request from the access queue one by one and wake up the waiting threads corresponding to each removed access request one by one. Exemplarily, the computer device runs a head thread to perform dequeue operations on multiple threads in the access queue one by one and wakes up the dequeueed threads one by one; the dequeue operation refers to removing a thread from the access queue.

[0153] Corresponding to the three methods of creating access queues shown in the first to third methods in step 2012, the dequeue operation in step 203 includes the following three types.

[0154] In the first method, for the first access queue, the computer device, through the head thread, calls the target lock of the first access queue to remove each access request included in the first access queue one by one from the queue.

[0155] The computer device can remove access requests based on the process of calling the target lock. For example, the computer device can execute the call operation to the target lock through a head thread. Upon successful call, based on the dequeue operation of the target lock, multiple access requests enclosed in the first access queue are removed from the queue. When each access request in the first access queue is removed, the first access queue is empty, and the computer device can release the target lock. For example, the target lock can be a mutex lock. The computer device can call the target lock according to the order of the access requests in the first access queue and perform dequeue operations on the access requests one by one according to this order, so as to dequeue each access request in the order of arrangement. It should be noted that in this step, the computer device can call the target lock once during dequeueing. Upon successful call, each access request in the access queue is removed from the queue until the first access queue is empty, at which point the target lock is released. The process by which the computer device calls the target lock through the head thread and performs the dequeueing operation of each access request is similar to the process in the first method of step 2012, where multiple threads call the target lock to enqueue the corresponding access requests one by one. It will not be described in detail here.

[0156] In one possible implementation, the access information for each request may also include a status code for the access request. That is, the access information includes: the access index, the thread identifier of the corresponding thread, and the status code. The status code is used to indicate whether the head thread has successfully updated the index data. When the status code is updated, it means that the head thread has successfully updated the index data. When the status code is not updated, it means that the head thread has not successfully updated the index data.

[0157] In one possible example, for each access request in the first access queue, when the computer device removes the access request from the queue via the head thread, the computer device modifies the status code of the access request to "updated" via the head thread and wakes up the thread corresponding to the access request. Specifically, the computer device uses the head thread to determine whether the data to be accessed by the access request has been updated when the access request is dequeued. For example, based on the access index carried in the access request, the status code in the access information can be modified to "updated" when the head thread successfully updates the index data corresponding to that access index.

[0158] In the second approach, for the second access queue, the computer device, through the head thread, removes each access request from the queue one by one based on the operation result of the current head node position of the second access queue.

[0159] Through the head thread, the computer device can compare the memory address and expected address of the current head node; in response to the comparison result meeting the third target condition, the memory address and target address of the head node are swapped; based on the head node queue position determined by the comparison and swap operation, the access request for the current head node is removed from the queue, and the comparison and swap operation for the current head node and the operation of removing it from the queue upon successful operation are repeated until every access request in the second access queue is removed from the queue. For example, for a CAS operation, the memory address of the head node is the actual storage address of the head node, and the expected address of the head node can be the standard value before the current comparison and swap operation or the old value before the current comparison and swap operation. The target address of the head node is the address of the second node in the second access queue after the current head node. When the actual storage address is the same as the old value, the computer device determines the uniqueness of the thread performing the dequeue operation, swaps the memory address of the head node with the target address of the head node, updates the actual address of the head node to the address of the second node, and removes the access request currently located at the head node from the queue according to the order of the access requests in the second access queue; at this time, the second node becomes the new head node, and so on.

[0160] In one possible example, similar to the first approach in step 203, for each access request in the second access queue, when the computer device removes the access request from the queue via the head thread, the computer device modifies the status code of the access request to "updated" and wakes up the waiting thread corresponding to the access request.

[0161] It should be noted that the process of the computer device performing the comparison and swap operation and removing access requests one by one through the head thread is the same as the process of performing the comparison and swap operation and enqueuing access requests one by one through multiple threads in the second method of step 2012, and will not be described in detail here.

[0162] The third method, for the third access queue, involves the computer device removing each access request from the queue one by one through the head thread, based on the result of the operation on the queue head pointer of the third access queue.

[0163] The queue head pointer is an attribute variable of the third access queue, and its value is the memory address of the head node of the third access queue. Through the head thread, the computer device can compare the value of the queue head pointer with the expected address of the head node; in response to the comparison result meeting the fourth target condition, the value of the queue head pointer and the target value of the head pointer are swapped; based on the head pointer target value determined by the comparison and swap operation, the access request for the current head node is removed from the queue, and the comparison and swap operation of the queue head pointer and the removal of requests from the queue upon successful operation are repeatedly executed until every access request in the third access queue is removed from the queue. For example, the value of the queue head pointer is the address of the head node, that is, the actual memory address of the head node; the expected address of the head node can be the standard value of the head node's address, that is, the memory address of the head node before the head thread performs the comparison and swap operation. The target value of the head pointer is the address of the next node after the head node. When the value of the queue head pointer is the same as the expected address of the head node, it means that the actual memory address of the head node is the same as the memory address of the head node before the head thread performed the comparison and swap operation. The computer device swaps the value of the queue head pointer and the target value of the head pointer, and removes the access request located at the current head node from the queue according to the order of the access requests in the third access queue. The next node in the third access queue after the current head node becomes the new head node, and the value of the queue head pointer is the address of the next node.

[0164] In one possible example, similar to the first approach in step 203, for each access request in the third access queue, when the computer device removes the access request from the queue via the head thread, the computer device modifies the status code of the access request to "updated" and wakes up the waiting thread corresponding to the access request.

[0165] It should be noted that the process by which the computer device performs the comparison and swap operation and removes the access requests one by one through the head thread is the same as the process in the third method of step 2012, which performs the comparison and swap operation and enqueues the access requests one by one through multiple threads. It will not be described in detail here.

[0166] In one possible example, the computer device can also be configured with a maximum number of wake-up threads. The device can run a head thread to wake up waiting threads one by one. When the maximum number of wake-up threads is reached, the device can reselect a first thread to wake up the remaining waiting threads. For example, this first thread could be the last waiting thread woken up by the head thread, and the device can run this first thread to wake up the remaining waiting threads. For instance, thread A wakes up the first 50 threads in a queue of 100 threads, and the 50th thread, B, wakes up the remaining 50 threads.

[0167] By waking up waiting threads one by one through the head thread, the waiting threads are switched from a suspended state to a state where they can perform access operations. This satisfies the access needs of a large number of requests without requiring access requests to penetrate the backend server. Furthermore, for different access queues, the head thread corresponding to the head request executes the corresponding dequeue process for each access request. This provides enqueue and dequeue processes for various access queues to meet the needs of different scenarios. Under high concurrency, appropriate methods can be selected to create access queues as needed, and data can be updated and accessed based on the access queues. This ensures the stable and reliable operation of the entire update and access process, improving the practicality and reliability of the data update process.

[0168] Step 204: The computer device accesses the updated index data based on the threads corresponding to at least two access requests in the access queue.

[0169] The computer device executes access operations on the updated index data through awakened waiting threads. The computer device can run at least one awakened waiting thread, each waiting thread performing access operations on the updated index data based on the access index carried in the corresponding access request. In one possible example, when a waiting thread is awakened, the computer device runs the waiting thread to check whether the status code of the corresponding access request is updated; if it is updated, the waiting thread continues to run and execute the corresponding access operation.

[0170] In one possible example, the header request can achieve data access by executing an update process. That is, the header request performs a data update process based on the header thread to complete the access operation of the header request, and the computer device may not need to execute the access operation of the header request in step 204. Of course, the computer device may also execute the access operation corresponding to the header request in step 204 after the update process is completed based on the header request. This application embodiment does not specifically limit whether an access operation is still executed after the header request updates the index data.

[0171] Figure 4 A flowchart for data updating provided in this application, such as Figure 4 As shown, when a business needs to access data, a query cache operation is performed on the cache storage. When the cached data to be accessed needs to be updated, it enters the update queue corresponding to the index key based on the access index; for example... Figure 4As shown, there are currently N queues, each corresponding to an index key. The computer device adds the access request to the corresponding queue 1 based on the thread corresponding to the current access request. If there is already an access request in queue 1, the thread corresponding to the currently added access request is switched to a suspended waiting thread. The computer device then uses the head request of the head node at the head of queue 1 to pull data from the backend service or database, updates the index data based on the pulled data, updates the cached data, and wakes up the waiting threads included in queue 1. The woken-up waiting threads directly access the data in the cache.

[0172] The data update method provided in this application, when data updates are triggered by at least two access requests, first determines an access queue based on the access index, thereby achieving unified and convenient management of multiple access requests accurately centralized in the queue. The head request in the access queue updates the index data matching each access request in the access queue. The head thread corresponding to the head request wakes up the waiting threads corresponding to the other access requests, so that the other access requests can directly access the index data updated by the head request without having to perform the update repeatedly. This avoids repeated updates by a large number of access requests. Especially in high-concurrency scenarios, it can prevent massive requests from penetrating the backend device and avoid update errors, dirty data, operating system crashes, and other problems caused by simultaneous repeated updates by massive requests. This ensures the accuracy and reliability of the data update process.

[0173] Furthermore, access queues can be determined based on access indexes, and multiple access requests can be precisely divided into various access queues according to the access indexes. This can include various methods such as one access queue corresponding to one index key, one location queue corresponding to one data bucket, or one location queue corresponding to a virtual key. This allows for flexible selection based on needs, improving the flexibility and accuracy of subsequent data updates and data access based on access queues, and enhancing the applicability of the data update process in this application.

[0174] Furthermore, it provides three access queues: a first access queue based on target lock locking operations, which ensures the uniqueness of the thread executing the queue operation and guarantees the accuracy of the determination process of the first access queue; a second access queue with a predetermined length and a third access queue with a doubly linked list structure, all of which can be used to ensure that each access request is accurately enqueued through CAS operations, making the operation flexible and convenient, and further improving the flexibility and processing efficiency of the data update process.

[0175] Furthermore, it provides multiple ways to update index data via header requests, allowing updates to both index data corresponding to index keys and index data corresponding to virtual keys, meeting diverse scenario requirements, avoiding system crashes under high concurrency requests, and solving problems such as easy update errors and dirty data generation caused by a large number of threads repeatedly updating simultaneously under high concurrency, thus ensuring the reliability, accuracy, and stability of the data update process.

[0176] Figure 5 This is a schematic diagram of a data update device provided in an embodiment of this application. Figure 5 As shown, the device includes:

[0177] The queue determination module 501 is used to determine an access queue based on the access index corresponding to the at least two access requests that trigger data updates in response to at least two access requests. The access queue includes at least two access requests, and any access request is used to access index data corresponding to its access index.

[0178] The update module 502 is used to update the index data that matches each access request in the access queue based on the head request in the access queue. The head request refers to the access request located at the head node of the access queue.

[0179] The wake-up module 503 is used to wake up at least one waiting thread in the access queue corresponding to an access request other than the head request, based on the head thread corresponding to the head request. The waiting thread is used to wait to execute the access operation of the corresponding access request.

[0180] Access module 504 is used to access the updated index data based on the threads corresponding to at least two access requests in the access queue.

[0181] In one possible implementation, the access index includes an index key or a virtual key; the queue determination module 501 is also used for any of the following:

[0182] Based on the index key, the access queue corresponding to the index key is determined, and the access queue corresponding to the index key includes at least two access requests to access the index data corresponding to the index key.

[0183] Based on the data bucket to which the index key belongs, determine the access queue corresponding to the data bucket. The access queue corresponding to the data bucket includes at least two access requests for accessing the index data corresponding to any index key in the data bucket.

[0184] Based on the virtual key, the access queue corresponding to the virtual key is determined. The access queue corresponding to the virtual key includes at least two access requests for the index data corresponding to the virtual key to be accessed. The virtual key refers to an index key that does not exist in the cache database to be accessed.

[0185] In one possible implementation, the queue determination module 501 includes:

[0186] Create a unit to respond to at least two access requests that trigger a data update, and create an initial queue corresponding to the access index based on the access index;

[0187] An add unit is used to add the at least two access requests one by one to the respective queue positions of the initial queue to obtain the access queue.

[0188] In one possible implementation, the creation unit is also used for any of the following:

[0189] Based on queue attribute variables and the target lock of queue operations, a first initial queue corresponding to the access index is created. The target lock is used to lock the uniqueness of the thread performing queue operations on the first initial queue. The queue operation includes at least one of enqueue operation and dequeue operation. The queue attribute variables include at least one of queue length variable and memory usage variable.

[0190] Based on the predetermined queue length, head node, and tail node, create a second initial queue corresponding to the access index, with the head node and tail node of the second initial queue connected together;

[0191] Based on the queue attribute variable and the left pointer of the tail node, create the third initial queue corresponding to the access index.

[0192] In one possible implementation, the added unit is also used for any of the following:

[0193] When the initial queue is the first initial queue, based on the results of at least two calls to the target lock by the threads corresponding to the at least two access requests, the access requests corresponding to the threads that successfully made the calls are added to the first initial queue one by one to obtain the first access queue;

[0194] When the initial queue is the second initial queue, based on the operation result of the thread corresponding to the at least two access requests on the current tail node position of the second initial queue, the access requests corresponding to each thread are added to the second initial queue one by one to obtain the second access queue;

[0195] When the initial queue is the third initial queue, based on the operation result of the pointer of the current tail node of the third initial queue by the thread corresponding to the at least two access requests, the access request corresponding to each thread is added to the third initial queue one by one to obtain the third access queue.

[0196] In one possible implementation, the adding unit is further configured to execute a call operation on the target lock by the thread corresponding to at least one access request that has not been added to the first initial queue; in response to a successful call by any thread, based on the enqueue operation of the target lock, the access request corresponding to the successful call is added to the first initial queue, and the call operation on the target lock and the enqueue operation are repeated until each of the at least two access requests is added to the first initial queue, thereby obtaining the first access queue.

[0197] In one possible implementation, the adding unit is further configured to compare the memory address of the current tail node with the expected address using the thread corresponding to at least one access request that has not been added to the second initial queue; swap the memory address and the target address when the comparison result of any thread meets the first target condition; add the access request corresponding to any thread whose comparison result meets the first target condition to the second initial queue based on the queue position determined by the comparison and swap operation; repeat the comparison and swap operation of the current tail node and the operation of adding to the second initial queue when the operation is successful until each of the at least two access requests is added to the second initial queue or until the current queue length of the second initial queue reaches the predetermined queue length, thereby obtaining the second access queue.

[0198] In one possible implementation, the adding unit is further configured to compare the address pointed to by the left pointer of the current tail node with the expected address pointed to by the thread corresponding to at least one access request that has not been added to the third initial queue; in response to the comparison result of any thread meeting the second target condition, swap the pointer address and the target pointer address; based on the target pointer address determined by the comparison and swap operation, add the access request corresponding to any thread whose comparison result meets the second target condition to the third initial queue, and repeat the comparison and swap operation of the current tail node and the operation of adding to the third initial queue when the operation is successful, until each of the at least two access requests is added to the third initial queue, thereby obtaining the third access queue.

[0199] In one possible implementation, the device further includes:

[0200] The detection module is used to, for each access request, detect, through the thread corresponding to the currently added access request, all other access requests included in the initial queue besides the currently added access request when the access request is added to the initial queue.

[0201] The head thread determination module is used to determine the currently added access request as the head request when the initial queue does not contain any access request other than the currently added access request.

[0202] The switching module is used to switch the state of the thread corresponding to the currently added access request to a suspended state when the initial queue includes any access request other than the currently added access request.

[0203] In one possible implementation, update module 502 is also used for at least one of the following:

[0204] Using the header thread corresponding to the header request, based on the index key corresponding to each access request in the access queue, the data corresponding to the index key is retrieved from the target resource, and the retrieved data corresponding to the index key is updated to the index data corresponding to the index key in the cache database;

[0205] Through this head thread, based on the virtual key corresponding to each access request in the access queue, the data corresponding to the virtual key is pulled from the target resource, and the virtual key is added to the cache database. The pulled data corresponding to the virtual key is then updated to the index data corresponding to the virtual key in the cache database.

[0206] The target resource includes at least one of the target database, target service, target interface, and target instance of the index data.

[0207] In one possible implementation, the device further includes:

[0208] The lookup module is used to perform a lookup operation on the threads included in the access queue by using the header request corresponding to the header thread. The lookup operation is used to find the specified request in the access queue that performs a specified access operation on the index data.

[0209] The specified operation execution module is used to execute the specified access operation on the index data through the head thread when the access queue includes the specified request;

[0210] The specified request includes any one of the following: a write request for a write operation, an add request for an add operation, a modify request for a modify operation, and a delete request for a delete operation.

[0211] In one possible implementation, the specified operation execution module is further configured to perform conflict detection on the at least two specified requests through the head thread; when there is no conflict between the at least two specified requests, execute at least two specified access operations on the at least two specified requests through the head thread; and when there is a conflict between the at least two specified requests, execute the target specified operation of the request that conforms to the conflict policy among the at least two specified requests through the head thread.

[0212] In one possible implementation, the wake-up module 503 is further configured to, in response to the successful update of the index data matching each access request, remove at least two access requests from the access queue one by one through the head thread, and wake up the waiting thread corresponding to the access request removed from the access queue.

[0213] In one possible implementation, the at least two access requests that trigger the data update are: an access request that misses a cache database entry or an access request that accesses expired data in the cache database.

[0214] The data update apparatus provided in this application, when data updates are triggered by at least two access requests, first determines an access queue based on the access index, thereby achieving unified and convenient management of multiple access requests accurately centralized in the queue. The head request in the access queue updates the index data matching each access request in the access queue. The head thread corresponding to the head request wakes up the waiting threads corresponding to the other access requests, so that the other access requests can directly access the index data updated by the head request without having to perform the update repeatedly. This avoids repeated updates by a large number of access requests. Especially in high-concurrency scenarios, it can prevent massive requests from penetrating the backend device and avoid update errors, dirty data, operating system crashes, and other problems caused by simultaneous repeated updates by massive requests. This ensures the accuracy of the data update process and improves the reliability of the update process.

[0215] Furthermore, access queues can be determined based on access indexes, and each access request can be precisely divided into multiple access queues according to the access index. This can include various methods such as one access queue corresponding to one index key, one location queue corresponding to one data bucket, or one location queue corresponding to a virtual key. This allows for flexible selection based on needs, improving the flexibility and accuracy of subsequent data updates and data access based on access queues, and enhancing the applicability of the data update process in this application.

[0216] Furthermore, it provides three access queues: a first access queue based on target lock locking operations, which ensures the uniqueness of the thread executing the queue operation and guarantees the accuracy of the determination process of the first access queue; a second access queue with a predetermined length and a third access queue with a doubly linked list structure, all of which can be enqueued accurately through CAS operations; the operation is flexible and simple, further improving the flexibility and processing efficiency of the data update process.

[0217] Furthermore, it provides multiple ways to update index data via header requests, allowing updates to both index data corresponding to index keys and index data corresponding to virtual keys, meeting diverse scenario requirements, avoiding system crashes under high concurrency requests, and solving problems such as easy update errors and dirty data generation caused by a large number of threads repeatedly updating simultaneously under high concurrency, thus ensuring the reliability, accuracy, and stability of the data update process.

[0218] The data update device in this embodiment can execute the data update method shown in the above embodiments of this application. The implementation principle is similar, and will not be described again here.

[0219] Figure 6 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. For example... Figure 6 As shown, the computer device includes: a memory and a processor; at least one program, stored in the memory, which, when executed by the processor, can achieve the following compared to existing technologies: when at least two access requests trigger data updates, an access queue is first determined based on the access index, thereby achieving unified and convenient management of multiple access requests accurately centralized in the queue; the head request in the access queue updates the index data matching each access request in the access queue, and the head thread corresponding to the head request wakes up the waiting threads corresponding to the other access requests, so that the other access requests can directly access the index data updated by the head request without repeating the update; thus avoiding the repeated updates of a large number of access requests, especially in high-concurrency scenarios, it can prevent the massive number of high-concurrency requests from penetrating the backend device, and avoid problems such as update errors, dirty data generation, and operating system crashes caused by the simultaneous repeated updates of massive requests, ensuring the accuracy of the data update process and improving the reliability of the update process.

[0220] In one alternative embodiment, a computer device is provided, such as Figure 6 As shown, Figure 6 The computer device 600 shown includes a processor 601 and a memory 603. The processor 601 and the memory 603 are connected, for example, via a bus 602. Optionally, the computer device 600 may further include a transceiver 604, which can be used for data interaction between the computer device and other computer devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 604 is not limited to one type, and the structure of the computer device 600 does not constitute a limitation on the embodiments of this application.

[0221] Processor 601 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 601 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0222] Bus 602 may include a pathway for transmitting information between the aforementioned components. Bus 602 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 602 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0223] The memory 603 may be a ROM (Read Only Memory) or other type of static storage device capable of storing static information and instructions, RAM (Random Access Memory) or other type of dynamic storage device capable of storing information and instructions, or an EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0224] The memory 603 stores application code (computer program) that executes the solution of this application, and its execution is controlled by the processor 601. The processor 601 executes the application code stored in the memory 603 to implement the content shown in the foregoing method embodiments.

[0225] Computer equipment includes, but is not limited to, servers, service clusters, or terminals.

[0226] This application provides a computer-readable storage medium storing a computer program that, when run on a computer, enables the computer to execute the corresponding content of the data update method in the aforementioned method embodiments.

[0227] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the data update method described above.

[0228] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0229] The above description is only a partial embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A data updating method characterized by comprising: The method comprises: determining an access queue based on access indexes corresponding to at least two access requests triggering data update, the access queue comprising the at least two access requests, any access request being used to access index data corresponding to the access index thereof; updating index data corresponding to each access request in the access queue based on a head request in the access queue, the head request being the access request at a head node of the access queue; waking up waiting threads corresponding to at least one access request in the access queue other than the head request based on a head thread corresponding to the head request, the waiting threads being used to wait for execution of access operations corresponding to the access requests; accessing the updated index data based on threads corresponding to the at least two access requests in the access queue.

2. The data updating method according to claim 1, characterized by, The access indexes comprise index keys or virtual keys; and the determining the access queue based on the access indexes corresponding to the at least two access requests comprises any of the following: determining an access queue corresponding to the index keys based on the index keys, the access queue corresponding to the index keys comprising at least two access requests to be used to access index data corresponding to the index keys; determining an access queue corresponding to a data bucket based on the data bucket to which the index keys belong, the access queue corresponding to the data bucket comprising at least two access requests to be used to access index data corresponding to any index key in the data bucket; determining an access queue corresponding to the virtual keys based on the virtual keys, the access queue corresponding to the virtual keys comprising at least two access requests to be used to access index data corresponding to the virtual keys, the virtual keys being index keys that do not exist in a cache database to be accessed.

3. The data updating method according to claim 1, characterized by, The determining the access queue based on the access indexes corresponding to the at least two access requests comprises: creating an initial queue corresponding to the access indexes based on the access indexes in response to the at least two access requests triggering data update; adding the at least two access requests to each queue position of the initial queue to obtain the access queue.

4. The data updating method according to claim 3, characterized by, The creating the initial queue corresponding to the access indexes based on the access indexes in response to the at least two access requests triggering data update comprises any of the following: creating a first initial queue corresponding to the access indexes based on a target lock of a queue attribute variable and a queue operation, the target lock being used to lock uniqueness of threads performing the queue operation on the first initial queue, the queue operation comprising at least one of an enqueue operation and a dequeue operation, and the queue attribute variable comprising at least one of a queue length variable and a memory usage variable; creating a second initial queue corresponding to the access indexes based on a predetermined queue length, a head node and a tail node, the head node and the tail node of the second initial queue being connected; creating a third initial queue corresponding to the access indexes based on a left pointer of a tail node and a queue attribute variable.

5. The data updating method according to claim 4, characterized by, The adding the at least two access requests to each queue position of the initial queue to obtain the access queue comprises: When the initial queue is a first initial queue, based on results of at least two invocations of the target lock by threads corresponding to the at least two access requests, access requests corresponding to threads that successfully invoke are added to the first initial queue one by one to obtain a first access queue; When the initial queue is a second initial queue, based on results of operations on a position of a current tail node of the second initial queue by threads corresponding to the at least two access requests, access requests corresponding to each thread are added to the second initial queue one by one to obtain a second access queue; When the initial queue is a third initial queue, based on results of operations on a pointer of a current tail node of the third initial queue by threads corresponding to the at least two access requests, access requests corresponding to each thread are added to the third initial queue one by one to obtain a third access queue.

6. The data updating method according to claim 5, characterized by, The adding, based on the results of the at least two invocations of the target lock by the threads corresponding to the at least two access requests, of the access requests corresponding to the threads that successfully invoke to the first initial queue one by one to obtain the first access queue includes: performing, by a thread corresponding to at least one access request that has not been added to the first initial queue, an invocation operation on the target lock; in response to invocation of any thread being successful, adding, based on an enqueue operation of the target lock, an access request corresponding to any thread that successfully invokes to the first initial queue, repeatedly performing the invocation operation on the target lock and the enqueue operation until each of the at least two access requests is added to the first initial queue to obtain the first access queue.

7. The data updating method according to claim 5, characterized by, The adding, based on the results of the operations on the position of the current tail node of the second initial queue by the threads corresponding to the at least two access requests, of the access requests corresponding to each thread to the second initial queue one by one to obtain the second access queue includes: performing, by a thread corresponding to at least one access request that has not been added to the second initial queue, a comparison between a memory address of the current tail node and an expected address; in response to a comparison result of any thread meeting a first target condition, swapping the memory address and the target address; based on a queue position determined by the comparison and swap operation, adding, to the second initial queue, an access request corresponding to any thread whose comparison result meets the first target condition, repeatedly performing the comparison and swap operation on the current tail node and the operation of adding to the second initial queue when the operation is successful until each of the at least two access requests is added to the second initial queue or until a current queue length of the second initial queue reaches a predetermined queue length to obtain the second access queue.

8. The data updating method according to claim 5, characterized by, The adding, based on the results of the operations on the pointer of the current tail node of the third initial queue by the threads corresponding to the at least two access requests, of the access requests corresponding to each thread to the third initial queue one by one to obtain the third access queue includes: performing, by a thread corresponding to at least one access request that has not been added to the third initial queue, a comparison between a pointing address of a left pointer of the current tail node and an expected pointing address; in response to the comparison result of any thread meeting the second target condition, swapping the address pointed to by the thread and the target address pointed to by the target thread; based on the target address pointed to by the thread determined by the compare-and-swap operation, adding the access request corresponding to any thread whose comparison result meets the second target condition to the third initial queue, and repeating the compare-and-swap operation on the current tail node and the operation of adding to the third initial queue when the operation is successful, until each access request in the at least two access requests is added to the third initial queue, obtaining the third access queue.

9. The data updating method according to claim 3, characterized by, The method further comprises: For each access request, when the access request is added to the initial queue, detecting, by the thread corresponding to the currently added access request, the access requests included in the initial queue except the currently added access request; in response to the initial queue not including any access request except the currently added access request, determining that the currently added access request is the head request; in response to the initial queue including any access request except the currently added access request, switching the state of the thread corresponding to the currently added access request to a suspended state.

10. The data updating method according to claim 1, characterized by, The updating of the index data matching each access request in the access queue based on the head request in the access queue comprises at least one of the following: pulling, by the head thread corresponding to the head request, the data corresponding to the index key from the target resource based on the index key corresponding to each access request in the access queue, and updating the pulled data corresponding to the index key as the index data corresponding to the index key in the cache database; pulling, by the head thread, the data corresponding to the virtual key from the target resource based on the virtual key corresponding to each access request in the access queue, and adding the virtual key in the cache database, and updating the pulled data corresponding to the virtual key as the index data corresponding to the virtual key in the cache database; wherein the target resource comprises at least one of a target database, a target service, a target interface, and a target instance of the index data.

11. The data updating method according to claim 1, characterized by, Before the updating of the index data matching each access request in the access queue based on the head request in the access queue, the method further comprises: performing, by the head thread corresponding to the head request, a lookup operation on the threads included in the access queue, the lookup operation being used to find a specified request in the access queue for a specified access operation on the index data; in response to the access queue including the specified request, performing, by the head thread, the specified access operation on the index data; wherein the specified request comprises any one of a write request for a write operation, an increase request for an increase operation, a modification request for a modification operation, and a deletion request for a deletion operation.

12. A data updating apparatus characterized by comprising: The apparatus comprises: a queue determination module configured to, in response to at least two access requests triggering data updating, determine an access queue based on the access indexes corresponding to the at least two access requests, the access queue comprising the at least two access requests, any access request being used to access index data corresponding to the access index of the access request; an updating module, configured to update index data matched with each access request in the access queue based on a head request in the access queue, the head request being an access request at a head node of the access queue; an awakening module, configured to awaken at least one waiting thread corresponding to at least one access request in the access queue other than the head request based on a head thread corresponding to the head request, the waiting thread being configured to wait for performing an access operation corresponding to the access request; an accessing module, configured to access the updated index data based on threads corresponding to at least two access requests in the access queue.

13. The data updating apparatus according to claim 12, wherein The access index comprises an index key or a virtual key. The queue determining module is further configured to: determine an access queue corresponding to the index key based on the index key, the access queue corresponding to the index key comprising at least two access requests to be used to access index data corresponding to the index key; determine an access queue corresponding to a data bucket based on the data bucket to which the index key belongs, the access queue corresponding to the data bucket comprising at least two access requests to be used to access index data corresponding to any index key in the data bucket; determine an access queue corresponding to the virtual key based on the virtual key, the access queue corresponding to the virtual key comprising at least two access requests to be used to access index data corresponding to the virtual key, the virtual key being an index key that does not exist in a cache database to be accessed.

14. The data updating apparatus according to claim 12, wherein The queue determining module is configured to: create an initial queue corresponding to the access index based on the access index in response to at least two access requests triggering data updating; add the at least two access requests to each queue position of the initial queue one by one to obtain the access queue.

15. The data updating apparatus according to claim 14, wherein The queue determining module is configured to: create a first initial queue corresponding to the access index based on a queue attribute variable and a target lock of a queue operation, the target lock being used to lock uniqueness of a thread performing a queue operation on the first initial queue, the queue operation comprising at least one of an enqueue operation and a dequeue operation, the queue attribute variable comprising at least one of a queue length variable and a memory usage variable; create a second initial queue corresponding to the access index based on a predetermined queue length, a head node and a tail node, the head node and the tail node of the second initial queue being connected; create a third initial queue corresponding to the access index based on a queue attribute variable and a left pointer of the tail node.

16. The data updating apparatus according to claim 15, wherein The queue determining module is configured to: when the initial queue is the first initial queue, add, based on results of at least two invocations of the target lock by threads corresponding to the at least two access requests, an access request corresponding to a thread whose invocation is successful to the first initial queue one by one to obtain a first access queue; when the initial queue is the second initial queue, add, based on operation results of the at least two threads on a position of a current tail node of the second initial queue, an access request corresponding to each thread to the second initial queue one by one to obtain a second access queue; When the initial queue is a third initial queue, based on an operation result of a thread corresponding to each access request on a pointer of a current tail node of the third initial queue, the access request corresponding to each thread is added to the third initial queue one by one, to obtain a third access queue.

17. The data updating apparatus according to claim 16, wherein The queue determining module is configured to: perform, by a thread corresponding to at least one access request that has not joined the first initial queue, an invocation operation on the target lock; in response to invocation success of any thread, add, based on an enqueue operation of the target lock, the access request corresponding to any thread that has invocation success to the first initial queue, repeatedly perform the invocation operation on the target lock and the enqueue operation until each access request in the at least two access requests is added to the first initial queue, to obtain the first access queue.

18. The data updating apparatus according to claim 16, wherein The queue determining module is configured to: perform, by a thread corresponding to at least one access request that has not joined the second initial queue, a comparison between a memory address of the current tail node and an expected address; in response to a comparison result of any thread meeting a first target condition, exchange the memory address and the target address; add, based on a queue position determined by the comparison and exchange operation, the access request corresponding to any thread whose comparison result meets the first target condition to the second initial queue, repeatedly perform the comparison and exchange operation on the current tail node and the operation of joining the second initial queue when the operation is successful until each access request in the at least two access requests is added to the second initial queue or until a current queue length of the second initial queue reaches a predetermined queue length, to obtain the second access queue.

19. The data updating apparatus according to claim 16, wherein The queue determining module is configured to: perform, by a thread corresponding to at least one access request that has not joined the third initial queue, a comparison between a pointing address of a left pointer of the current tail node and an expected pointing address; in response to a comparison result of any thread meeting a second target condition, exchange the pointing address and the target pointing address; add, based on a target pointing address determined by the comparison and exchange operation, the access request corresponding to any thread whose comparison result meets the second target condition to the third initial queue, repeatedly perform the comparison and exchange operation on the current tail node and the operation of joining the third initial queue when the operation is successful until each access request in the at least two access requests is added to the third initial queue, to obtain the third access queue.

20. The data updating apparatus according to claim 14, wherein The device further includes a detection module, a head thread determining module, and a switching module; The detection module is configured to, for each access request, when the access request is added to the initial queue, detect, by a thread corresponding to the currently added access request, access requests included in the initial queue other than the currently added access request; The head thread determining module is configured to, in response to the initial queue not including any access request other than the currently added access request, determine the currently added access request as the head request; The switching module is configured to switch the state of the thread corresponding to the currently added access request to a suspended state in response to the initial queue including any access request in addition to the currently added access request.

21. The data updating apparatus according to claim 12, wherein The updating module is further configured to perform at least one of the following: updating, by the head thread, the data corresponding to the index key in the target resource based on the index key corresponding to each access request in the access queue, the pulled data corresponding to the index key in the cache database as index data corresponding to the index key; and updating, by the head thread, the data corresponding to the virtual key in the target resource based on the virtual key corresponding to each access request in the access queue, the pulled data corresponding to the virtual key in the cache database as index data corresponding to the virtual key. The target resource includes at least one of a target database, a target service, a target interface, and a target instance of the index data.

22. The data updating apparatus according to claim 12, wherein The device further includes a searching module and a specified operation execution module: The searching module is configured to perform, by the head thread corresponding to the head request, a searching operation on the threads included in the access queue, the searching operation being configured to search for a specified request for performing a specified access operation on the index data in the access queue. The specified operation execution module is configured to perform, by the head thread, the specified access operation on the index data in response to the access queue including the specified request. The specified request includes any one of a write request for a write operation, an increase request for an increase operation, a modification request for a modification operation, and a deletion request for a deletion operation.

23. A computer device, comprising: The computer device includes: one or more processors; a memory; one or more computer programs, wherein the one or more application programs are stored in the memory and configured to be executed by the one or more processors, and the one or more programs are configured to perform the data updating method according to any one of claims 1 to 11.

24. A computer-readable storage medium, characterized in that, The computer readable storage medium is used to store computer instructions, when the computer instructions are run on a computer, so that the computer can execute the data updating method according to any one of claims 1 to 11.

25. A computer program product, characterised in that, The computer program or instructions are executed by the processor to realize the data updating method according to any one of claims 1 to 11.

Images