A distributed unique identifier generation method based on a three-level degradation mechanism

Abstract

The application discloses a distributed unique identifier generation method based on a three-level degradation mechanism. A plurality of identifier generation strategies with different priorities are preconfigured, and the highest priority strategy is initially enabled by default. A unique identifier is generated by preferentially calling the current strategy, and if the generation is successful, the current strategy is retained and the result is output. If the current strategy fails, the lower-level strategy is switched and retried in turn according to the priority from high to low, until the identifier generation is successful or all strategies are traversed. After switching to the new strategy and successfully generating the identifier, the current effective strategy in the cache is updated, and the strategy degradation record is retained synchronously. Through the hierarchical strategy automatic degradation and retry mechanism, the unique identifier generation success rate is improved, the strategy abnormal degradation event is facilitated to be counted and maintained, and the stable output of the identifier in the distributed scene is ensured.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method for generating distributed unique identifiers based on a three-level degradation mechanism. Background Technology

[0002] Distributed unique identifier generation systems, as core infrastructure of distributed architectures, are widely used in microservices, cloud computing, and big data scenarios. Among related technologies, an ID generation system based on the Snowflake algorithm is constructed through the coordinated combination of timestamps, worker node identifiers, and sequence numbers. Specifically, this system covers the entire chain from centralized storage to local caching, including key steps such as timestamp synchronization, node allocation, and sequence number incrementing, aiming to ensure global uniqueness and high performance.

[0003] However, existing ID generation methods directly adopt a single centralized storage or fixed node identifier allocation strategy, without systematic degradation and fault tolerance mechanisms for network jitter, containerized dynamic environments, and multi-business line isolation. This may lead to system paralysis in the event of a single point of failure, node conflicts caused by changes in container IPs, or cross-business line data pollution affecting ID uniqueness, thereby affecting the overall availability and operational efficiency of the distributed system. Summary of the Invention

[0004] The present invention aims to at least partially solve one of the technical problems in the related art.

[0005] Therefore, the first objective of this invention is to propose a distributed unique identifier generation method based on a three-level degradation mechanism.

[0006] Another objective of this invention is to propose a distributed unique identifier generation device based on a three-level degradation mechanism.

[0007] The third objective of this invention is to provide a computer device.

[0008] A fourth objective of this invention is to provide a non-transitory computer-readable storage medium.

[0009] To achieve the above objectives, a first aspect of the present invention proposes a distributed unique identifier generation method based on a three-level degradation mechanism, comprising: S1, Configure multiple identifier generation strategies with different priorities, and set the current strategy as the highest priority strategy; S2, try to generate a unique identifier using the current strategy. If the generation is successful, remember the current strategy and output the identifier. S3. If the current strategy generation fails, try the next priority strategy in order of priority until success or all strategies fail. S4: When successfully switching to a new policy, update the current policy in memory and record the downgrade event.

[0010] In one embodiment of the present invention, configuring multiple identifier generation strategies with different priorities and setting the current strategy as the highest priority strategy includes: Configure Redis mode, IP mode, and MAC mode as identifier generation strategies; Set Redis mode as the current policy, IP mode as the second-highest priority policy, and MAC mode as the lowest priority policy.

[0011] In one embodiment of the present invention, configuring Redis mode, IP mode, and MAC mode as identifier generation strategies further includes: Different RedisKey namespaces are used based on business line identifiers to achieve business isolation.

[0012] In one embodiment of the present invention, it further includes: WorkerIDs are allocated from the Redis cluster using the ShardedWorkerIdAllocator sharding algorithm, which includes calculating the number of shards: , in The range of WorkerIDs is specified; the sharding order is randomly shuffled, and the first slot of each shard is tried in turn. If the slot is occupied, all slots of the shard are linearly scanned, and the free WorkerID is obtained atomically through the SETNXEX operation.

[0013] In one embodiment of the present invention, the step of attempting to generate a unique identifier using the current strategy, and if successful, memorizing the current strategy and outputting the identifier, includes: Get the current timestamp, the WorkerID corresponding to the current strategy, and the sequence number; According to the formula: , Assemble a unique identifier, where This is the current timestamp. This is the timestamp of the beginning of the era. This is the number of bits shifted left by the timestamp. It is a combination of WorkerID and serial number; The current policy is remembered and the identifier is output through AtomicReference.

