Distributed cache consistency method, distributed system and computer device

Abstract

This application discloses a distributed cache consistency method, a distributed system, and a computer device, relating to the fields of distributed systems and cloud computing technology. The method is applied to business nodes in a distributed system. The method includes: responding to a change event issued by an Etcd cluster, calculating a delay time for the change event based on a preset delay factor, and starting a timer with a duration equal to the delay time; extracting the event version number from the change event, retrieving the modification version number of the target data corresponding to the change event from local memory, and comparing the event version number and the modification version number; if the event version number is greater than the modification version number, then after the timer expires, performing an invalidation operation on the target data in local memory. This method can ensure data consistency between the local cache and the database in the business node and avoid problems such as a surge in database pressure and data logic inconsistencies caused by data cleanup operations.

Description

Technical Field

[0001] This application relates to the fields of distributed systems and cloud computing technology, and in particular to a distributed cache consistency method, a distributed system, and a computer device. Background Technology

[0002] In the fields of distributed systems and cloud computing, microservice architecture is widely adopted. In this architecture, multiple independently deployed business nodes each maintain their own local cache to reduce access latency to the underlying database and improve system throughput. Maintaining efficient and reliable data consistency between the local caches of each business node and the underlying database is a core technical challenge in microservice architecture.

[0003] Etcd is a highly available distributed key-value store system whose Watch mechanism enables basic cache invalidation notifications. In existing distributed cache consistency maintenance schemes, the Etcd Watch mechanism works as follows: when data in the underlying database changes, Etcd pushes the change event to all subscribed business nodes. Upon receiving the event, each business node immediately clears its local cache and, on the next request, retrieves the latest data from the underlying database and stores it in its local cache.

[0004] The above solution leverages Etcd's strong consistency to ensure reliable distribution of change notifications, maintaining data consistency between the local cache and the database under normal circumstances. However, in large-scale production environments, when Etcd issues a failure notification, hundreds or thousands of business nodes simultaneously clear their local caches and request the underlying database, causing a sudden surge in database pressure and potentially leading to system crashes. Furthermore, in complex network environments such as those experiencing network jitter, the order in which business nodes receive change events may be disordered. If cleanup is performed directly without verification, old notifications may overwrite new data, resulting in logical data inconsistencies. Summary of the Invention

[0005] In view of this, embodiments of this application provide a distributed cache consistency method, a distributed system, and a computer device, the main purpose of which is to solve the technical problems of system pressure surge caused by multiple business nodes centrally clearing cache and data logic inconsistency when business nodes clear data.

[0006] According to one aspect of this application, a distributed cache consistency method is provided, the method being applied to business nodes in a distributed system, the method comprising: In response to receiving a change event from the Etcd cluster, the delay time for the change event is calculated based on a preset delay factor, and a timer with a duration equal to the delay time is started. Extract the event version number from the change event, obtain the modification version number of the target data corresponding to the change event from local memory, and compare the event version number and the modification version number. If the event version number is greater than the modification version number, then after the timer expires, the target data in the local memory is invalidated.

[0007] According to another aspect of this application, a distributed system is provided, the distributed system including an Etcd cluster, a database, and multiple business nodes, wherein each of the business nodes includes: Local memory is used to store data read from the database; The Etcd client is used to establish a long connection with the Etcd cluster and receive change events issued by the Etcd cluster. The random delay calculation module is used to calculate the delay time for the change event based on a preset delay factor, and to start a timer with a timing duration equal to the delay time. The revision number controller is used to extract the event version number from the change event, obtain the modification version number of the target data corresponding to the change event from the local memory, and compare the event version number and the modification version number; if the event version number is greater than the modification version number, then after the timer expires, the target data in the local memory is invalidated.

[0008] According to another aspect of this application, a storage medium is provided on which a computer program is stored, which, when executed by a processor, implements the above-described distributed cache coherence method.

[0009] According to another aspect of this application, a computer device is provided, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor implements the above-described distributed cache coherence method when executing the program.

[0010] By employing the above technical solutions, the distributed cache consistency method, distributed system, and computer device provided in this application embodiment, through setting a random delay time for a change event, starting a timer with a duration equal to the delay time, and performing data cleanup operations after the timer expires, can discretize concurrent invalidation requests on the timeline, thereby avoiding a surge in instantaneous pressure caused by a large number of business nodes simultaneously responding to the same change event or simultaneously accessing the database. Furthermore, by comparing the event version number corresponding to the change event with the modification version number of the target data stored locally, and performing data invalidation operations only after the version comparison, idempotent processing can be performed on out-of-order and duplicate change events, thereby preventing old notifications from overwriting new data due to blind cache cleanup, thus avoiding data inconsistency problems. This application only performs data cleanup after local data expires and after a random delay, ensuring data consistency and effectively eliminating the risk of cache avalanche by dispersing database reload requests through delay.

