Dynamic AppId polling acquisition method and system

Abstract

The invention discloses a dynamic AppId polling acquisition method and system, and mainly relates to the technical field of cross-platform identity authentication management. Comprising the following steps: establishing a basic environment for reading initial AppId list configuration; initializing a safe data storage structure of the thread, and recording a polling position; the configuration monitoring mechanism is used for monitoring the AppId list change of the Nacos configuration center in real time; when the configuration change is monitored, triggering a configuration analysis process, and performing format processing and cleaning on the new AppId list configuration to generate a standardized AppId list; updating a locally stored AppId list based on the analyzed new list, and synchronously resetting a polling index to an initial position; and constructing an asynchronous processing mechanism based on the thread pool, asynchronously executing a polling acquisition process after receiving an AppId acquisition request, and returning a result through a callback mechanism after completing the polling acquisition process. The method has the beneficial effects that dynamic configuration, ordered polling, thread security access and real-time refreshing of AppId are realized.

Description

Technical Field

[0001] The present invention relates to the technical field of cross-platform identity authentication management, and in particular to a method and system for obtaining dynamic AppId polling based on a Nacos configuration center. Background Art

[0002] With the rapid development of cloud computing and microservices architectures, modern enterprise application systems often require integration and data exchange across multiple third-party platforms. In cross-platform applications, each platform requires a unique application identifier (AppId) for identity authentication and API call permission control. Traditional AppId management methods typically use static configuration files for storage, which poses challenges such as requiring service restarts for configuration updates, inability to dynamically scale, and a lack of organized access mechanisms.

[0003] In highly concurrent distributed systems, when frequent calls to multiple platform APIs are required, managing and utilizing these AppIDs efficiently and in an orderly manner becomes a significant technical challenge. Ordered polling mechanisms are particularly important when load balancing is required to avoid throttling caused by frequent calls to a single AppID.

[0004] In existing technologies, most systems use hard-coded or static configuration files to manage AppIDs. Adding or removing platforms requires manually modifying the configuration file and restarting the service, resulting in high maintenance costs and slow response times. Furthermore, existing technologies lack effective polling mechanisms, leading to uneven distribution of API calls and impacting system performance.

[0005] Therefore, a dynamic AppId polling acquisition method and system based on the Nacos configuration center is urgently needed to solve the above problems. Summary of the Invention

[0006] The purpose of the present invention is to provide a dynamic AppId polling acquisition method and system based on the Nacos configuration center, which realizes dynamic configuration, orderly polling, thread-safe access and real-time refresh of AppId.

[0007] To achieve the above-mentioned purpose, the present invention is implemented through the following technical solutions: In one aspect, a method for obtaining a dynamic AppId by polling is provided, comprising the following steps: Step S1: Build a basic environment based on the Nacos Configuration Center and complete the connection between the Nacos Configuration Center and the application system to read the initial AppId list configuration; Step S2: Build a core configuration management module to initialize a thread-safe data storage structure to save the AppId list, and create an atomic index in the core configuration management module to record the polling position; Step S3: Integrate a configuration monitoring mechanism into the core configuration management module to monitor the changes in the AppId list of the Nacos configuration center in real time; Step S4: When a configuration change is detected, the configuration parsing process is triggered to format and clean the new AppId list configuration to generate a standardized AppId list; Step S5: Update the locally stored AppId list based on the parsed new list, and simultaneously reset the polling index to the initial position; Step S6: When the system has an AppId acquisition requirement, the current polling index is read through atomic operations and automatically incremented. A boundary check is performed based on the list length. If the range is exceeded, the index is automatically reset to implement cyclic polling. Step S7: A read-write lock mechanism is used during the polling acquisition process. Specifically, the read-write lock mechanism is: a read lock is used during a read operation, and a write lock is used during a write operation; Step S8: Build an asynchronous processing mechanism based on the thread pool, asynchronously execute the polling acquisition process after receiving the AppId acquisition request, and return the result through the callback mechanism after completion.