[0014] In one embodiment of the present invention, the strategy of trying the next priority level in order of priority includes: Iterate through the generator array and try each generator in order of priority. If the current generator fails, try the next generator; If all generators fail, a runtime exception is thrown.

[0015] In one embodiment of the present invention, the recording of degradation events includes: Update AtomicReference to the new current policy; Update the degradation counter, record the success counter and the error counter, and obtain the statistics using the getStats() method.

[0016] To achieve the above objectives, a second aspect of the present invention provides a distributed unique identifier generation device based on a three-level degradation mechanism, comprising: The multi-priority strategy configuration module is used to configure multiple identifier generation strategies with different priorities and set the current strategy as the highest priority strategy. The main strategy identifier generation module is used to attempt to generate a unique identifier using the current strategy. If the generation is successful, the current strategy is remembered and the identifier is output. The degradation strategy polling module is used to try the next priority strategy in order of priority if the current strategy fails to be generated, until it succeeds or all strategies fail. The policy state update and recording module is used to update the current policy in memory and record the downgrade event when a new policy is successfully switched.

[0017] This invention discloses a distributed unique identifier generation method and apparatus based on a three-level degradation mechanism. Through the three-level degradation mechanism and dynamic bit structure, it effectively solves the single point of failure and environment adaptability problems of ID generation in distributed systems, and achieves high availability and high concurrency.

[0018] To achieve the above objectives, a third aspect of this application provides a computer device, including a processor and a memory; wherein the processor runs a program corresponding to the executable program code by reading executable program code stored in the memory, for implementing the method described in the first aspect embodiment.

[0019] To achieve the above objectives, a fourth aspect of this application provides a non-transitory computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method described in the first aspect.

[0020] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Attached Figure Description

[0021] Figure 1 This is a flowchart of a distributed unique identifier generation method based on a three-level degradation mechanism according to an embodiment of the present invention; Figure 2 This is a system overall architecture diagram according to an embodiment of the present invention; Figure 3 This is a flowchart of a three-level degradation strategy according to an embodiment of the present invention; Figure 4 This is a schematic diagram of a 64-bit ID structure according to an embodiment of the present invention; Figure 5 This is a flowchart of the WorkerID allocation process according to an embodiment of the present invention; Figure 6 This is a schematic diagram of a service isolation mechanism according to an embodiment of the present invention; Figure 7 This is a flowchart of the clock protection mechanism according to an embodiment of the present invention; Figure 8 This is a diagram of a multi-cluster monitoring architecture according to an embodiment of the present invention; Figure 9 This is a monitoring and statistics system architecture diagram according to an embodiment of the present invention; Figure 10 This is a structural diagram of a distributed unique identifier generation device based on a three-level degradation mechanism according to an embodiment of the present invention; Figure 11 It is a computer device according to an embodiment of the present invention. Detailed Implementation

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

[0023] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0024] The following description, with reference to the accompanying drawings, describes a distributed unique identifier generation method and apparatus based on a three-level degradation mechanism according to an embodiment of the present invention.

[0025] Figure 1 This is a flowchart of a distributed unique identifier generation method based on a three-level degradation mechanism according to an embodiment of the present invention, as shown below. Figure 1 As shown, it includes: S1, Configure multiple identifier generation strategies with different priorities, and set the current strategy as the highest priority strategy; S2, try to generate a unique identifier using the current strategy. If the generation is successful, remember the current strategy and output the identifier. S3. If the current strategy generation fails, try the next priority strategy in order of priority until success or all strategies fail. S4: When successfully switching to a new policy, update the current policy in memory and record the downgrade event.

[0026] This invention provides a distributed unique identifier generation system and method based on a three-level degradation mechanism, which is achieved through the following technical means.

[0027] The overall architecture diagram of the system of this invention is as follows: Figure 2 As shown, the layered structure of the monitoring and early warning layer, application access layer, strategy decision layer, core algorithm layer and storage service layer, as well as the data flow between each layer, are illustrated.