[0011] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, the following are specific embodiments of this application. Attached Figure Description

[0012] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating a distributed cache consistency method provided in an embodiment of this application is shown. Figure 2 This illustration shows an interaction diagram of multiple execution entities in a distributed system according to an embodiment of this application; Figure 3 A flowchart illustrating a distributed cache consistency method provided in an embodiment of this application is shown. Figure 4 A flowchart illustrating a distributed cache consistency method provided in an embodiment of this application is shown. Figure 5 A flowchart illustrating a distributed cache consistency method provided in an embodiment of this application is shown. Figure 6 A flowchart illustrating a distributed cache consistency method provided in an embodiment of this application is shown. Figure 7 A flowchart illustrating a distributed cache consistency method provided in an embodiment of this application is shown. Figure 8A flowchart illustrating a distributed cache consistency method provided in an embodiment of this application is shown. Figure 9 A schematic diagram of the structure of a distributed cache consistency system provided in an embodiment of this application is shown. Detailed Implementation

[0013] The present application will be described in detail below with reference to the accompanying drawings and embodiments. It should be noted that, unless otherwise specified, the embodiments and features described in the embodiments of the present application can be combined with each other.

[0014] In one embodiment, such as Figure 1 As shown, a distributed cache consistency method is provided. Taking the application of this method to a business node in a distributed system as an example, the method includes the following steps: Step 101: In response to receiving a change event from the Etcd cluster, calculate the delay time for the change event based on a preset delay factor, and start a timer with a duration equal to the delay time.

[0015] Among them, a change event refers to a message received by the business node from the Etcd cluster (a distributed key-value storage system) to notify that a key-value pair has changed; a timer is a program component inside the business node used to keep track of time and trigger a callback function after a set time.

[0016] Specifically, business nodes can maintain a long-lived connection with the Etcd cluster through the Etcd client and subscribe to change events for relevant key-value pairs. When a key-value pair in the Etcd cluster is modified, Etcd will push a change event to all business nodes that have subscribed to that key-value pair. Upon receiving the change event, the business node can calculate a random delay time based on a preset latency factor. For example, it can obtain the container identifier or Internet Protocol address of the current business node, perform a hash operation on the identifier, and then take the modulo of this hash with a preset latency upper limit threshold, such as 1000 milliseconds, to obtain a random time value between 0 and 1000 milliseconds. Alternatively, it can call a random number generation function to generate a random value as the latency time. Then, it starts a timer corresponding to this latency time, i.e., starts a timer with a timing interval equal to the latency time, and waits for the timer to finish.

[0017] Step 102: Extract the event version number from the change event, obtain the modification version number of the target data corresponding to the change event from the local memory, and compare the event version number and the modification version number.

[0018] Among them, local memory refers to the random access memory used by the business node to temporarily store data; target data refers to the key-value pair entries corresponding to the change event stored in the local memory of the business node; the event version number is a globally monotonically increasing integer value assigned by the Etcd cluster to the change event, which is called Event Revision in Etcd; the modification version number is the global revision number corresponding to the target data when it is stored in memory, which is called ModRevision in Etcd. This modification version number and the data body are encapsulated together as a cache object and stored in local memory.

[0019] Specifically, after receiving a change event and calculating the delay time, the business node can extract the event version number from the change event either during the delay or before the delay ends. Based on the key-value pair identifier carried in the change event, it then searches for the corresponding cached object in local memory, i.e., searches for the target data. If the target data is found, it extracts the pre-stored modification version number of the target data and compares it with the event version number of the change event. This comparison operation can be performed at any time before the delay ends or immediately after the delay ends.

[0020] Step 103: If the event version number is greater than the modification version number, then after the timer expires, perform an invalidation operation on the target data in local memory.

[0021] The invalidation operation refers to deleting a specified cache entry from local memory.

[0022] Specifically, after comparing the event version number and the modification version number, if the business node determines that the event version number is greater than the modification version number, it indicates that the target data in local memory is outdated, lagging behind the latest version of the key-value pair in Etcd. In this case, the business node can perform an invalidation operation on the target data in local memory after the timer expires, i.e., delete the cache entry. After deletion, when subsequent business requests access the target data, due to the cache missing, the business node will reload the latest data from the database and store it in local memory. In another implementation, the business node can also proactively preload the latest data from the database into local memory after the invalidation operation to pre-fill the cache.

