A distributed fast refresh method and system based on version number configuration

Abstract

This invention discloses a distributed fast refresh method for configuration based on version numbers. The method includes: generating a logical version number corresponding to a configuration data change operation; broadcasting a change event containing a configuration identifier and a logical version number to each business node via a publish-subscribe pattern; upon receiving the change event, each business node compares the logical version number in the event with the version number corresponding to the configuration data stored locally, where the logical version number in the event is the event version number, and the version number corresponding to the configuration data stored locally is the local version number. If the event version number is greater than the local version number, the configuration entry corresponding to the configuration identifier in the local cache is invalidated; when a business thread requests the configuration corresponding to the configuration identifier, the latest configuration data is loaded from the data source, and the version number stored locally is updated to the event version number. By constructing a distributed consistency control model with a monotonically increasing version number, consistent and stable configuration refresh is achieved.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and more specifically to a distributed fast refresh method and system based on version number configuration. Background Technology

[0002] In distributed system architectures, efficiently and reliably managing dynamically changing configuration information is a key technical challenge for ensuring system stability and maintainability. Traditional configuration management solutions, such as writing configurations to application configuration files and having them take effect upon application restart, or periodically polling the database for updates, are no longer sufficient to meet the high availability and agile operation and maintenance requirements of modern microservices and cloud-native architectures. Therefore, the industry has proposed various dynamic configuration refresh solutions.

[0003] In existing technologies, a common approach is to broadcast configuration change events through message middleware such as Kafka or RabbitMQ, notifying each business node to refresh its local configuration. For example, Chinese invention patent CN115733848A discloses a distributed data storage management system for edge devices. This system utilizes a cloud-edge collaboration mechanism, using gRPC bidirectional data streams to update configuration files and data processing models between the edge and the cloud, embodying the idea of ​​remote configuration synchronization through message communication. However, such solutions based on general message queues typically broadcast complete configuration content or change commands. In a distributed environment, issues such as network partitions, node restarts, or message retries and out-of-order delivery by the message middleware itself can easily lead to inconsistent event sequences received by different nodes. If a later configuration change event arrives at a node before an earlier one, the node's configuration may be incorrectly rolled back to the old version, causing distributed configuration inconsistencies and potentially leading to service failures.

[0004] The applicant has found that existing system configuration refresh technologies suffer from problems such as uncontrollable delays in configuration activation, coarse-grained configuration refresh, high system resource consumption, and potential configuration inconsistencies in out-of-order message scenarios. Furthermore, some solutions still rely on restarting the application to ensure configuration activation, severely impacting system stability. Summary of the Invention

[0005] To overcome the technical problem that message out-of-order refresh caused by the above-mentioned system configuration refresh may lead to inconsistent configurations, this invention provides a distributed fast refresh method and system based on version number configuration.

[0006] To solve the above problems, the present invention is implemented according to the following technical solution:

[0007] In a first aspect, the present invention provides a distributed fast refresh method based on version number configuration, comprising: generating a logical version number corresponding to the change operation in response to a change operation of configuration data; broadcasting a change event containing a configuration identifier and the logical version number to each business node through a publish-subscribe pattern; after receiving the change event, each business node compares the logical version number in the event with the version number corresponding to the configuration data stored locally, wherein the logical version number in the event is the event version number, and the version number corresponding to the configuration data stored locally is the local version number; if the event version number is greater than the local version number, then invalidating the configuration entry corresponding to the configuration identifier in the local cache; when a business thread requests to obtain the configuration corresponding to the configuration identifier, loading the latest configuration data from the data source and updating the version number stored locally to the event version number.

[0008] Preferably, the step of generating a logical version number corresponding to the configuration data change operation in response to the change operation specifically includes: listening for the configuration data change operation through an interceptor set in the data persistence layer; and generating a monotonically increasing value as the logical version number of the change operation after the database transaction corresponding to the change operation is successfully committed.