[0008] Preferably, the basic environment based on the Nacos configuration center in step S1 includes: Step S11: Build an application environment that supports the microservice architecture, integrate the dependent components required by the Nacos configuration center, and complete the version compatibility configuration; Step S12: Configure the connection parameters between the application and Nacos, including the service address and port, to ensure that the application can access the configuration center normally; Step S13: Create an initial configuration file in the Nacos Configuration Center, define the storage format of the AppId list, support comma and semicolon separated strings, and enter the initial AppId data; Step S14: Enable the automatic configuration refresh function of the application so that the application can perceive the configuration changes in Nacos in real time.

[0009] Preferably, building the core configuration management module in step S2 includes: Step S21: Based on the environment built in step S1, create a configuration management module responsible for the storage, update and polling status maintenance of the AppId list; Step S22: Use CopyOnWriteArrayList as a thread-safe list structure to store AppId data; Step S23: Introduce AtomicInteger as the atomic index component to record the current polling position, initialized to 0; Step S24: Integrate the monitoring interface of the Nacos configuration center so that the module can receive configuration change notifications.

[0010] Preferably, the integrated configuration monitoring mechanism in step S3 includes: Step S31: Develop configuration change monitoring logic to automatically trigger the processing flow when the AppId list in Nacos is updated; Step S32: Record the configuration change log, including the old configuration value and the new configuration value, for debugging and tracing; Step S33: Set the monitoring frequency to ensure that the configuration change can be responded to within 1 second.

[0011] Preferably, the configuration analysis process in step S4 includes: Step S41: Supporting AppId list strings separated by multiple delimiters, converting them into standardized list data, where delimiters include commas, semicolons, and spaces; Step S42: Clean the format of each parsed AppId, remove leading and trailing spaces, and filter out invalid values, including empty strings and strings containing only special characters; Step S43: Verify whether the format of the cleaned AppId complies with preset rules, which include a length between 8 and 32 bits and a combination of only letters and numbers.

[0012] Preferably, the calculation process of the polling index in step S6 is: set up: The current value of the atomic index component before the auto-increment operation, that is, the return value of atomicIndex.get(). The length of the current AppId list is listSize, is the current polling index value, that is, currentIndex, then: ; in, Indicates the remainder operation, that is, calculation Divide by The remainder after , to ensure The value range of is always between [0, 1], realizing the cyclic polling of the AppId list. That is, when the AppId list is empty, the atomic index reset mechanism needs to be triggered, that is, the value of the atomic index component is reset to 0 to ensure that the polling mechanism can be started normally after the subsequent list is updated.

[0013] Preferably, the specific implementation of the read-write lock mechanism in step S7 includes: Step S71: using ReentrantReadWriteLock as the read-write lock component; Step S72: When performing a read operation to obtain AppId, a read lock is acquired. Multiple read operations can be performed simultaneously. Step S73: When performing a write operation to update the AppId list, a write lock is acquired. At this time, any read operations and other write operations are prohibited until the write lock is released; Step S74: During the process of acquiring and releasing the lock, the lock operation log is recorded, including the operation type, time, and thread ID.

[0014] Preferably, the asynchronous processing mechanism in step S8 includes: Step S81: Configure a dedicated thread pool, set the number of core threads to 5-20, the maximum number of threads to 50-100, and the task queue capacity to 1000-5000; Step S82: Develop an asynchronous acquisition service. After receiving the AppId acquisition request, encapsulate the polling acquisition logic as a task and submit it to the thread pool. Step S83: Design a callback mechanism. When the asynchronous task is completed, the preset callback function is automatically called and the obtained AppId is passed to the subsequent business logic. Step S84: Integrate exception handling logic to capture and record null pointer exceptions, index out-of-bounds exceptions, etc. during asynchronous execution, and return the preset default AppId or error prompt information.