[0023] The following example illustrates the entire process. Assume an Etcd cluster stores a key-value pair with a revision number of 100. Two business nodes, Pod A and Pod B, both subscribe to this key-value pair and cache the data in their local memory, with the cached revision number also set to 100. At some point, an operations engineer modifies the value of this key-value pair. The Etcd cluster then increments the global revision number to 101, updates the revision number of the key-value pair to 101, and pushes a change event to all subscribed business nodes. This event carries an event version number of 101. Pod A and Pod B receive this change event almost simultaneously. Pod A calculates a latency of 200 milliseconds based on the latency factor, while Pod B calculates a latency of 600 milliseconds. During the delay, both business nodes retrieve the modification version number of the target data from their local memory and find it to be 100. Since the event version number 101 is greater than 100, both business nodes consider the data to be expired. Pod A deletes the corresponding data entry from its local cache after 200 milliseconds, while Pod B performs the same deletion operation after 600 milliseconds. Because Pod A deletes first, if a business request arrives at Pod A at this time, Pod A will reload the latest value and the new modification version number 101 from the database and store it in the cache. Pod B, after 600 milliseconds, performs the deletion and loads the new data with modification version number 101, which is asynchronous with Pod A's operation, thus effectively alleviating the database access pressure. If, due to network jitter, Pod B receives an older event with event version number 100, and compares it with the local cached modification version number 101, finding that 100 is less than or equal to 101, then no invalidation operation is needed, thus avoiding reverting the cache to an older version.

[0024] Reference Figure 2 Next, we will explain the data update and query processes for each execution entity in the entire distributed system. First, during the data update phase, when a user initiates a data update request through the application, the business nodes will update the data in the database according to the request and synchronously update the corresponding key-value pairs in the Etcd cluster. Then, the Etcd cluster will record this modification operation as a globally monotonically increasing revision number and update the modification revision number (ModRevision) of the key-value pair to the latest value.

[0025] The process then enters the asynchronous notification phase. During this phase, the Etcd cluster utilizes its built-in watch mechanism to proactively push change events, carrying event revision numbers, to all business nodes that have subscribed to the key-value pair via long-lived connections. This push process is asynchronous and concurrent, and does not affect the Etcd cluster's own write performance. The Etcd client within each business node is responsible for receiving these change events and delivering them to the upper-layer business logic.

[0026] Next, the internal processing logic phase begins. In this phase, each business node, upon receiving a change event, first calculates a delay within a preset time range based on a pre-defined delay factor. During or after the delay, the event version number carried by the event is compared with the modification revision number stored in the local cache for that data entry. If the event version number is greater than the local modification revision number, it indicates that the local cache has expired, and an invalidation operation is performed, i.e., the corresponding cache entry is deleted. If the event version number is less than or equal to the local modification revision number, it indicates that the local data is already up-to-date or that the event is a late, older notification, and no invalidation operation is required. By using random delays and version comparisons, cache avalanche and out-of-order notifications can be prevented.

[0027] Finally, the cache data refilling phase begins. In this phase, when a business node receives a data query request, if the requested target data is expired or does not exist in the local cache, the business node accesses the database to read the latest value of the data and obtains the current revision number of the data through the Etcd application interface. Subsequently, the business node can encapsulate the read data body and the corresponding revision number into a cache object and store it back in local memory. Afterward, subsequent queries for this data can directly hit the cache without accessing the database again, thus reducing database load and speeding up response time. Through the coordinated work of these four phases, the distributed system can achieve data consistency in the distributed cache under high concurrency environments and prevent problems such as database pressure surges and data inconsistencies.

[0028] The above embodiment discretizes concurrent invalidation requests on the timeline by setting a random delay time for the change event and simultaneously starting a timer with a duration equal to the delay time. After the timer expires, data cleanup is performed. This avoids a surge in instantaneous pressure caused by a large number of business nodes simultaneously responding to the same change event or accessing the database. Furthermore, by comparing the event version number corresponding to the change event with the modification version number of the target data stored locally, and only performing data invalidation after the version comparison, idempotent processing of out-of-order and duplicate change events can be achieved. This prevents old notifications from overwriting new data due to blind cache cleanup, thus avoiding data inconsistency issues. This embodiment only performs data cleanup after local data expires and after a random delay, ensuring data consistency and effectively eliminating the risk of cache avalanche by distributing database reload requests through delay.

[0029] In one embodiment, such as Figure 3 As shown, the above distributed cache consistency method further includes the following steps: Step 104: If the event version number is less than or equal to the modification version number, then perform a discard operation on the change event.

[0030] The discard operation refers to the business node ignoring the received change event and not performing any cache cleanup or data update operations.

[0031] Specifically, after comparing the event version number and the modification version number, if the business node determines that the event version number is less than or equal to the modification version number, it indicates one of two possibilities: First, the target data in the local cache already contains the update indicated by the change event, meaning the local data version is not older than the event version; second, the change event is a delayed, older notification with a version number lower than the locally processed version. In both cases, no changes need to be made to the local cache. Therefore, the business node can directly discard the change event without performing any caching operations.