[0028] Furthermore, the invention proposes a three-level degradation ID generation architecture, comprising: Level 1: Centralized storage mode (RedisMode); utilizing Redis as a centralized storage service to uniformly allocate and manage worker node IDs (WorkerIDs); employing the ShardedWorkerIdAllocator sharding algorithm + SETNXEX mechanism to ensure the uniqueness and security of ID allocation; supporting STANDARD mode (512 nodes) and EXTENDED mode (6144 nodes); providing a high-concurrency ID generation capability of 1024 / ms; Level 2: Network Address Mode (IPMode): Automatically downgrades to IP address mode when Redis service is unavailable; uses the last two segments of the local IP address as the WorkerID to ensure uniqueness in the container environment; supports 65,536 IP combinations to meet the needs of large-scale deployments; although the sequence number is reduced to 6 bits, it is perfectly acceptable as a fallback solution; Third Level: Physical Address Mode (MACMode), uses MAC address hash to calculate the WorkerID when the network is completely unavailable; as a final fallback solution, it ensures that the system can generate a unique ID under any circumstances; provides basic availability guarantees to avoid complete system failure.

[0029] Furthermore, the flowchart of the three-level degradation strategy is as follows: Figure 3The diagram illustrates the automatic degradation and recovery process between Redis mode, IP mode, and MAC mode. It employs a sequential attempt-based degradation strategy (DistributedFallBackSequence) to achieve automated mode switching: Degradation facade: DistributedFallBackSequence acts as the degradation facade, uniformly managing the three generation strategies (Redis, IP, and MAC); Sequential attempt mechanism: Each generator is tried sequentially according to the configured order, automatically switching to the next generator when the primary generator fails; State memory: Once a usable generator is found, it is remembered via AtomicReference for subsequent requests; Fault recovery: When the current generator fails, the remembered state is automatically cleared, and the process restarts from the beginning.

[0030] Furthermore, it provides comprehensive monitoring and statistical capabilities: Success Counter: records the total number of times ID generation was successful; Degradation Counter: records the number of times degradation switching was triggered; Error Counter: records the total number of times generation failed; Statistical Reset: supports manual reset of statistical data for easy periodic statistics.

[0031] Furthermore, regarding the dynamic bit structure design, this module adopts a modular bit allocation architecture, achieving pattern recognition through the WorkerID range. It includes three independent components: a timestamp module, a WorkerID module, and a serial number module. A schematic diagram of the 64-bit ID structure is shown below. Figure 4 As shown, the bit distribution of the timestamp (41 bits) and Body (22 / 23 bits) is displayed, where the Body implicitly distinguishes between Redis / IP / MAC modes through the WorkerID range.

[0032] Furthermore, the WorkerID allocation flowchart is as follows: Figure 5 The diagram illustrates the atomic allocation process of WorkerIDs using the ShardedWorkerIdAllocator algorithm based on Redis. This invention implicitly distinguishes different modes through WorkerID ranges, enabling ID structure switching under a degradation strategy: Standard ID structure (64 bits): 1 sign bit, 41-bit timestamp (millisecond level); no mode bit (distinguished by WorkerID range); 22-bit dynamic area; Dynamic area structure: Mode=0 (Redis / MAC mode): 12-bit ID + 10-bit sequence number; Mode=1 (IP mode): 16-bit ID + 6-bit sequence number; Through the implicit distinction of WorkerID ranges, the system can optimize ID space allocation in different modes. STANDARD mode is compatible with the standard TwitterSnowflake (22-bit body), while EXTENDED mode supports more WorkerIDs (23-bit body).

[0033] Furthermore, an implicit differentiation mode based on the WorkerID range is adopted to achieve pattern recognition of the ID structure: STANDARD mode (22-bit body): Redis mode WorkerID 0511, IP mode 512767, MAC mode 7681023; EXTENDED mode (23-bit body): Redis mode WorkerID 06143, IP mode 61447167, MAC mode 71688191.

[0034] Furthermore, a variable-length field allocation strategy is designed: Redis / MAC mode (Mode=0): *WorkerID: 12 bits, supporting 4096 nodes *Serial number: 10 bits, generating 1024 IDs per millisecond; IP mode (Mode=1): *WorkerID: 16 bits, supporting 65536 nodes *Serial number: 6 bits, generating 64 IDs per millisecond; Automatic switching: Automatically selects the corresponding bit allocation scheme according to the current mode.

[0035] Furthermore, the timestamp design is optimized to support long-term stable operation: Timestamp bit length: 41 bits, precision in milliseconds; Start epoch: 2010110409:42:54.657UTC (1288834974657L); Usage period: 2^41 / (1000*365*24*3600)≈69.7 years; Overflow protection: Early warning when the timestamp approaches the upper limit to avoid overflow and ID duplication; Clock rollback processing: Automatic waiting when a rollback of less than 5ms is detected, and an exception is thrown when it is greater than 5ms.