[0015] On the other hand, a system for implementing the above-mentioned dynamic AppId polling acquisition method is provided, comprising: The environment building module is used to build the basic environment based on the Nacos configuration center, complete the connection between the Nacos configuration center and the application system, and read the initial AppId list configuration; The core configuration management module is used to initialize the thread-safe data storage structure to save the AppId list and create an atomic index to record the polling position; Configure the monitoring module to monitor the changes in the AppId list in the Nacos configuration center in real time; The configuration parsing module is used to format and clean the new AppId list configuration when it monitors configuration changes, and generate a standardized AppId list; The list update and index reset module is used to update the locally stored AppId list based on the parsed new list and simultaneously reset the polling index to the initial position; The polling acquisition module is used to read the current polling index through atomic operations and automatically increment it when the system has an AppId acquisition requirement. It also performs boundary checks based on the list length and automatically resets the index when it exceeds the range, thus implementing cyclic polling. The thread safety guarantee module is used to adopt the read-write lock mechanism during the polling acquisition process, using the read lock for read operations and the write lock for write operations; An asynchronous processing module is configured to build an asynchronous processing mechanism based on a thread pool, perform a polling acquisition process asynchronously after receiving an AppId acquisition request, and return a result through a callback mechanism after completion.

[0016] Preferably, the core configuration management module comprises: A storage unit is configured to store AppId data in a thread-safe list structure of CopyOnWriteArrayList; An index unit is configured to introduce AtomicInteger as an atomic index component to record a current polling position, which is initialized as 0; An interface integration unit is configured to integrate a listening interface of the Nacos configuration center, so that the module can receive configuration change notifications; The asynchronous processing module comprises: A thread pool configuration unit is configured to configure a dedicated thread pool, set the number of core threads to 5-20, the maximum number of threads to 50-100, and the capacity of the task queue to 1000-5000; A task submission unit is configured to receive AppId acquisition requests, encapsulate polling acquisition logic into tasks, and submit the tasks to the thread pool; A callback unit is configured to automatically call a preset callback function when the asynchronous task is completed, and pass the acquired AppId to subsequent business logic; An exception handling unit is configured to capture and record null pointer exceptions, index out-of-range exceptions and the like during asynchronous execution, and return a preset default AppId or error prompt information.

[0017] Compared with the prior art, the application has the following advantages: 1. Dynamic configuration management: The Nacos configuration center is used to realize dynamic configuration of the AppId list, which can take effect in real time without restarting the service, greatly reducing the operation and maintenance cost and improving the flexibility and maintainability of the system; 2. Sequential polling mechanism: Atomic index and loop mechanism are used to ensure that AppIds are acquired in a predetermined order, avoiding the API call imbalance problem caused by random acquisition, and effectively preventing the flow limiting problem caused by frequent calls to some AppIds; 3. Thread safety guarantee: Through read-write locks, atomic operations and write-copy lists, data consistency is ensured in a high-concurrency environment, and race conditions are avoided when multiple threads access the AppId list simultaneously; 4. Real-time refresh synchronization: The polling state is automatically refreshed and reset when the configuration changes, ensuring that the system always uses the latest configuration and ensuring the consistency of the polling state, avoiding the problem of repeated acquisition of the same AppId after configuration refresh; 5. High-performance asynchronous processing: Adopting a multi-threaded asynchronous processing mechanism to improve the system's response speed and processing capabilities, and support AppId acquisition requirements in high-concurrency scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 is a flow chart of the method of the present invention; Figure 2 It is a flow chart of data preprocessing of the present invention. DETAILED DESCRIPTION

[0019] Below in conjunction with specific embodiment, further set forth the present invention.Should be understood that these embodiments are only used to illustrate the present invention and are not used in limiting the scope of the present invention.In addition, should be understood that after reading the content taught by the present invention, those skilled in the art can make various changes or modifications to the present invention, and these equivalent forms fall within the scope limited by the application equally.