[0032] This embodiment directly discards change events whose event version number is less than or equal to the modification version number. This prevents older events from overwriting locally updated data due to network out-of-order delivery. It also avoids repeatedly processing the same or older version of change events, thus reducing computational overhead.

[0033] In one embodiment, in step 101, after receiving a change event, the business node can calculate the delay time by: first, obtaining the instance identifier or random number factor of the current business node as the delay factor; then, based on the instance identifier or random number factor, calculating a random time value between a preset lower delay time threshold and a preset upper delay time threshold as the delay time.

[0034] Among them, the instance identifier is the unique identity of the business node in the distributed system; the random number factor is the initial value or seed used to generate random numbers; the lower limit threshold and the upper limit threshold of the delay time refer to the minimum and maximum duration set for the delay time, for example, 0 milliseconds and 1000 milliseconds.

[0035] Specifically, after receiving a change event, the business node can obtain the instance identifier or random number factor of the current business node as a delay factor. The instance identifier can be the business node's Internet Protocol address, container identifier, or process identifier, etc., and this embodiment does not impose specific limitations. Then, based on the instance identifier or random number factor, the business node can calculate a random time value as the delay time between a preset lower delay time threshold and a preset upper delay time threshold. For example, a delay time of 200 milliseconds can be calculated between the lower delay time threshold of 0 milliseconds and the upper delay time threshold of 1000 milliseconds.

[0036] The above embodiments calculate the cache cleanup delay time based on the instance identifier or random number factor of the current business node, which can make different business nodes respond differently to the same change event, thereby avoiding instantaneous load peaks caused by a large number of business nodes accessing the database at the same time.

[0037] In one embodiment, such as Figure 4 As shown, the change event that starts the timer can be stored in the pending event table. Therefore, the above distributed cache consistency method can also include the following steps: Step 201: Upon receiving a change event from the Etcd cluster, query the pending event table to see if there are any unprocessed change events for the same data, and compare the event version number of the received change event with the event version number of the unprocessed change event.

[0038] Step 202: If there are unprocessed change events for the same data in the pending event table, and the event version number of the received change event is greater than the event version number of the unprocessed change event, then the received change event is recorded in the pending event table, and the unprocessed change event is discarded.

[0039] The pending event table refers to a data structure maintained locally by the business node to record change events that are waiting for the delay time to end, i.e., waiting for the timer to expire, and their corresponding key-value pairs.

[0040] Specifically, after receiving a change event, the business node can query the pending event table to see if there are any unprocessed change events for the same key-value pair. It then compares the event version number of the received change event with the event version number of the unprocessed change event in the table. If an unprocessed change event for the same data exists in the pending event table, and the event version number of the received change event is greater than that of the unprocessed change event, it indicates that the new event carries an updated data version, and the old event waiting to be processed is outdated. In this case, the business node can cancel the delayed task for the unprocessed change event (i.e., stop its corresponding timer), delete the unprocessed change event from the pending event table, and perform a discard operation on the event. The new change event is retained in the pending event table until the target data corresponding to the change event is cleaned up, or the event is replaced by an updated event.

[0041] The above embodiments maintain a table of pending events and deduplicate multiple pending change events with the same key-value pair, retaining only the change event with the latest version number for invalidation operations. This reduces invalid delayed tasks and cache cleanup times, thereby lowering the computational overhead of business nodes and the access pressure on the database.

[0042] In one embodiment, such as Figure 5 As shown, after step 201, the above distributed cache consistency method may further include the following steps: Step 203: If there are unprocessed change events for the same data in the event table to be processed, and the event version number of the received change event is less than or equal to the event version number of the unprocessed change event, then the received change event is discarded.

[0043] Step 204: If there are no unprocessed change events for the same data in the event to be processed table, then record the received change event in the event to be processed table.

[0044] Specifically, if there are unprocessed change events for the same data in the pending event table, and the event version number of the received change event is less than or equal to the event version number of the unprocessed change event in the table, it indicates that the new event is an outdated old event or has the same version as the already waiting event, and the data version it carries is not newer than the currently waiting event version. In this case, the business node does not need to make any changes to the existing unprocessed events, nor does it need to start a new delayed task. Instead, it directly performs a discard operation on the newly received change event, neither recording it in the pending event table nor creating a timer.

[0045] Furthermore, if no unprocessed change events for the same data exist in the pending event table, it indicates that no other events with the same key-value pair identifier are currently awaiting processing. In this case, the business node can record the newly received change event in the pending event table, including its key-value pair identifier, event version number, and associated delayed task information, such as timer identifiers. Subsequently, the business node can perform version comparison and invalidation operations after the timer expires, or wait for an updated change event to replace the current event. Optionally, the business node can start the corresponding timer while recording the event and bind the timer to the event, so that when an updated change event is received within the event's delay time, the corresponding timer can be quickly located and canceled.