[0036] Furthermore, regarding the business isolation mechanism, this invention provides a complete business isolation solution: a schematic diagram of the business isolation mechanism is shown below. Figure 6The diagram illustrates a three-tiered namespace structure based on business line, mode, and node isolation. RedisKey isolation: Different business lines use independent RedisKey namespaces; Key format: snowflake:{businessline}:cursor, snowflake:{businessline}:worker:{id}; completely avoiding cross-business line data pollution and WorkerID conflicts; WorkerID range isolation: Within the same business line, different degradation modes use different WorkerID ranges; Redis mode: 0511 (STANDARD) or 06143 (EXTENDED); IP mode: 512767 (STANDARD) or 61447167 (EXTENDED); MAC mode: 7681023 (STANDARD) or 71688191 (EXTENDED). Monitoring group isolation: Nodes from different business lines are automatically grouped and displayed in the monitoring system; supports unified management of business lines across clusters; operations personnel can clearly view the health status of each business line. Furthermore, a three-level namespace isolation structure is designed: Level 1 namespace: business line identifier (businessLine), such as order, user, payment; Level 2 namespace: mode identifier (mode), such as redis, ip, mac; Level 3 namespace: node identifier (workerId). Key format: snowflake:{businessLine}:{mode}:worker:{workerId} Example: snowflake:order:redis:worker:123.

[0037] Furthermore, a WorkerID range segmentation mechanism is implemented: Redis mode range: 0511 (STANDARD) or 06143 (EXTENDED); IP mode range: 512767 (STANDARD) or 61447167 (EXTENDED); MAC mode range: 7681023 (STANDARD) or 71688191 (EXTENDED); Isolation guarantee: different modes use different key prefixes to ensure that no conflicts occur.

[0038] Furthermore, it supports automatic identification of monitoring groups: Automatic discovery: Automatically discover all business lines through the RedisKEYS command; Group aggregation: Aggregate node status by business line and calculate the health of each business line; Display optimization: Provide multi-dimensional views by business line, by cluster, and by mode; Alarm isolation: Alarms are sent in groups by business line to avoid alarm storms.

[0039] Furthermore, regarding the intelligent clock protection mechanism, this invention designs a comprehensive clock rollback processing mechanism: the clock protection mechanism flowchart is as follows. Figure 7 The diagram illustrates the processing logic for clock rollback detection, auto-healing, and lifetime protection. Auto-healing: When NTP time jitter (<5ms) is detected, the system automatically waits for the time to catch up; this avoids ID duplication issues caused by time rollback; and improves system robustness. Lifetime protection: Explicitly detects whether the 41-bit timestamp exceeds the 69.7-year limit; provides early warning of timestamp overflow risks; and offers clear error messages for easy maintenance. Furthermore, an automatic healing mechanism is designed to automatically catch up when an NTP time jitter of less than 5ms is detected. A lifetime protection function is introduced to explicitly detect whether the 41-bit timestamp exceeds the 69.7-year upper limit. A multi-level threshold strategy is employed to differentiate between three scenarios: minor jitter, severe rollback, and time overflow.

[0040] Furthermore, for unified monitoring of multiple clusters, this invention provides the industry's first ID generation system and AI-driven intelligent early warning system that support unified monitoring of multiple Redis clusters: The multi-cluster monitoring architecture diagram is shown below. Figure 8 The diagram illustrates the connection relationships between the monitoring server and multiple Redis clusters, as well as the monitoring data aggregation process. Unified Management Platform: A single monitoring server can manage multiple Redis clusters simultaneously; it supports unified monitoring of clusters in different environments (development, testing, production); and provides cross-cluster aggregated views and statistical analysis. Intelligent Grouping Display: Automatically identifies nodes from different business lines; displays cluster status and mode distribution by business line; supports intuitive visualization of degraded status (green = Redis, yellow = IP, red = MAC). RESTful API Interface: Provides standard API interfaces to obtain cluster information, business line grouping, and node status; supports integration and secondary development of third-party systems; and facilitates integration with other operation and maintenance tools.

[0041] Furthermore, it enables unified management of multiple clusters, allowing a single monitoring server to manage multiple Redis clusters simultaneously. It features intelligent grouping and display functionality, automatically identifying and grouping nodes from different business lines. A RESTful API interface is provided to support third-party system integration and secondary development.