[0020] In the present invention, terms such as "upper", "lower", "left", "right", "front", "back", "vertical", "horizontal", "side", "bottom", etc. indicating directions or positional relationships are based on the directions or positional relationships shown in the accompanying drawings. They are relational words determined only for the convenience of describing the structural relationships of the various parts or elements of the present invention, and do not specifically refer to any part or element in the present invention, and should not be understood as limiting the present invention.

[0021] Example: like Figure 1 As shown, this embodiment provides a dynamic AppId polling acquisition method, which specifically includes the following steps: Step 1: Build a dynamic configuration infrastructure: (1) Build an application environment that supports microservice architecture, integrate the dependent components required by the Nacos configuration center, and complete version compatibility configuration; (2) Configure the connection parameters between the application and Nacos (including service address, port, etc.) to ensure that the application can access the configuration center normally; (3) Create an initial configuration file in the Nacos Configuration Center, define the storage format of the AppId list (such as supporting comma- and semicolon-separated strings), and enter the initial AppId data; (4) Enable the automatic refresh function of the application configuration so that the application can perceive the configuration changes in Nacos in real time.

[0022] Step 2: Build the core configuration management module: (1) Based on the environment built in step 1, create a configuration management module responsible for the storage, update and polling status maintenance of the AppId list; (2) Use a thread-safe list structure to store AppId data to ensure reading security in a multi-threaded environment; (3) Introduce the atomic index component to record the current polling position, initialize it to 0, and use it as the starting point of the polling; (4) Integrate the monitoring interface of the configuration center so that the module can receive configuration change notifications.

[0023] Step 3: Implement configuration monitoring and parsing mechanism: (1) In the configuration management module created in step 2, develop configuration change monitoring logic to automatically trigger the processing flow when the AppId list in Nacos is updated; (2) Record configuration change logs (including old and new configuration values) for debugging and tracing; (3) Develop configuration parsing logic to support AppId list strings separated by multiple delimiters (such as commas and semicolons) and convert them into standardized list data; (4) Clean the format of each parsed AppId (such as removing leading and trailing spaces), filter invalid values, and ensure data validity.

[0024] Step 4: Design a thread-safe list update mechanism: (1) Based on the parsing results of step 3, develop an AppId list update method to synchronize the newly parsed list to local storage; (2) Use read-write locks to protect the list update process: obtain a write lock when updating to prevent data confusion caused by multiple threads modifying the data at the same time; (3) Clear the existing local list and add the newly parsed AppId data in batches to ensure the integrity of the list data; (4) After the list is updated, the index reset method is automatically called to restore the polling index to 0 to ensure that polling starts from the starting position of the new list.

[0025] Step 5: Implement atomic polling acquisition logic: (1) Develop an AppId polling acquisition interface for other system modules to call; (2) When calling the interface, first obtain the list read permission through the read lock to improve the multi-threaded concurrent reading performance; (3) Utilize the self-increment feature of atomic index to obtain the current index value and automatically increment it to ensure the thread safety of index update; (4) Add index boundary check: When the index value exceeds the list length, it is automatically reset to 0 to implement cyclic polling of the list.

[0026] Step 6: Build asynchronous processing service: (1) Configure a dedicated thread pool, set parameters such as the number of core threads, maximum number of threads, and task queue capacity to adapt to high-concurrency scenarios; (2) Develop an asynchronous acquisition service. After receiving the AppId acquisition request, submit the polling acquisition logic to the thread pool for asynchronous execution; (3) Design a callback mechanism to automatically trigger the subsequent processing flow of AppId (such as business logic call) after the asynchronous acquisition is completed; (4) Integrate exception handling logic to capture and record errors during asynchronous execution to ensure service stability.

[0027] Step 7: Develop external access interface: (1) Based on the asynchronous processing service in step 6, design a RESTful API interface to provide an external system call entry; (2) Implement a synchronous acquisition interface for debugging scenarios, and directly return the AppId obtained by polling; (3) Implement the asynchronous acquisition interface, return the processing status after receiving the request, and complete the AppId delivery through asynchronous callback; (4) Provides a manual refresh interface to support operation and maintenance personnel to actively trigger configuration refresh, and is compatible with the automatic refresh mechanism.