[0009] Preferably, broadcasting the change event containing the configuration identifier and the logical version number to each business node via a publish-subscribe pattern specifically includes: encapsulating the configuration identifier and the logical version number into a configuration change event; publishing the configuration change event to a preset message channel or message middleware; and pushing the configuration change event to all business nodes that have subscribed to this event type through the message channel or message middleware.

[0010] Preferably, after receiving the change event, each business node compares the logical version number in the event with the version number corresponding to the configuration data in local storage. If the event version number is greater than the local version number, the configuration entry corresponding to the configuration identifier in the local cache is invalidated. Specifically, this includes: the business node parsing the configuration identifier and the event version number from the change event; obtaining the current local version number corresponding to the configuration data from local storage based on the configuration identifier; comparing the event version number with the local version number; if the event version number is greater than the local version number, determining that the configuration data in the local cache is outdated, and deleting or marking the configuration entry corresponding to the configuration identifier in the local cache as invalid; if the event version number is not greater than the local version number, ignoring the change event and keeping the local cache and local version number unchanged.

[0011] Preferably, when a business thread requests to obtain the configuration corresponding to the configuration identifier, the latest configuration data is loaded from the data source, and the version number stored locally is updated to the event version number. Specifically, this includes: when a business thread requests to obtain the target configuration, checking whether the configuration entry corresponding to the target configuration identifier in the local cache is valid; if the configuration entry has been marked as invalid or does not exist in the cache, then loading the latest configuration data corresponding to the target configuration identifier from the data source; storing the loaded configuration data in the local cache, and updating the version number corresponding to the target configuration stored locally to the event version number of the last change event; and returning the loaded configuration data to the business thread.

[0012] Preferably, the distributed fast refresh method based on version number configuration further includes: when the business node starts, loading all configuration data and their corresponding logical version numbers from the data source, storing the loaded configuration data in the local cache, and storing the logical version number as the local version number.

[0013] Preferably, the step of loading all configuration data and their corresponding logical version numbers from the data source when the business node starts, and storing the loaded configuration data in the local cache, while storing the logical version number as the local version number, specifically includes: sending a full configuration data loading request to the data source; receiving a set of configuration entries returned by the data source containing configuration identifiers, configuration data, and logical version numbers; traversing the set of configuration entries, writing the configuration data of each configuration entry into the local cache, and storing the logical version number of the configuration entry as the local version number of the configuration.

[0014] Secondly, the present invention also provides a distributed fast refresh system based on version number configuration, comprising: a configuration management module, used to generate a logical version number corresponding to the change operation in response to a change operation of configuration data; an event response module, used to broadcast a change event containing a configuration identifier and the logical version number to each business node through a publish-subscribe pattern; a processing module, used to compare the logical version number in the event with the version number corresponding to the configuration data stored locally after each business node receives the change event, wherein the logical version number in the event is the event version number, and the version number corresponding to the configuration data stored locally is the local version number, and if the event version number is greater than the local version number, then the configuration entry corresponding to the configuration identifier in the local cache is invalidated; and a configuration loading module, used to load the latest configuration data from the data source and update the version number stored locally to the event version number when a business thread requests to obtain the configuration corresponding to the configuration identifier.

[0015] Compared with the prior art, the beneficial effects of the present invention are:

[0016] This invention achieves rapid and consistent updates of configuration data in a distributed environment by introducing a change event broadcasting mechanism based on logical version numbers and a publish-subscribe pattern. By comparing the event version number with the local version number, the configuration that needs updating can be accurately and efficiently identified, avoiding frequent fetching and comparison of full data, thus reducing network overhead and computational load. The latest configuration is loaded from the data source only when the business thread actually requests it, ensuring data real-time performance and avoiding instantaneous pressure spikes caused by configuration changes, thereby improving the overall stability and responsiveness of the system. By decoupling configuration change notifications from data loading timing, the system's scalability and fault tolerance are enhanced, effectively supporting the configuration management needs of large-scale distributed systems. Attached Figure Description