[0046] The above embodiments ensure that each key-value pair in the event table retains at most one change event corresponding to the largest event version number, thus avoiding multiple consecutive cache invalidation operations for the same data and effectively improving data cleaning efficiency in high-frequency update scenarios.

[0047] In one embodiment, such as Figure 6 As shown, the distributed cache consistency method also includes the following steps: Step 301: In response to receiving a data query request, extract the key-value pair identifier from the data query request and query the data corresponding to the key-value pair identifier in local memory.

[0048] Step 302: If the data corresponding to the key-value pair identifier is found in the local memory, then retrieve the data corresponding to the key-value pair identifier from the local memory.

[0049] Step 303: If the data corresponding to the key-value pair identifier is not found in the local memory, the data corresponding to the key-value pair identifier is read from the database, and the modification version number of the data is obtained through the Etcd application interface.

[0050] Step 304: Encapsulate the data and the corresponding modification version number into a cache object and store it in local memory.

[0051] Among them, a data query request is a business call request received by a business node to read specific data; a key-value pair identifier is a keyword or path name used to uniquely identify a key-value pair.

[0052] Specifically, upon receiving a data query request, a business node can extract the key-value pair identifier from the request and search for the corresponding cached object in its local memory based on that identifier. If a cached object corresponding to the key-value pair identifier is found in local memory, the data in that cached object is directly returned as the query result. If no cached object is found in local memory, the business node reads the data corresponding to the key-value pair identifier from the database and obtains the modification version number of that data in the Etcd cluster through the Etcd application interface. Subsequently, the business node can encapsulate the read data body and the modification version number into a cached object and store it in local memory for direct use by subsequent query requests. In this embodiment, a data query request can carry one or more key-value pair identifiers. For each key-value pair identifier in the data query request, the business node can query and process them one by one. For key-value pair identifiers that match the cache, the corresponding data is directly retrieved from local memory; for key-value pair identifiers that do not match the cache, the data is retrieved from the database.

[0053] The above embodiment reads data from the database and obtains the modification version number of the data in Etcd when the data query request misses the local cache. Then, it stores the data and the corresponding modification version number in local memory, which makes it easier to determine the data version and thus ensures the accuracy of cache consistency verification.

[0054] In one embodiment, such as Figure 7 As shown, the distributed cache consistency method also includes the following steps: Step 401: When a business node starts up, based on the current global revision number of the Etcd cluster, record the revision number watermark that the current business node has processed.

[0055] Step 402: In response to receiving a change event from the Etcd cluster, calculate the delay time for the change event based on a preset delay factor, and start a timer with a duration equal to the delay time.

[0056] Step 403: Extract the event version number from the change event, obtain the modification version number of the target data corresponding to the change event from the local memory, and compare the event version number and the modification version number.

[0057] Step 404: If the event version number is greater than the modification version number, then after the timer expires, perform an invalidation operation on the target data in local memory.

[0058] Step 405: After the target data corresponding to the change event is invalidated, update the revision number watermark of the current business node based on the event version number corresponding to the change event.

[0059] Step 406: If the event version number is greater than the modification version number, then the change event is discarded.

[0060] The global revision number is the latest monotonically increasing integer value in the Etcd cluster, representing the version number corresponding to the last write operation in the entire Etcd cluster; the revision number watermark is an integer value maintained locally by the business node to record the largest event version number that the business node has processed.

[0061] Specifically, when a business node starts up, it can send a query request to the Etcd cluster to obtain the current global revision number of the Etcd cluster, and record this global revision number as the initial value as the revision number watermark for the current business node. Subsequently, when the business node receives a change event issued by the Etcd cluster, it can extract the event version number from the change event, calculate a random delay time based on a preset delay factor, and then start a timer with a duration equal to the delay time. It then retrieves the modification version number of the target data corresponding to the change event from its local memory and compares the event version number with the modification version number. If the event version number is greater than the modification version number, it indicates that the locally cached data is outdated, and the business node performs an invalidation operation on the target data after the timer expires. Furthermore, after the invalidation operation is completed, the business node can update the data using the event version number as the new revision number watermark. In an optional embodiment, the service node can compare the event version number of the changed event with the revision number watermark that the current service node has processed. If the event version number is greater than the revision number watermark, the service node updates the event version number as the new revision number watermark; if the event version number is less than or equal to the revision number watermark, the original revision number watermark is retained.

[0062] The above embodiments initialize the revision number watermark when the business node starts up, and update the revision number watermark based on the event version number after each failure operation. This allows for real-time recording of the event processing progress of the business node. In scenarios with unstable networks, such as disconnection and reconnection, the changes processed by the business node can be accurately recorded, thereby enabling accurate data compensation operations.