[0042] Furthermore, this invention provides an AI-driven intelligent early warning system based on large-scale model capabilities, ensuring timely delivery of early warning information through dual channels: WeChat and SMS. The intelligent early warning system architecture diagram is shown below. Figure 9The diagram illustrates the complete process of data collection, AI analysis, alarm generation, and notification execution. The intelligent analysis capabilities based on a large model include: Anomaly Pattern Recognition: Utilizing a large model to analyze historical monitoring data to identify patterns such as periodic anomalies and gradual performance degradation; Predictive Maintenance: Predicting system health status within the next 24 hours based on historical trends, providing early warnings of resource bottlenecks; Root Cause Analysis: When multiple nodes experience anomalies simultaneously, the large model analyzes correlations to pinpoint common root causes; Intelligent Suggestions: Providing handling suggestions and optimization solutions based on analysis results; Intelligent Alarm Enhancement Based on a Large Model: Intelligent Alarm Classification: Dynamically adjusting alarm levels based on contextual information (peak business periods, historical failure frequency); Alarm Merging and Suppression: Intelligently merging related alarms to avoid alarm storms and reduce alarm fatigue; Alarm Escalation Mechanism: Automatically escalating alarm levels based on alarm duration to ensure timely problem handling; Alarm Correlation Analysis: Analyzing the correlation between alarms to identify root causes.

[0043] Furthermore, large-scale intelligent analysis capabilities are introduced to achieve anomaly pattern recognition, predictive maintenance, and root cause analysis. An intelligent alarm grading mechanism is designed to dynamically adjust alarm levels based on peak business periods and historical failure frequencies. An alarm merging and suppression function is implemented to intelligently merge related alarms and avoid alarm storms.

[0044] The system architecture of this invention is divided into the following layers: This system adopts a layered architecture design, and the overall architecture is as follows: Figure 2As shown, it includes the following core components: Application Access Layer: SpringBootStarter component: provides auto-configuration capabilities, activated by snowflake.enabled=true; RESTful API interface: provides an HTTP interface for external systems to call; MyBatisPlus integration: implements automatic generation of database primary keys; Strategy Decision Layer: DistributedFallBackSequence: a fallback facade class that manages three generation strategies based on a sequential trial mechanism; Monitoring and Statistics Module: uses AtomicLong to count the number of successes, fallbacks, and errors; State Memory Module: uses AtomicReference to remember currently available generators. Core Algorithm Layer: RedisSnowFlakeSequence: a Redis mode strategy that allocates WorkerIDs using the ShardedWorkerIdAllocator sharding algorithm; IPModeStrategy: an IP mode strategy that generates WorkerIDs based on the local IP address; MACModeStrategy: a MAC mode strategy that generates WorkerIDs based on MAC address hashes. Storage Service Layer: Redis Cluster: stores WorkerID allocation status and monitoring data; Local Cache: caches the current WorkerID and mode status to reduce Redis access. Monitoring and Alert Layer: MonitorController: Monitoring interface, providing a cluster status query API; AlertEngine: Alert engine, implementing intelligent alarm classification and notification; Statistics Module: Based on large-scale model anomaly pattern recognition, predictive maintenance, root cause analysis, and intelligent suggestions. Data flow between layers: Application access layer receives requests > Policy decision layer selects mode > Core algorithm layer generates ID > Storage service layer persists status > Monitoring and alert layer monitors in real time.