[0017] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings, wherein:

[0018] Figure 1 This is a flowchart of a distributed fast refresh method based on version number configuration according to the present invention;

[0019] Figure 2 This is a block diagram of an electronic device used to implement embodiments of the present invention;

[0020] In the picture:

[0021] 100 - Electronic device, 101 - Computing unit, 102 - ROM, 103 - RAM, 104 - Bus, 105 - I / O interface, 106 - Input unit, 107 - Output unit, 108 - Storage unit, 109 - Communication unit. Detailed Implementation

[0022] The preferred embodiments of the present invention will be described below with reference to the accompanying drawings. It should be understood that the preferred embodiments described herein are for illustration and explanation only and are not intended to limit the present invention.

[0023] In distributed system architectures, efficiently and reliably managing dynamically changing configuration information is a key technical challenge for ensuring system stability and maintainability. Traditional configuration management solutions, such as writing configurations to application configuration files and having them take effect upon application restart, or periodically polling the database for updates, are no longer sufficient to meet the high availability and agile operation and maintenance requirements of modern microservices and cloud-native architectures. Therefore, the industry has proposed various dynamic configuration refresh solutions.

[0024] Implementing configuration refresh in distributed systems primarily relies on several techniques: periodically polling the database, refreshing based on cache expiration time, or broadcasting the complete configuration content via message queues. These solutions generally suffer from several drawbacks, such as uncontrollable delays in configuration activation, overly coarse granularity of configuration refresh, and significant system resource consumption. Furthermore, in scenarios with out-of-order messages, these solutions can lead to inconsistent configuration states across nodes. More critically, some traditional solutions still require restarting the entire application to ensure configuration effectiveness, severely impacting the stability and availability of the distributed system.

[0025] Example 1:

[0026] like Figures 1-2 As shown, the distributed fast refresh method based on version number configuration of the present invention includes: generating a logical version number corresponding to the change operation in response to a change operation of configuration data; broadcasting a change event containing a configuration identifier and the logical version number to each business node through a publish-subscribe pattern; after receiving the change event, each business node compares the logical version number in the event with the version number corresponding to the configuration data stored locally, wherein the logical version number in the event is the event version number, and the version number corresponding to the configuration data stored locally is the local version number; if the event version number is greater than the local version number, the configuration entry corresponding to the configuration identifier in the local cache is invalidated; when a business thread requests to obtain the configuration corresponding to the configuration identifier, the latest configuration data is loaded from the data source, and the version number stored locally is updated to the event version number.

[0027] In a further preferred embodiment, the step of generating a logical version number corresponding to the configuration data change operation in response to the change operation specifically includes: listening for the configuration data change operation through an interceptor set in the data persistence layer; and generating a monotonically increasing value as the logical version number of the change operation after the database transaction corresponding to the change operation is successfully committed.

[0028] Understandably, configuration administrators perform add, delete, and modify operations on configuration tables in the database through the configuration management interface. In the persistence layer, the MyBatis-Plus framework can be used in this embodiment. The persistence layer interception module intercepts all INSERT, UPDATE, and DELETE operations on the configuration tables and records the change intent. After ensuring successful database transaction commit, the system generates a globally monotonically increasing logical version number for this change, uniquely identifying the order of the changes. Subsequently, the event dispatch module encapsulates the changed configuration identifier and this logical version number into a configuration change event object.

[0029] In a further preferred embodiment, broadcasting the change event containing the configuration identifier and the logical version number to each business node via a publish-subscribe pattern specifically includes: encapsulating the configuration identifier and the logical version number into a configuration change event; publishing the configuration change event to a preset message channel or message middleware; and pushing the configuration change event to all business nodes that have subscribed to the event type through the message channel or message middleware.