[0063] In one embodiment, such as Figure 8 As shown, the distributed cache consistency method also includes the following steps: Step 501: In response to the detection that the connection between the current business node and the Etcd cluster has been restored from the interrupted state, obtain the current global revision number of the Etcd cluster and read the revision number watermark that the business node has processed.

[0064] Step 502: Compare the global revision number and the revision number water level marker.

[0065] Step 503: If the global revision number is greater than the revision number watermark, then obtain all missed change events within the interval between the revision number watermark and the global revision number.

[0066] Step 504: Perform an invalidation operation on the expired data corresponding to the missed change events in local memory.

[0067] Step 505: Update the water level marker of the revision number that has been processed in the current business node based on the global revision number.

[0068] Step 506: Enter normal listening mode.

[0069] Among them, the omitted change events refer to all change events that occurred in the Etcd cluster during the period when the connection between the business node and Etcd was interrupted but failed to be pushed to the business node due to the connection interruption.

[0070] Specifically, upon detecting the recovery of the persistent connection with Etcd from an interrupted state, the business node can obtain the current global revision number of the Etcd cluster by calling Etcd's status interface and read the revision number watermark that the business node has processed from its local memory. The revision number watermark represents the largest event version number processed by the current business node. Subsequently, the business node can compare the obtained global revision number with the revision number watermark. If the global revision number is greater than the revision number watermark, it indicates that there were missed change events during the connection interruption. The business node can then call Etcd's historical version query interface, specifying a revision number range from the revision number watermark plus 1 to the global revision number, and retrieve all missed change events within this range. Further, the business node can iterate through these missed change events and check each key-value pair corresponding to the missed change event in its local memory, performing an invalidation operation to delete the corresponding expired data from the local cache. After completing all invalidation operations, the business node updates the locally processed revision number watermark to the obtained global revision number.

[0071] The above embodiments obtain the global revision number after connection recovery and compare the global revision number with the local revision number watermark. This allows for precise invalidation of change events only within the missed range, thereby effectively avoiding system performance jitter and secondary database impact caused by clearing the entire cache.

[0072] In one embodiment, in step 504, an invalidation operation can be performed on the expired data corresponding to the missed change event in the local memory using the following method: For each missed change event, check whether there is data corresponding to the missed change event in the local memory. If there is data corresponding to the missed change event in the local memory, compare the event version number corresponding to the missed change event with the modification version number of the data corresponding to the missed change event. If the event version number corresponding to the missed change event is greater than the modification version number of the data corresponding to the missed change event, then an invalidation operation is performed on the data corresponding to the missed change event in the local memory.

[0073] Specifically, after obtaining all missed change events within the revision number watermark and global revision number range, the business node can check whether corresponding data exists in local memory for each missed change event. If the corresponding data does not exist in local memory, no operation is required; if the corresponding data exists in local memory, the business node extracts the event version number of the missed change event, reads the modification version number bound to the data from local memory, and compares the event version number with the modification version number. If the event version number corresponding to the missed change event is greater than the modification version number corresponding to the data, it indicates that the data in local memory is outdated, and the business node can perform an invalidation operation on the data, i.e., delete the cached entry from local memory; if the event version number of the missed change event is less than or equal to the modification version number corresponding to the data, it indicates that the version of the data in local memory is not older than the version of the change event, and the business node can skip the event without performing an invalidation operation on the data in local memory.

[0074] The above embodiments effectively avoid repeatedly deleting updated cache by setting a version number comparison in the handling of missed change events and performing data cleanup only when the event version number is greater than the modification version number of the local cache data, thereby effectively improving the accuracy of data recovery.

[0075] In one embodiment, in step 504, before performing an invalidation operation on the expired data corresponding to the omitted change events in local memory, the following operations may also be performed: group the omitted change events according to the key-value pair identifiers corresponding to the omitted change events, and then, for each group, retain the change event with the largest event version number in the group, and perform a discard operation on the other change events in the group.

[0076] Specifically, after obtaining all missed change events within the revision number watermark and the global revision number range, the business node can group all missed change events according to their key-value pair identifiers before performing invalidation operations on expired data in local memory. This ensures that change events with the same key-value pair identifier are grouped into the same group. Then, for each group, the business node can iterate through all change events within that group, compare the event version number of each change event, and retain only the change event with the largest event version number in that group, discarding all other change events with smaller event version numbers. After grouping and deduplication, the business node only performs subsequent version number comparison and invalidation operations on the change event with the largest event version number retained in each group, without needing to handle change events with multiple intermediate states corresponding to the same identifier.

[0077] The above embodiments avoid repeatedly processing change events in multiple intermediate states of the same data by grouping the missed change events by data identifier and retaining only the change event with the largest event version number in each group. This reduces the number of version comparisons and failure operations and improves the execution efficiency of incremental compensation.