[0045] Furthermore, the application interface layer provides two access methods: SpringBootStarter and direct API calls; the integration layer includes a DistributedFallBackSequence fallback facade class for unified management of generation strategies; the core algorithm layer contains concrete implementations of the three generation strategies; the tool support layer includes network tools, configuration management, and constant definitions; and the storage layer includes Redis database storage and monitoring data storage. Furthermore, for the three - level downgrade ID generation algorithm, this embodiment describes the core algorithm process of three - level downgrade ID generation. The system adopts a sequential attempt mechanism to achieve automatic downgrading, and uses AtomicReference to remember the currently available generator. Algorithm 1: Three - level downgrade ID generation algorithm. Input: business identifier businessLine, mode configuration modeConfig; Output: unique identifier ID; Step 1: Initialize the three - level mode set M = {Redis, IP, MAC}, and set the current mode m = Redis; Step 2: Check if currentSequence has been remembered. If it has been remembered, try to use this generator; Step 3: If the current generator fails or has not been remembered, traverse the generator array [Redis, IP, MAC] and try in order; Step 4: Once a generator succeeds, remember this generator through AtomicReference and directly use it subsequently; Step 5: If all generators fail, throw RuntimeException; Step 6: Statistical monitoring: successCount (number of successes), fallbackCount (number of downgrades), errorCount (number of errors); Step 7: ID assembly is implemented in each Sequence class and not in the downgrade algorithm; Step 8: Return the generated ID; ID assembly formula (implemented in each Sequence class): ID = ((TT0) << shift)|body where: T: current timestamp (in milliseconds); T0: starting epoch timestamp (default value: 1288834974657L); shift: number of bits to left - shift the timestamp (22 bits for STANDARD mode, 23 bits for EXTENDED mode); body: combination of WorkerID and sequence number; <<: bit - shift left operator; |: bit - or operator; where: T is the timestamp, T0 is the starting epoch (1288834974657L), W is WorkerID, S_bits is the number of bits of the sequence number, S is the sequence number; Downgrade statistical formula: Stats = [successCount, fallbackCount, errorCount]; Obtain statistical information through the getStats() method and reset statistics through the resetStats() method.

[0046] Furthermore, RedisWorkerID Allocation Algorithm: This embodiment describes an atomic allocation algorithm for WorkerID based on Redis. The ShardedWorkerIdAllocator sharding algorithm is used to achieve efficient allocation of WorkerID, which is compatible with RedisStandalone and RedisCluster. Algorithm 2: WorkerID Allocation Algorithm: Input: business line identifier businessLine, client information clientInfo, ID range [min, max]; Output: Allocated WorkerID or failure identifier (1); Step 1: Calculate sharding parameters: poolSize = max - min + 1, shardCount = min(64, max(4, poolSize / 128)), shardSize = poolSize / shardCount; Step 2: Randomly shuffle the sharding order Collections.shuffle(shardIndices); Step 3: In Phase 1, traverse each shard and try the first slot of the shard: SET(snowflake:{businessLine}:worker:{workerId}, clientInfo, NX, EX, ttl); Step 4: If the first slot of all shards in Phase 1 is occupied, enter Phase 2 to randomly shuffle the sharding order again and linearly scan all slots of each shard; Step 5: After finding an idle slot, obtain a lock atomically through the SETNXEX operation; Step 6: If the acquisition is successful, return the allocated workerId; Step 7: If no successful allocation is made after scanning all shards, return 1 (pool exhausted). Sharding calculation formula: shardCount = min(MAX_SHARDS, max(MIN_SHARDS, poolSize / TARGET_SHARD_SIZE)), where TARGET_SHARD_SIZE = 128, MIN_SHARDS = 4, MAX_SHARDS = 64; Sharding range formula: shardStart(i) = min + i * shardSize + min(i, remainder), shardEnd(i) = shardStart(i) + shardSize + (i < remainder? 1 : 0) - 1; Concurrency safety guarantee: Atomicity is achieved through the SETNXEX (set if not exists and set expiration time) feature of Redis to avoid ID conflicts in a distributed environment; Furthermore, regarding IP address resolution algorithms, this implementation describes a WorkerID generation algorithm based on IP addresses. A unique identifier is generated by extracting a specific segment from the local IP address. Algorithm 3: IP Address WorkerID Generation Algorithm; Input: Local IPv4 address IP=(b0,b1,b2,b3); Output: WorkerID and DataCenterID; Step 1: Obtain all network interfaces of the local machine, filtering loopback interfaces and virtual interfaces; Step 2: Select the first valid IPv4 address and extract the byte array [b0,b1,b2,b3]; Step 3: Calculate WorkerID=ipModeBase+(lastOctet%rangeSize), taking the last segment of the IP address and mapping it to the corresponding mode range; Step 4: Calculate DataCenterID=thirdOctet%128 (EXTENDED mode) or 0 (STANDARD mode), taking the third segment of the IP address; Step 5: Return (WorkerID, DataCenterID). Key formulas: WorkerID calculation: W=ipModeBase+(IP[3]%rangeSize), where IP[3] is the last segment and rangeSize is the mode range size; DataCenterID calculation: D=IP[2]%128 (EXTENDED mode) or 0 (STANDARD mode), where IP[2] is the 3rd segment; IP segment extraction formula: IP[i]=bytes[i]&0xFF, converting bytes to unsigned integers; Capacity analysis: STANDARD mode WorkerID space = 256 (8 bits), EXTENDED mode WorkerID space = 1024 (10 bits); Further, MAC address hashing algorithm: This implementation describes a WorkerID generation algorithm based on MAC address. A unique identifier is calculated by extracting specific bytes from the MAC address. Algorithm 4: MAC address WorkerID generation algorithm, Input: Local MAC address MAC=[m0,m1,m2,m3,m4,m5]; Output: WorkerID; Step 1: Obtain the MAC address corresponding to the local network interface; Step 2: Traverse the entire 6-byte MAC address and calculate the hash value hash=(hash<<8)|(b&0xFF); Step 3: Take the absolute value of the hash value hash=Math.abs(hash); Step 4: Map to the MAC mode range: WorkerID_final=macBase+(hash%macPoolSize); Step 5: Return WorkerID_final; Original hash value: H = iterate through MAC[0] to MAC[5], H = (H<<8)|(MAC[i]&0xFF), and then take the absolute value; Range mapping formula: W = macBase + (H%macPoolSize), mapped to the MAC mode range (STANDARD:7681023, EXTENDED:71688191); Byte to integer formula: MAC[i] = bytes[i]&0xFF; Conflict probability analysis: P(conflict) = 1e^(n^2 / (2*256)), where n is the number of nodes.