[0030] Understandably, the event distribution module connects to the current master node of the Redis Sentinel cluster and publishes the encapsulated change events to the specified broadcast channel through Redis's publish / subscribe (Pub / Sub) mechanism. Redis Sentinel mode ensures that the publication channel remains available even during master node failover, thus guaranteeing the high availability of the change notification mechanism.

[0031] In a further preferred embodiment, after receiving the change event, each service node compares the logical version number in the event with the version number corresponding to the configuration data in local storage. If the event version number is greater than the local version number, the configuration entry corresponding to the configuration identifier in the local cache is invalidated. Specifically, this includes: the service node parses the configuration identifier and the event version number from the change event; based on the configuration identifier, it obtains the current local version number corresponding to the configuration data from local storage; it compares the event version number with the local version number; if the event version number is greater than the local version number, it determines that the configuration data in the local cache is outdated and deletes or marks the configuration entry corresponding to the configuration identifier in the local cache as invalid; if the event version number is not greater than the local version number, the change event is ignored, and the local cache and local version number remain unchanged.

[0032] Understandably, upon startup, all business nodes subscribe to the aforementioned Redis channel using their respective business node listening modules to monitor configuration change events. When a business node receives an event, it immediately performs a critical operation to obtain the configuration identifier and event version number. It then queries the local storage for the local version number corresponding to that configuration identifier. A version number comparison is performed; if the event version number is greater than the local version number, it indicates a new and valid change, and the process proceeds to the next step. If the event version number is less than or equal to the local version number, it indicates an expired or duplicate message, and the event is discarded. This mechanism addresses message out-of-order and duplicate message issues.

[0033] In a further preferred embodiment, when a business thread requests to obtain the configuration corresponding to the configuration identifier, the latest configuration data is loaded from the data source, and the version number stored locally is updated to the event version number. Specifically, this includes: when a business thread requests to obtain the target configuration, checking whether the configuration entry corresponding to the target configuration identifier in the local cache is valid; if the configuration entry has been marked as invalid or does not exist in the cache, then loading the latest configuration data corresponding to the target configuration identifier from the data source; storing the loaded configuration data in the local cache, and updating the version number corresponding to the target configuration stored locally to the event version number of the last change event; and returning the loaded configuration data to the business thread. When a business node starts, all configuration data and their corresponding logical version numbers are loaded from the data source, and the loaded configuration data is stored in the local cache, while the logical version number is stored as the local version number. The step of loading all configuration data and their corresponding logical version numbers from the data source when the business node starts, storing the loaded configuration data in the local cache, and storing the logical version number as the local version number specifically includes: sending a full configuration data loading request to the data source; receiving a set of configuration entries returned by the data source containing configuration identifiers, configuration data, and logical version numbers; traversing the set of configuration entries, writing the configuration data of each configuration entry into the local cache, and storing the logical version number of the configuration entry as the local version number of the configuration.

[0034] Understandably, when a business node starts, initial synchronization is necessary to ensure it has a complete and correct configuration before processing business operations. After startup, the node sends a full configuration data load request to the configuration database. The data source returns a set of configuration entries. Each entry in the set explicitly includes a configuration identifier, configuration data, and the logical version number of that configuration item in the data source; the configuration data is the specific value of the configuration. The node iterates through the received set of configuration entries. For each configuration entry in the set, the following operations are performed: the configuration data of the entry is written to the local cache using its configuration identifier as the key. This ensures that subsequent business requests can directly read the configuration from memory in microseconds. Simultaneously, the logical version number of the configuration entry is persistently stored locally on the node as the local version number of the configuration identifier. This step ensures that at the beginning of startup, the node's local state is completely consistent with the latest global state of the configuration data source, establishing a correct version baseline for receiving incremental change events.