[0078] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. In addition, the labels corresponding to each step in the above embodiments are only for identification purposes and are not intended to limit the execution order of the steps. The execution order of the steps in each embodiment can be set according to the actual situation.

[0079] Furthermore, as Figures 1 to 8 The specific implementation of the method shown in this application provides a distributed system, such as... Figure 9 As shown, the distributed system includes an Etcd cluster, a database, and multiple business nodes, each of which includes: Local memory is used to store data read from the database; The Etcd client is used to establish a long connection with the Etcd cluster and receive change events issued by the Etcd cluster. The random delay calculation module is used to calculate the delay time for the change event based on a preset delay factor, and to start a timer with a timing duration equal to the delay time. The revision number controller is used to extract the event version number from the change event, obtain the modification version number of the target data corresponding to the change event from the local memory, and compare the event version number and the modification version number; if the event version number is greater than the modification version number, then after the timer expires, the target data in the local memory is invalidated.

[0080] In specific application scenarios, the random delay calculation module specifically obtains the instance identifier or random number factor of the current business node as the delay factor; based on the instance identifier or the random number factor, it calculates a random time value between the preset lower limit threshold and the upper limit threshold of the delay time as the delay time.

[0081] In specific application scenarios, the revision number controller is also used to perform a discard operation on the change event when the event version number is less than or equal to the modification version number.

[0082] In specific application scenarios, the change event that starts the timer is stored in the pending event table; the revision number controller is also used to query whether there is an unprocessed change event for the same data in the pending event table, and compare the event version number of the received change event with the event version number of the unprocessed change event; if there is an unprocessed change event for the same data in the pending event table, and the event version number of the received change event is greater than the event version number of the unprocessed change event, then the received change event is recorded in the pending event table, and the unprocessed change event is discarded.

[0083] In specific application scenarios, the revision number controller is further configured to discard the received change event if there is an unprocessed change event for the same data in the pending event table, and the event version number of the received change event is less than or equal to the event version number of the unprocessed change event; if there is no unprocessed change event for the same data in the pending event table, the received change event is recorded in the pending event table.

[0084] In specific application scenarios, the business node further includes a data query module. The data query module is used to respond to a received data query request, extract the key-value pair identifier from the data query request, and query the data corresponding to the key-value pair identifier in local memory. If the data corresponding to the key-value pair identifier is not found in local memory, the data corresponding to the key-value pair identifier is read from the database, and the modification version number of the data is obtained through the Etcd application interface. The data and the modification version number corresponding to the data are encapsulated together into a cache object and stored in local memory.

[0085] In specific application scenarios, the revision number controller is also used to record the revision number watermark that the current business node has processed based on the current global revision number of the Etcd cluster when the business node starts up; and to update the revision number watermark that the current business node has processed based on the event version number corresponding to the change event after the target data corresponding to the change event is invalidated.

[0086] In specific application scenarios, the revision number controller is further configured to, in response to the detection that the connection between the current business node and the Etcd cluster has been restored from an interrupted state, obtain the current global revision number of the Etcd cluster and read the revision number watermark that the current business node has processed, wherein the revision number watermark is the largest event version number processed by the current business node; compare the global revision number and the revision number watermark; if the global revision number is greater than the revision number watermark, obtain all missed change events within the range of the revision number watermark and the global revision number; perform invalidation operations on the expired data corresponding to the missed change events in local memory, and update the revision number watermark that the current business node has processed based on the global revision number.

[0087] In specific application scenarios, the revision number controller is further configured to check whether there is data corresponding to the missed change event in the local memory for each missed change event; if there is data corresponding to the missed change event in the local memory, the event version number corresponding to the missed change event is compared with the modification version number of the data corresponding to the missed change event; if the event version number corresponding to the missed change event is greater than the modification version number of the data corresponding to the missed change event, an invalidation operation is performed on the data corresponding to the missed change event in the local memory.

[0088] In specific application scenarios, the revision number controller is also used to group the missed change events according to the key-value pair identifiers corresponding to the missed change events; for each group, the change event with the largest event version number in the group is retained, and other change events in the group are discarded.

[0089] It should be noted that other corresponding descriptions of the functional units involved in the distributed cache consistency system provided in this application embodiment can be found in [reference]. Figures 1 to 8 The corresponding descriptions in the methods will not be repeated here.

[0090] This application also provides a computer device, specifically a personal computer, server, network device, etc. The computer device includes a bus, processor, memory, and communication interface, and may also include input / output interfaces and a display device. The processor of the computer device provides computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the computer device stores location information. The network interface of the computer device is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the various method embodiments.

[0091] Those skilled in the art will understand that the structure of the computer device described above is only a partial structure related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. A specific computer device may include more or fewer components, or combine certain components, or have different component arrangements.