[0028] Step 8: Integrate monitoring and scheduled tasks: (1) Develop statistical functions to record the total number of AppIds, current polling index, total number of requests and other indicators in real time for system monitoring; (2) Configure a scheduled task to automatically trigger the AppId acquisition process at preset intervals, which is suitable for periodic business scenarios; (3) Improve log records to cover key links such as configuration updates, polling acquisition, and exception handling to facilitate problem troubleshooting; (4) Integrated monitoring and alarm mechanism, when the AppId list is empty or fails to be obtained, an alarm prompt will be automatically issued.

[0029] Step 9: System Testing and Verification: (1) Deploy Nacos services and application systems, and verify whether the initial configuration can be loaded into the local list normally; (2) Continuously call the acquisition interface to check whether the AppId is returned in order and verify the correctness of the polling mechanism; (3) Modify the AppId list in Nacos, observe whether the application automatically updates the local list and resets the index, and verify the dynamic refresh function; (4) Simulate high-concurrency scenarios, call the acquisition interface simultaneously through multiple threads, check whether there are data inconsistencies or duplicate acquisition problems, and verify thread safety; (5) Test boundary scenarios (such as empty list, single AppId, configuration format error, etc.) to verify the system's fault tolerance; (6) Conduct long-term operation tests to monitor system performance indicators and stability to ensure that they meet the requirements of the production environment.

[0030] like Figure 2 As shown, this embodiment also provides a dynamic AppId polling acquisition system, including: The environment building module is used to build the basic environment based on the Nacos configuration center, complete the connection between the Nacos configuration center and the application system, and read the initial AppId list configuration; The core configuration management module is used to initialize the thread-safe data storage structure to save the AppId list and create an atomic index to record the polling position; Configure the monitoring module to monitor the changes in the AppId list in the Nacos configuration center in real time; The configuration parsing module is used to format and clean the new AppId list configuration when it monitors configuration changes, and generate a standardized AppId list; The list update and index reset module is used to update the locally stored AppId list based on the parsed new list and simultaneously reset the polling index to the initial position; The polling acquisition module is used to read the current polling index through atomic operations and automatically increment it when the system has an AppId acquisition requirement. It also performs boundary checks based on the list length and automatically resets the index when it exceeds the range, thus implementing cyclic polling. The thread safety guarantee module is used to adopt the read-write lock mechanism during the polling acquisition process, using the read lock for read operations and the write lock for write operations; The asynchronous processing module is used to build an asynchronous processing mechanism based on the thread pool. After receiving the AppId acquisition request, it asynchronously executes the polling acquisition process and returns the result through the callback mechanism after completion.

[0031] The core configuration management modules include: The storage unit uses CopyOnWriteArrayList as a thread-safe list structure to store AppId data; Index unit, introduces AtomicInteger as the atomic index component to record the current polling position, initialized to 0; The interface integration unit integrates the monitoring interface of the Nacos configuration center, enabling the module to receive configuration change notifications; The asynchronous processing module includes: Thread pool configuration unit, configure a dedicated thread pool, set the number of core threads to 5-20, the maximum number of threads to 50-100, and the task queue capacity to 1000-5000; The task submission unit is configured to encapsulate the polling acquisition logic as a task and submit the task to a thread pool after receiving an AppId acquisition request; The callback unit is configured to automatically call a preset callback function and pass the acquired AppId to subsequent business logic after the asynchronous task is executed. The exception processing unit is configured to capture and record null pointer exceptions, index out-of-bound exceptions and the like in the asynchronous execution process, and return a preset default AppId or error prompt information.

[0032] The above is a specific description of the preferred implementation of the present application, but the present application is not limited to the described embodiments. Those skilled in the art can make various equivalent modifications or replacements without departing from the spirit of the present application. These equivalent modifications or replacements are all included in the scope defined by the claims of the present application.