[0035] When a business thread needs to retrieve a configuration during business operations, the following process is triggered: The business thread requests the configuration corresponding to the target configuration identifier. The system first checks if the configuration entry corresponding to that identifier in the local cache is valid. The validity criterion is whether it has been marked as invalid. If the cached entry has been marked as invalid or does not exist in the cache at all, it means that the configuration may have changed or has not yet been loaded. In this case, the system will not directly use the old value, but will load the latest configuration data corresponding to the target configuration identifier from the data source. This on-demand loading mechanism avoids invalid preloading and reduces the load on the data source. The latest configuration data just loaded from the data source is then re-stored or refreshed in the local cache, using the configuration identifier as the key. The version number corresponding to the target configuration stored locally is updated to the event version number of the change event that triggered this loading. Note that this version number is the version number previously received and verified as valid through event broadcasting, which ensures that the local version record is logically synchronized with the actual version in the data source. Finally, the loaded latest configuration data is returned to the requesting business thread for its use.

[0036] If message order is out of order, later-arriving older version messages are discarded because their version number is not greater than the local version number, thus avoiding configuration rollback. If message duplication occurs, events with the same version number are received multiple times, and all but the first one are ignored, achieving idempotent refresh.

[0037] After a node restarts, it initializes and loads the latest version numbers of each configuration item from the database, then rejoins the subscription to ensure state synchronization. In the event of a brief disconnection, the system reconnects after the brief interruption and can continue receiving events, ultimately achieving data consistency through the version number mechanism.

[0038] Example 2:

[0039] Another aspect of the present invention provides a distributed fast refresh system based on version number configuration, comprising: a configuration management module, used to generate a logical version number corresponding to the change operation in response to a change operation of configuration data; an event response module, used to broadcast a change event containing a configuration identifier and the logical version number to each business node through a publish-subscribe pattern; a processing module, used to compare the logical version number in the event with the version number corresponding to the configuration data stored locally after each business node receives the change event, wherein the logical version number in the event is the event version number and the version number corresponding to the configuration data stored locally is the local version number, and if the event version number is greater than the local version number, then the configuration entry corresponding to the configuration identifier in the local cache is invalidated; and a configuration loading module, used to load the latest configuration data from the data source and update the version number stored locally to the event version number when a business thread requests to obtain the configuration corresponding to the configuration identifier.

[0040] The configuration management module responds to administrator changes to configuration data (add, delete, modify). When the interceptor detects a change to the configuration table and confirms a successful database transaction commit, the version number generation module within the configuration management module generates a globally monotonically increasing logical version number for this change. This version number is crucial for ensuring the order of changes and preventing message out-of-order delivery.

[0041] The event response module broadcasts configuration change information to all business nodes in the distributed system. This module receives the configuration identifier and logical version number from the configuration management module and encapsulates them into a structured change event object. Then, it connects to the current master node of the Redis Sentinel cluster and utilizes Redis's publish / subscribe (Pub / Sub) functionality to publish the event to a predefined channel. The Redis Sentinel mode ensures that the event publication channel automatically switches even if the master node fails, guaranteeing high system availability. Upon startup, the business node subscribes to the configuration change channel in Redis and continuously listens for broadcast messages from the event publication module.

[0042] Upon receiving a change event, the processing module immediately parses out the configuration identifier and event version number from the event. Then, it queries the local version number corresponding to that configuration identifier stored on the local node and compares them. The judgment logic is as follows: only if the event version number is greater than the local version number is it considered a valid new event, triggering subsequent actions; otherwise, if it is less than or equal to the local version number, the event is discarded. This mechanism is a key technical point for this system to solve the problems of message out-of-order delivery and duplicate delivery.