[0092] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, having stored thereon a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0093] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0094] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, graphics processors, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0095] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0096] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A distributed cache consistency method, wherein the method is applied to business nodes in a distributed system, characterized in that, The method includes: In response to receiving a change event from the Etcd cluster, the delay time for the change event is calculated based on a preset delay factor, and a timer with a duration equal to the delay time is started. Extract the event version number from the change event, obtain the modification version number of the target data corresponding to the change event from local memory, and compare the event version number and the modification version number. If the event version number is greater than the modification version number, then after the timer expires, the target data in the local memory is invalidated.

2. The method according to claim 1, characterized in that, The calculation of the delay time for the change event based on a preset delay factor includes: Obtain the instance identifier or random number factor of the current business node as the delay factor; Based on the instance identifier or the random number factor, a random time value is calculated as the delay time between the preset lower threshold and the upper threshold of the delay time.

3. The method according to claim 1, characterized in that, After comparing the event version number and the modification version number, the method further includes: If the event version number is less than or equal to the modified version number, then the change event is discarded.

4. The method according to claim 1, characterized in that, The change event that starts the timer is stored in the pending event table; therefore, after receiving the change event issued by the Etcd cluster, the method further includes: Query the pending event table to see if there are any unprocessed change events for the same data, and compare the event version number of the received change event with the event version number of the unprocessed change event; If there are unprocessed change events for the same data in the pending event table, and the event version number of the received change event is greater than the event version number of the unprocessed change event, then the received change event is recorded in the pending event table, and the unprocessed change event is discarded.

5. The method according to claim 4, characterized in that, After comparing the event version number of the received change event with the event version number of the unprocessed change event, the method further includes: If there are unprocessed change events for the same data in the pending event table, and the event version number of the received change event is less than or equal to the event version number of the unprocessed change event, then the received change event is discarded. If there are no unprocessed change events for the same data in the pending event table, the received change event will be recorded in the pending event table.

6. The method according to claim 1, characterized in that, The method further includes: In response to receiving a data query request, the key-value pair identifier is extracted from the data query request, and the data corresponding to the key-value pair identifier is queried in local memory; If the data corresponding to the key-value pair identifier is not found in the local memory, the data corresponding to the key-value pair identifier is read from the database, and the modification version number of the data is obtained through the Etcd application interface. The data and its corresponding version number are encapsulated together into a cache object and stored in local memory.

7. The method according to claim 1, characterized in that, The method further includes: When a business node starts up, it records the revision number watermark that the current business node has processed, based on the current global revision number of the Etcd cluster. After performing the invalidation operation on the target data in local memory, the method further includes: The revision number watermark of the current business node is updated based on the event version number corresponding to the change event.

8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: In response to the detection that the connection between the current service node and the Etcd cluster has been restored from the interrupted state, the current global revision number of the Etcd cluster is obtained, and the revision number watermark of the current service node is read, wherein the revision number watermark is the largest event version number processed by the current service node; The global revision number and the revision number water level marker are compared; If the global revision number is greater than the revision number watermark, then all missed change events within the interval between the revision number watermark and the global revision number are obtained; Perform invalidation operations on expired data corresponding to missed change events in local memory, and update the revision number watermark of the current business node based on the global revision number.

9. The method according to claim 8, characterized in that, The invalidation operation for expired data corresponding to missed change events in local memory includes: For each missed change event, check if there is data in the local memory corresponding to the missed change event; If data corresponding to the missed change event exists in local memory, then the event version number corresponding to the missed change event is compared with the modification version number of the data corresponding to the missed change event. If the version number of the omitted change event is greater than the modification version number of the data corresponding to the omitted change event, then an invalidation operation is performed on the data corresponding to the omitted change event in local memory.

10. The method according to claim 8, characterized in that, Before performing the invalidation operation on the expired data corresponding to the missed change events in local memory, the method further includes: Group the missed change events according to the key-value pair identifiers corresponding to the missed change events; For each group, retain the change event with the highest version number within the group, and discard the other change events within the group.

11. A distributed system, characterized in that, The distributed system includes an Etcd cluster, a database, and multiple business nodes, wherein each business node includes: Local memory is used to store data read from the database; The Etcd client is used to establish a long connection with the Etcd cluster and receive change events issued by the Etcd cluster. The random delay calculation module is used to calculate the delay time for the change event based on a preset delay factor, and to start a timer with a timing duration equal to the delay time. The revision number controller is used to extract the event version number from the change event, obtain the modification version number of the target data corresponding to the change event from the local memory, and compare the event version number and the modification version number; if the event version number is greater than the modification version number, then after the timer expires, the target data in the local memory is invalidated.

12. A computer device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 10.

Images