[0047] This invention also offers the following technical advantages: Enhanced high availability: Through a three-level degradation mechanism, system availability is increased from the traditional 99.99% to 99.999%, significantly reducing system outages caused by single points of failure. Strong environment adaptability: Perfectly adapts to dynamic containerized and cloud-native environments; the IP mode automatically adapts to changes in the IP addresses of container instances without manual intervention. Comprehensive business isolation: Through RedisKey isolation and WorkerID range isolation, complete isolation is achieved when multiple business lines share infrastructure, avoiding mutual interference. High degree of automation: Fault detection, degradation switching, and recovery mechanisms are fully automated, requiring no manual intervention and reducing operational costs. Comprehensive monitoring capabilities: Provides a unified monitoring and management platform, allowing operations personnel to understand system status in real time and quickly locate and resolve problems. Excellent performance: The Redis mode supports ID generation capabilities of 1 million+ QPS, meeting the needs of high-concurrency scenarios. Intelligent Early Warning Capabilities: Utilizing a dual-channel early warning mechanism via WeChat and SMS, real-time notifications of degradation events are achieved, transforming the fault response mode from passive to proactive notification. This significantly shortens fault detection and handling time, substantially improving system operation and maintenance efficiency and business continuity. Intelligent Analysis Capabilities: Innovatively introducing large-scale model technology enables intelligent analysis capabilities such as anomaly pattern recognition, predictive maintenance, and root cause analysis. The large-scale model can analyze historical monitoring data, identify periodic anomalies and progressive performance degradation patterns, predict future system health, and analyze correlations to pinpoint root causes when multiple nodes are simultaneously abnormal. Early warning accuracy is improved, significantly reducing false alarms and missed alarms. Predictive maintenance capabilities proactively identify potential problems, reducing sudden failures and significantly improving operation and maintenance efficiency. Intelligent Alarm Enhancement: Innovatively introducing large-scale model technology to design an intelligent alarm enhancement mechanism, including intelligent alarm grading (dynamically adjusted based on peak business periods and historical fault frequency), alarm merging and suppression (intelligently merging related alarms to avoid alarm storms), alarm escalation mechanism (automatically escalating based on duration), and alarm correlation analysis (identifying root causes). The accuracy and effectiveness of alerts have been significantly improved, fundamentally resolving the issue of alert fatigue among operations and maintenance personnel. An intelligent tiered mechanism ensures that different levels of problems receive appropriate attention, alert merging reduces invalid alerts, an alert escalation mechanism ensures that serious problems are handled promptly, and alert correlation analysis helps quickly pinpoint the root cause. Deployment costs are reduced: multiple business lines can share the same infrastructure, and business isolation mechanisms avoid conflicts, lowering deployment and operations and maintenance costs.