[0043] The configuration loading module, after version verification passes, is responsible for performing targeted invalidation operations. This means it only invalidates the cached entry in the local cache corresponding to the configuration identifier indicated by the change event, without affecting other data in the cache. It is responsible for loading configuration data, cache management, and version number persistence. When a business node starts, it sends a full load request to the configuration database to obtain the current data and logical version numbers of all configuration items. Then, it iterates through the result set, loading the data of each configuration item into the local cache and recording its version number as the local version number, thus completing the initial synchronization of the node state. When a business thread requests a configuration, and the corresponding entry in the local cache has been marked as invalid or does not exist, this module is triggered. It loads the latest data corresponding to that configuration identifier from the configuration database, writes the new data to the local cache, updates the locally stored version number to the version number of the event that previously triggered the invalidation, and finally returns the data to the business thread. This achieves on-demand refreshing, avoiding concentrated database impact.

[0044] The configuration database is the authoritative source for storing all configuration data and its latest logical version number; it is a relational database. It responds to change operations from the configuration management module, as well as query requests from business nodes during full synchronization and runtime lazy loading.

[0045] Administrators modify configurations in the data source via the configuration management terminal. The configuration management module generates a new version number, which is broadcast as a change event by the event publishing module. The event subscription and processing modules of each business node receive the event, filter invalid events through the version verification submodule, and invalidate the corresponding cache through the cache control submodule. When a business request arrives, the configuration loading and caching module loads the latest configuration from the data source and updates the cache and local versions, completing a seamless hot update.

[0046] Example 3:

[0047] According to embodiments of the present invention, the present invention also provides an electronic device, a readable storage medium, and a computer program product.

[0048] Figure 2 A schematic block diagram of an example electronic device 100 that can be used to implement embodiments of the present invention is shown. Electronic device 100 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic device 100 may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their links and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0049] like Figure 2 As shown, the electronic device 100 includes a computing unit 101, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 102 or a computer program loaded from a storage unit 108 into a random access memory (RAM) 103. The RAM 103 may also store various programs and data required for the operation of the device 100. The computing unit 101, ROM 102, and RAM 103 are interconnected via a bus 104. An input / output (I / O) interface 105 is also connected to the bus 104.

[0050] Multiple components in electronic device 100 are linked to I / O interface 105, including: input unit 106, such as keyboard, mouse, etc.; output unit 107, such as various types of displays, speakers, etc.; storage unit 108, such as disk, optical disk, etc.; and communication unit 109, such as network card, modem, wireless transceiver, etc. Communication unit 109 allows electronic device 100 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0051] The computing unit 101 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 101 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 101 performs the various methods and processes described above, such as a version number-based distributed fast refresh method. For example, in some embodiments, a version number-based distributed fast refresh method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 108. In some embodiments, part or all of the computer program can be loaded and / or installed on device 100 via ROM 102 and / or communication unit 109. When the computer program is loaded into RAM 103 and executed by the computing unit 101, one or more steps of a version number-based distributed fast refresh method described above can be performed. Alternatively, in other embodiments, computing unit 101 may be configured by any other suitable means (e.g., by means of firmware) to perform a distributed fast refresh method based on version number configuration.

[0052] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0053] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0054] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical links based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0055] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0056] The systems and technologies described herein can be implemented in computing systems that include back-end components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include front-end components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such back-end, middleware, or front-end components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0057] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0058] It should be understood that the various forms of processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this invention can be achieved, and this is not limited herein.

[0059] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Therefore, any modifications, equivalent changes, and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A distributed fast refresh method based on version number configuration, characterized in that, include: In response to a change operation on configuration data, a logical version number corresponding to the change operation is generated; The change event, which includes the configuration identifier and the logical version number, will be broadcast to each business node via a publish-subscribe pattern. After receiving the change event, each business node compares the logical version number in the event with the version number corresponding to the configuration data stored locally. The logical version number in the event is the event version number, and the version number corresponding to the configuration data stored locally is the local version number. If the event version number is greater than the local version number, the configuration entry corresponding to the configuration identifier in the local cache is invalidated. When a business thread requests to retrieve the configuration corresponding to the configuration identifier, it loads the latest configuration data from the data source and updates the version number stored locally to the event version number.