Claims

1. A dynamic AppId polling acquisition method, characterized in that: The following steps are involved: Step S1: Build a basic environment based on the Nacos Configuration Center and complete the connection between the Nacos Configuration Center and the application system to read the initial AppId list configuration; Step S2: Build a core configuration management module to initialize a thread-safe data storage structure to save the AppId list, and create an atomic index in the core configuration management module to record the polling position; Step S3: Integrate a configuration monitoring mechanism into the core configuration management module to monitor the changes in the AppId list of the Nacos configuration center in real time; Step S4: When a configuration change is detected, the configuration parsing process is triggered to format and clean the new AppId list configuration to generate a standardized AppId list; Step S5: Update the locally stored AppId list based on the parsed new list, and simultaneously reset the polling index to the initial position; Step S6: When the system has an AppId acquisition requirement, the current polling index is read through atomic operations and automatically incremented. A boundary check is performed based on the list length. If the range is exceeded, the index is automatically reset to implement cyclic polling. Step S7: A read-write lock mechanism is used during the polling acquisition process. Specifically, the read-write lock mechanism is: a read lock is used during a read operation, and a write lock is used during a write operation; Step S8: Build an asynchronous processing mechanism based on the thread pool, asynchronously execute the polling acquisition process after receiving the AppId acquisition request, and return the result through the callback mechanism after completion.

2. A dynamic AppId polling acquisition method according to claim 1, characterized in that: The basic environment based on the Nacos configuration center in step S1 includes: Step S11: Build an application environment that supports the microservice architecture, integrate the dependent components required by the Nacos configuration center, and complete the version compatibility configuration; Step S12: Configure the connection parameters between the application and Nacos, including the service address and port, to ensure that the application can access the configuration center normally; Step S13: Create an initial configuration file in the Nacos Configuration Center, define the storage format of the AppId list, support comma and semicolon separated strings, and enter the initial AppId data; Step S14: Enable the automatic configuration refresh function of the application so that the application can perceive the configuration changes in Nacos in real time.

3. A dynamic AppId polling acquisition method according to claim 1, characterized in that: The construction of the core configuration management module in step S2 includes: Step S21: Based on the environment built in step S1, create a configuration management module responsible for the storage, update and polling status maintenance of the AppId list; Step S22: Use CopyOnWriteArrayList as a thread-safe list structure to store AppId data; Step S23: Introduce AtomicInteger as the atomic index component to record the current polling position, initialized to 0; Step S24: Integrate the monitoring interface of the Nacos configuration center so that the module can receive configuration change notifications.

4. A dynamic AppId polling acquisition method according to claim 1, characterized in that: The integrated configuration monitoring mechanism in step S3 includes: Step S31: Develop configuration change monitoring logic to automatically trigger the processing flow when the AppId list in Nacos is updated; Step S32: Record the configuration change log, including the old configuration value and the new configuration value, for debugging and tracing; Step S33: Set the monitoring frequency to ensure that the configuration change can be responded to within 1 second.

5. A dynamic AppId polling acquisition method according to claim 1, characterized in that: The configuration analysis process in step S4 includes: Step S41: Supporting AppId list strings separated by multiple delimiters, converting them into standardized list data, where delimiters include commas, semicolons, and spaces; Step S42: Clean the format of each parsed AppId, remove leading and trailing spaces, and filter out invalid values, including empty strings and strings containing only special characters; Step S43: Verify whether the format of the cleaned AppId complies with preset rules, which include a length between 8 and 32 bits and a combination of only letters and numbers.