[0048] To achieve the above embodiments, such as Figure 10 As shown, this embodiment also provides a distributed unique identifier generation device 10 based on a three-level degradation mechanism, including: The multi-priority policy configuration module 100 is used to configure multiple identifier generation policies with different priorities and set the current policy as the highest priority policy. The main strategy identifier generation module 200 is used to attempt to generate a unique identifier using the current strategy. If the generation is successful, the current strategy is remembered and the identifier is output. The degradation strategy polling module 300 is used to try the next priority strategy in order of priority if the current strategy fails to be generated, until it succeeds or all strategies fail. The strategy state update and recording module 400 is used to update the current strategy in memory and record the downgrade event when a new strategy is successfully switched.

[0049] This invention discloses a distributed unique identifier generation device based on a three-level degradation mechanism. Through the three-level degradation mechanism and dynamic bit structure, it effectively solves the single point of failure and environment adaptability problems of ID generation in distributed systems, and achieves high availability and high concurrency.

[0050] To implement the methods of the above embodiments, the present invention also provides a computer device, such as... Figure 11 As shown, the computer device 600 includes a memory 601 and a processor 602; wherein, the processor 602 reads executable program code stored in the memory 601 to run a program corresponding to the executable program code, so as to implement the various steps of the method described above.

[0051] To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in the foregoing embodiments.

[0052] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0053] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

Claims

1. A distributed unique identifier generation method based on a three-level degradation mechanism, characterized in that, include: S1, Configure multiple identifier generation strategies with different priorities, and set the current strategy as the highest priority strategy; S2, try to generate a unique identifier using the current strategy. If the generation is successful, remember the current strategy and output the identifier. S3. If the current strategy generation fails, try the next priority strategy in order of priority until success or all strategies fail. S4: When successfully switching to a new policy, update the current policy in memory and record the downgrade event.

2. The method as described in claim 1, characterized in that, The configuration of multiple identifier generation strategies with different priorities, and the setting of the current strategy as the highest priority strategy, includes: Configure Redis mode, IP mode, and MAC mode as identifier generation strategies; Set Redis mode as the current policy, IP mode as the second-highest priority policy, and MAC mode as the lowest priority policy.

3. The method as described in claim 2, characterized in that, The configuration of Redis mode, IP mode, and MAC mode as identifier generation strategies also includes: Different RedisKey namespaces are used based on business line identifiers to achieve business isolation.

4. The method as described in claim 3, characterized in that, The method further includes: WorkerIDs are allocated from the Redis cluster using the ShardedWorkerIdAllocator sharding algorithm, which includes calculating the number of shards: ， in The range of WorkerIDs is specified; the sharding order is randomly shuffled, and the first slot of each shard is tried in turn. If the slot is occupied, all slots of the shard are linearly scanned, and the free WorkerID is obtained atomically through the SETNXEX operation.

5. The method as described in claim 1, characterized in that, The process of attempting to generate a unique identifier using the current strategy, and if successful, remembering the current strategy and outputting the identifier, includes: Get the current timestamp, the WorkerID corresponding to the current strategy, and the sequence number; According to the formula: ， Assemble a unique identifier, where This is the current timestamp. This is the timestamp of the beginning of the era. This is the number of bits shifted left by the timestamp. It is a combination of WorkerID and serial number; The current policy is remembered and the identifier is output through AtomicReference.

6. The method as described in claim 1, characterized in that, The strategy of trying the next priority level in order of priority includes: Iterate through the generator array and try each generator in order of priority. If the current generator fails, try the next generator; If all generators fail, a runtime exception is thrown.

7. The method as described in claim 1, characterized in that, The recorded degradation events include: Update AtomicReference to the new current policy; Update the degradation counter, record the success counter and the error counter, and obtain the statistics using the getStats() method.

8. A distributed unique identifier generation device based on a three-level degradation mechanism, characterized in that, include: The multi-priority strategy configuration module is used to configure multiple identifier generation strategies with different priorities and set the current strategy as the highest priority strategy. The main strategy identifier generation module is used to attempt to generate a unique identifier using the current strategy. If the generation is successful, the current strategy is remembered and the identifier is output. The degradation strategy polling module is used to try the next priority strategy in order of priority if the current strategy fails to be generated, until it succeeds or all strategies fail. The policy state update and recording module is used to update the current policy in memory and record the downgrade event when a new policy is successfully switched.

9. A computer device, characterized in that, Including processor and memory; The processor runs a program corresponding to the executable program code stored in the memory to implement the method as described in any one of claims 17.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 17.

Images