2. The distributed fast refresh method based on version number configuration according to claim 1, characterized in that, The step of generating a logical version number corresponding to the configuration data change operation in response to the change operation specifically includes: Listen for changes to configuration data by setting interceptors in the data persistence layer; After the database transaction corresponding to the change operation is successfully committed, a monotonically increasing value is generated as the logical version number of the change operation.

3. The distributed fast refresh method based on version number configuration according to claim 1, characterized in that, The step of broadcasting the change event, which includes the configuration identifier and the logical version number, to each service node via a publish-subscribe pattern specifically includes: The configuration identifier and the logical version number are encapsulated into a configuration change event; Publish the configuration change event to the preset message channel or message middleware; The configuration change event is pushed to all business nodes that have subscribed to this event type via the message channel or message middleware.

4. The distributed fast refresh method based on version number configuration according to claim 1, characterized in that, Upon receiving the change event, each service node compares the logical version number in the event with the version number corresponding to the configuration data stored locally. If the event version number is greater than the local version number, the configuration entry corresponding to the configuration identifier in the local cache is invalidated, specifically including: The business node parses the configuration identifier and event version number from the change event; Based on the configuration identifier, retrieve the current local version number corresponding to the configuration data from the local storage; Compare the event version number with the local version number. If the event version number is greater than the local version number, it is determined that the configuration data in the local cache is outdated, and the configuration entry in the local cache corresponding to the configuration identifier is deleted or marked as invalid. If the event version number is not greater than the local version number, then the change event is ignored, and the local cache and local version number remain unchanged.

5. The distributed fast refresh method based on version number configuration according to claim 1, characterized in that, When a business thread requests the configuration corresponding to the configuration identifier, it loads the latest configuration data from the data source and updates the version number stored locally to the event version number, specifically including: When a business thread requests to obtain the target configuration, it checks whether the configuration entry corresponding to the target configuration identifier in the local cache is valid. If the configuration entry has been marked as invalid or does not exist in the cache, then the latest configuration data corresponding to the target configuration identifier is loaded from the data source; The loaded configuration data is stored in the local cache, and the version number of the target configuration stored locally is updated to the event version number of the last change event. The loaded configuration data is returned to the business thread.

6. The distributed fast refresh method based on version number configuration according to claim 1, characterized in that, Also includes: When a business node starts, it loads all configuration data and their corresponding logical version numbers from the data source, stores the loaded configuration data in the local cache, and stores the logical version numbers as local version numbers.

7. The distributed fast refresh method based on version number configuration according to claim 1, characterized in that, The step of loading all configuration data and their corresponding logical version numbers from the data source when the business node starts, storing the loaded configuration data in the local cache, and storing the logical version numbers as local version numbers specifically includes: Send a full configuration data load request to the data source; Receive a set of configuration entries returned by the data source, which includes a configuration identifier, configuration data, and logical version number; The configuration entry set is traversed, the configuration data of each configuration entry is written to the local cache, and the logical version number of the configuration entry is stored as the local version number of the configuration.

8. A distributed fast refresh system based on version number configuration, characterized in that, include: The configuration management module is used to generate a logical version number corresponding to the configuration data change operation in response to the change operation. The event response module is used to broadcast change events containing configuration identifiers and the logical version number to each business node through a publish-subscribe pattern; The processing module is used to compare the logical version number in the event with the version number corresponding to the configuration data stored locally after each business node receives the change event. The logical version number in the event is the event version number, and the version number corresponding to the configuration data stored locally is the local version number. If the event version number is greater than the local version number, the configuration entry corresponding to the configuration identifier in the local cache is invalidated. The configuration loading module loads the latest configuration data from the data source and updates the locally stored version number to the event version number when the business thread requests to obtain the configuration corresponding to the configuration identifier.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the distributed fast refresh method based on version number configuration as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that causes a processor to execute the distributed fast refresh method based on version number configuration as described in any one of claims 1-7.

Images