6. A dynamic AppId polling acquisition method according to claim 1, characterized in that: The calculation process of the polling index in step S6 is: set up: The current value of the atomic index component before the auto-increment operation, that is, the return value of atomicIndex.get(). The length of the current AppId list is listSize, is the current polling index value, that is, currentIndex, then: ； in, Indicates the remainder operation, that is, calculation Divide by The remainder after , to ensure The value range of is always between [0, 1], realizing the cyclic polling of the AppId list. That is, when the AppId list is empty, the atomic index reset mechanism needs to be triggered, that is, the value of the atomic index component is reset to 0 to ensure that the polling mechanism can be started normally after the subsequent list is updated.

7. A dynamic AppId polling acquisition method according to claim 1, characterized in that: The specific implementation of the read-write lock mechanism in step S7 includes: Step S71: using ReentrantReadWriteLock as the read-write lock component; Step S72: When performing a read operation to obtain AppId, a read lock is acquired. Multiple read operations can be performed simultaneously. Step S73: When performing a write operation to update the AppId list, a write lock is acquired. At this time, any read operations and other write operations are prohibited until the write lock is released; Step S74: During the process of acquiring and releasing the lock, the lock operation log is recorded, including the operation type, time, and thread ID.

8. A dynamic AppId polling acquisition method according to claim 1, characterized in that: The asynchronous processing mechanism in step S8 includes: Step S81: Configure a dedicated thread pool, set the number of core threads to 5-20, the maximum number of threads to 50-100, and the task queue capacity to 1000-5000; Step S82: Develop an asynchronous acquisition service. After receiving the AppId acquisition request, encapsulate the polling acquisition logic as a task and submit it to the thread pool. Step S83: Design a callback mechanism. When the asynchronous task is completed, the preset callback function is automatically called and the obtained AppId is passed to the subsequent business logic. Step S84: Integrate exception handling logic to capture and record null pointer exceptions and index out-of-bounds exceptions during asynchronous execution, and return the preset default AppId or error prompt information.

9. A system for implementing any one of the dynamic AppId polling acquisition methods according to claims 1-8, characterized in that: include: The environment building module is used to build the basic environment based on the Nacos configuration center, complete the connection between the Nacos configuration center and the application system, and read the initial AppId list configuration; The core configuration management module is used to initialize the thread-safe data storage structure to save the AppId list and create an atomic index to record the polling position; Configure the monitoring module to monitor the changes in the AppId list in the Nacos configuration center in real time; The configuration parsing module is used to format and clean the new AppId list configuration when it monitors configuration changes, and generate a standardized AppId list; The list update and index reset module is used to update the locally stored AppId list based on the parsed new list and simultaneously reset the polling index to the initial position; The polling acquisition module is used to read the current polling index through atomic operations and automatically increment it when the system has an AppId acquisition requirement. It also performs boundary checks based on the list length and automatically resets the index when it exceeds the range, thus implementing cyclic polling. The thread safety guarantee module is used to adopt the read-write lock mechanism during the polling acquisition process, using the read lock for read operations and the write lock for write operations; The asynchronous processing module is used to build an asynchronous processing mechanism based on the thread pool. After receiving the AppId acquisition request, it asynchronously executes the polling acquisition process and returns the result through the callback mechanism after completion.

10. The system according to claim 9, characterized in that The core configuration management module includes: The storage unit uses CopyOnWriteArrayList as a thread-safe list structure to store AppId data; Index unit, introduces AtomicInteger as the atomic index component to record the current polling position, initialized to 0; The interface integration unit integrates the monitoring interface of the Nacos configuration center, enabling the module to receive configuration change notifications; The asynchronous processing module includes: Thread pool configuration unit, configure a dedicated thread pool, set the number of core threads to 5-20, the maximum number of threads to 50-100, and the task queue capacity to 1000-5000; The task submission unit is used to encapsulate the polling acquisition logic as a task and submit it to the thread pool after receiving the AppId acquisition request; The callback unit is used to automatically call the preset callback function after the asynchronous task is completed, and pass the obtained AppId to the subsequent business logic; The exception handling unit is used to capture and record null pointer exceptions and index out-of-bounds exceptions during asynchronous execution, and return the preset default AppId or error prompt information.

Images