Method, apparatus, device and storage medium for unique identifier generation

Abstract

The application relates to the technical field of intelligent devices, and discloses a method, device and equipment for unique identifier generation and a storage medium. The method comprises the following steps: in the case that a unique identifier (ID) request of a current client is received, a current timestamp and a current serial number are acquired, wherein the timestamp is obtained based on logical clock back compensation, and the serial number is obtained through batch pre-allocation; a node ID of the current client and a corresponding lightweight entropy value are acquired, wherein the node ID is generated according to local multi-dimensional factors, and the lightweight entropy value is obtained based on random disturbance; the current timestamp, the current serial number, the node ID and the lightweight entropy value are subjected to compression coding processing to obtain the current ID of the client, and the current ID is sent to the current client. In this way, the generation of a distributed ID with no center dependence, high stability, high security and high performance is realized.

Description

Technical Field

[0001] This application relates to the field of smart device technology, such as methods, apparatus, devices, and storage media for generating unique identifiers. Background Technology

[0002] In distributed systems, microservice architectures, and cloud-native elastic scaling scenarios, core business processes such as order transactions, user management, logistics scheduling, equipment control, and payment settlement all require the generation of globally unique, highly available, and highly stable unique identifiers (IDs) for core scenarios such as data primary key identification, business chain tracing, data sharding, and distributed transaction identification. With the continuous expansion of internet business volume and the exponential growth of business concurrency, coupled with the dynamic scaling, frequent restarts, and cross-regional deployment characteristics of server clusters and container nodes, stringent requirements are placed on the distributed ID generation system. These requirements include: global uniqueness, high-concurrency generation performance, decentralized external dependencies, clock rollback fault tolerance, automatic multi-node adaptation, low-predictability security, and high service availability. Currently, mainstream distributed ID generation solutions in the industry mainly include UUID solutions, Redis / database auto-increment solutions, Snowflake algorithm, etc. Each solution has a certain degree of adaptability, but in complex enterprise-level distributed scenarios, they all have inherent defects that cannot be avoided, and cannot simultaneously meet the requirements of high availability, high performance, anomaly resistance, and high security. For example, in the UUID generation solution, the generated ID strings are too long, unordered, and highly random. In database storage scenarios, unordered IDs lead to index fragmentation and frequent index rebuilding, significantly reducing database read and write performance, and cannot be used as primary keys for high-performance databases. At the same time, UUIDs have an unstructured design, do not support high-concurrency batch generation, have poor scalability, and cannot adapt to high-traffic, high-throughput enterprise-level business scenarios. On the other hand, if the central component of the Redis / database auto-increment solution fails, or if there are failures such as downtime, network fluctuations, or master-slave synchronization delays, it will directly cause the global ID generation service to be interrupted, resulting in extremely low system availability and inability to support ultra-high concurrency business requirements.

[0003] In summary, these distributed ID generation technologies cannot meet the core requirements of decentralized dependency, anti-clock rollback, multi-node automatic negotiation, stable ID generation under ultra-high concurrency, and high security with unpredictability. There is an urgent need for a brand-new enterprise-level distributed ID generation solution to meet the needs of modern distributed business scenarios with cloud-native, microservice, and ultra-high concurrency.

[0004] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0005] To provide a basic understanding of some aspects of the disclosed embodiments, a brief summary is given below. This summary is not intended as a general commentary, nor is it intended to identify key / important components or describe the scope of protection of these embodiments, but rather as a prelude to the detailed description that follows.

[0006] This disclosure provides a method, apparatus, device, and storage medium for generating unique identifiers, in order to solve the technical problem that ID generation schemes cannot simultaneously achieve high availability, high performance, high adaptability, and high security.

[0007] In some embodiments, the method includes: Upon receiving a unique identifier (ID) request from the current client, obtain the current timestamp and the current sequence number. The timestamp is obtained based on logical clock rollback compensation, and the sequence number is obtained through batch pre-allocation. Get the node ID and corresponding lightweight entropy value of the current client. The node ID is generated based on local multidimensional factors, and the lightweight entropy value is obtained based on random perturbation. The current timestamp, current sequence number, node ID, and lightweight entropy value are compressed and encoded to obtain the client's current ID, which is then sent to the current client.

[0008] In this way, the clock rollback risk is avoided through a logical clock compensation mechanism, the concurrency performance is improved through batch pre-allocation of sequence numbers, node IDs are automatically generated based on local multi-dimensional factors to achieve manual configuration and adaptation, and ID security is improved by combining entropy value perturbation. Overall, the generation of distributed IDs with no central dependency, high stability, high security and high performance is achieved.

[0009] In some embodiments, obtaining the current timestamp includes: obtaining the current physical timestamp and the previous logical timestamp of the last output; If the current physical timestamp is greater than or equal to the previous logical timestamp, determine the current logical timestamp from the current physical timestamp and output the current logical timestamp as the current timestamp; If the current physical timestamp is less than the previous logical timestamp, a monotonically increasing current logical timestamp is generated based on a preset safe delay window mechanism combined with a logical clock advancement mechanism, and the current logical timestamp is output as the current timestamp.

[0010] As can be seen, by comparing physical time with historical logical time in real time, differentiating between normal time scenarios and clock rollback abnormal scenarios, dual-mode adaptation to time fluctuations ensures that the output timestamp continuously and monotonically increases under any time state, fundamentally eliminating ID duplication and business data conflict problems caused by clock rollback, and greatly improving the fault tolerance and availability of the distributed system.

[0011] In some embodiments, the method of generating a monotonically increasing current logical timestamp based on a preset security delay window mechanism combined with a logical clock advancement mechanism includes: The relative difference between the current physical timestamp and the previous logical timestamp is determined as the clock rollback magnitude; If the clock rollback magnitude is less than or equal to the first threshold, at the end of the current millisecond of the previous logical timestamp, the current logical timestamp is gradually increased in nanosecond increments until the increased current logical timestamp is greater than or equal to the previous logical timestamp, and the finally increased timestamp is determined as the current logical timestamp. If the clock rollback magnitude is greater than the first threshold, the sum of the previous logical timestamp and the millisecond step size is used to determine the current logical timestamp.

[0012] In this way, differentiated strategies are adapted for small and large callbacks. Small callbacks wait for physical time to catch up through nanosecond-level delays to avoid excessive logical time offsets. Large callbacks directly activate the logical clock advancement mechanism to avoid service blocking and downtime. At the same time, the handling logic for the two abnormal scenarios is distinguished to balance service stability and time accuracy.

[0013] In some embodiments, obtaining the current serial number includes: If no batch serial number matching the current timestamp is saved, allocate a set number of current batch serial numbers, extract the starting serial number from the current batch serial numbers, and determine it as the current serial number; If a batch of serial numbers matching the current timestamp has been saved, and if there are unextracted serial numbers in the current batch, the first unextracted serial number will be determined as the current serial number. If all the current batch serial numbers have been extracted, a set number of current batch serial numbers will be reallocated, and the starting serial number in the current batch will be extracted and determined as the current serial number.

[0014] Mechanisms such as batch number segment pre-allocation, memory cache reuse, and dynamic number segment replenishment can be adopted to reduce frequent lock contention and system calls, solve the problems of low single-millisecond sequence number upper limit, easy overflow under high concurrency, and need to wait for the next millisecond in traditional systems, significantly improve ID throughput in ultra-high concurrency scenarios, and eliminate performance jitter under high concurrency.

[0015] In some embodiments, obtaining the node ID of the current client includes: If a pre-generated persistent metadata file exists, the historical stable node ID stored in the persistent metadata file is used as the node ID of the current client. The persistent metadata file is created and persistently stored after the node ID of the current client is generated for the first time. In the absence of a pre-generated persistent metadata file, obtain the local multidimensional factors and get the first node ID based on the local multidimensional factors. The local multidimensional factors include two or more of the following: local communication address information, random salt information, startup timestamp, and device information. If the first node ID passes the conflict detection, the first node ID is determined as the node ID of the current client. If the first node ID fails the conflict detection, new random salt information is generated and the first node ID is obtained, until the first node ID passes the conflict detection.

[0016] As can be seen, by automatically calculating local multi-dimensional factors, iteratively verifying cluster conflicts, and persistently reusing local files, node IDs can be generated and reused automatically and stably. This completely eliminates the traditional method of manually configuring node IDs, adapts to cloud-native dynamic scaling and frequent node restart scenarios, eliminates multi-node ID conflicts from a mechanism perspective, reduces operation and maintenance costs, and improves cluster adaptability and stability.

[0017] In some embodiments, obtaining the lightweight entropy value includes: The initial entropy value is obtained by concatenating the thread ID, random salt information, and hardware random number. The initial entropy value is truncated by a bitmask to obtain a lightweight entropy value with a set number of bits.

[0018] In this way, by generating entropy values ​​through multi-dimensional random perturbation factors and truncating the number of bits of the standard entropy value through bitmasking, random perturbation is added to the structured ID without significantly increasing the ID length. This breaks the defect of predictable regularity in traditional IDs, effectively prevents external parties from inferring business data through IDs, and improves the security and anti-cracking capability of ID generation.

[0019] In some embodiments, obtaining the client's current ID includes: The current timestamp, current sequence number, node ID, and lightweight entropy value are combined in a structured manner to obtain the initial ID; Compress the initial ID into the current ID in a high-radix short code format.

[0020] By using structured concatenation, the information in each dimension of the ID is ensured to be regular, orderly, and parsable. Then, the ID length is shortened by high-radix compression encoding, which solves the problems of traditional UUIDs being too long and database indexing performance being poor. It takes into account the orderliness, uniqueness, and storage adaptability of the ID, and is suitable for core business scenarios such as database primary keys and database sharding.

[0021] In some embodiments, the apparatus includes a processor and a memory storing program instructions, wherein the processor is configured to execute the method described above for generating a unique identifier when executing the program instructions.

[0022] In some embodiments, the cloud server device includes: a device body, wherein the aforementioned means for generating a unique identifier is installed on the device body.

[0023] In some embodiments, the storage medium stores program instructions that, when executed, perform the method described above for generating unique identifiers.

[0024] The method, apparatus, device, and storage medium for generating unique identifiers provided in this disclosure can achieve the following technical effects: Through the collaborative design of a logical clock rollback compensation mechanism, a batch pre-allocation counter mechanism, a node self-negotiation persistence mechanism, a lightweight entropy enhancement mechanism, and high-radix compression encoding, a decentralized, highly available, high-performance, and highly secure enterprise-grade distributed ID generation system has been constructed. This not only avoids the component dependency failure risks and performance bottlenecks of centralized ID generation schemes, and solves the industry pain points of traditional Snowflake algorithms such as clock rollback duplicate IDs, conflicts easily caused by manual node configuration, high-concurrency sequence overflow, and high ID predictability, but also overcomes the defects of UUIDs being unordered and having poor storage performance. Therefore, it can perfectly adapt to complex enterprise-level scenarios such as cloud-native elastic scaling, dynamic scaling of microservice clusters, ultra-high-concurrency transactions, and cross-regional distributed deployment, possessing multiple advantages such as service stability, high-performance concurrency, maintenance-free deployment, and high data security, demonstrating extremely high versatility and adaptability.

[0025] The above general description and the description below are exemplary and illustrative only and are not intended to limit this application. Attached Figure Description

[0026] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations and drawings do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are shown as similar elements. The drawings are not to be scaled. And wherein: Figure 1 This is a schematic diagram of an architecture for a unique identifier generation system provided in an embodiment of this disclosure; Figure 2 This is a flowchart illustrating a method for generating unique identifiers provided in an embodiment of this disclosure; Figure 3 This is a schematic diagram of signaling interaction for a unique identifier generation method provided in an embodiment of this disclosure; Figure 4 This is a schematic diagram of a unique identifier generation device provided in an embodiment of this disclosure; Figure 5This is a schematic diagram of a unique identifier generation device provided in an embodiment of this disclosure; Figure 6 This is a schematic diagram of a unique identifier generation device provided in an embodiment of this disclosure; Figure 7 This is a schematic diagram of the structure of a sweeping robot provided in an embodiment of this disclosure. Detailed Implementation

[0027] To provide a more detailed understanding of the features and technical content of the embodiments of this disclosure, the implementation of the embodiments of this disclosure will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for illustrative purposes only and are not intended to limit the embodiments of this disclosure. In the following technical description, for ease of explanation, several details are used to provide a full understanding of the disclosed embodiments. However, one or more embodiments may still be implemented without these details. In other cases, well-known structures and devices may be simplified in their depiction to simplify the drawings.

[0028] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate for the embodiments of this disclosure described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion.

[0029] Unless otherwise stated, the term "multiple" means two or more.

[0030] In this embodiment of the disclosure, the character " / " indicates that the objects before and after it are in an "or" relationship. For example, A / B means: A or B.

[0031] The term "and / or" describes an association between objects, indicating that three relationships can exist. For example, A and / or B means: A or B, or A and B.

[0032] In this embodiment, a fully automatic, highly stable, high-throughput, and highly secure globally unique ID is generated automatically in a distributed cluster environment through the coordinated operation of a logical clock rollback compensation mechanism, a batch pre-allocation counter mechanism, a node self-negotiation persistence mechanism, a lightweight entropy enhancement mechanism, and high-level compression encoding. It systematically addresses various shortcomings of traditional distributed ID technologies across multiple dimensions, including controllable time, concurrent serial number expansion, seamless node adaptation, enhanced ID security, and optimized storage. This allows for broad adaptation to complex industrial-grade application scenarios such as microservice architectures, cloud-native elastic scaling, ultra-high-concurrency business transactions, and cross-regional distributed deployments.

[0033] Figure 1This is a schematic diagram of an architecture for a unique identifier generation system provided in an embodiment of this disclosure. Figure 1 As shown, the system adopts a distributed architecture with centralized scheduling on the server side and distributed requests from multiple clients. The whole system consists of cloud server devices 100 and one or more clients 200 to form a distributed interaction structure. It can adapt to cloud-native distributed business scenarios with multi-node cluster deployment and dynamic scaling, and can meet the enterprise-level distributed ID generation needs of large scale, high concurrency and dynamic scaling. Among them, cloud server device 100 is the core ID generation service node, used to respond to ID requests from each client 200 and independently complete the entire process of generating, verifying, and encoding unique identifiers. For example... Figure 1 As shown, the cloud server device 100 mainly includes five core functional modules: a time engine 110, a counter engine 120, a node manager 130, an entropy factor module 140, and an ID assembly encoder 150. Each module performs its function independently but also works in concert to complete a fully automated ID generation logic without centralized dependencies. In some embodiments, the server device 100 may also have a built-in local persistent storage unit, which can realize asynchronous storage and abnormal recovery of node metadata and serial number running status, ensuring that the status is not lost and the IDs are not duplicated after the service restarts. Specifically, the Time Engine 110 provides the system with stable, monotonically increasing standardized timestamps. It incorporates clock rollback detection, a security delay window, and a logical clock compensation mechanism, enabling dynamic timestamp correction in abnormal scenarios such as server physical time rollback, time calibration, and time zone switching, completely eliminating ID duplication issues caused by time reversal. The Counter Engine 120 is the core component for high-concurrency number generation, integrating batch number segment pre-allocation, lock-free memory incrementing, and asynchronous persistence mechanisms. By pre-caching serial numbers in batches and reducing high-frequency lock contention and system calls, it significantly increases the maximum concurrent number generation limit within milliseconds, avoiding serial number overflow and service lag issues in high-concurrency scenarios. The Node Manager 130 is responsible for the fully automatic generation and cluster adaptation of service node identities. It automatically calculates node identifiers based on local multi-dimensional environmental factors combined with random salt values, iterates and optimizes through a cluster conflict detection mechanism, and persistently stores node information in local metadata files, achieving the effects of no number change upon service restart, no manual configuration of multiple nodes in the cluster, and no ID conflicts. The entropy factor module 140 generates lightweight random perturbation entropy values. It generates random factors by fusing thread IDs, hardware random numbers, and node-specific salt values ​​from multiple dimensions, and uses bitmasking to truncate and normalize the number of bits, effectively breaking the regularity of IDs and improving the unpredictability and business security of identifiers. The ID assembly encoder 150 integrates ID structured splicing and high-radix compression encoding functions. It is responsible for structurally combining the calibrated timestamp, auto-incrementing sequence number, unique node ID, and security entropy value into the original ID in a fixed bit order. It then uses a high-radix compression algorithm to optimize the original ID for shorter codes, outputting a final unique ID that is more suitable for database index storage. Of course, as an independent service node without central dependency, the cloud server device 100 supports single-machine deployment and multi-cluster horizontal scaling deployment modes. Multiple cloud server devices 100 can independently complete ID generation calculations. There is no need for distributed lock coordination between nodes, nor is there any need to rely on centralized scheduling and storage components such as third-party databases and Redis. From the architectural level, the risk of global ID generation service unavailability caused by centralized component downtime, network anomalies, and synchronization delays is completely avoided, greatly improving the overall availability and disaster recovery capability of the system. Client 200 serves as the system's business request terminal, and may include various functional units that require a globally unique identifier as their business identifier, such as microservice business nodes, container service instances, business application servers, and terminal business systems. When performing operations such as business order creation, user information registration, logistics link recording, payment transaction processing, and device data reporting, each client 200 can proactively initiate an ID generation request to the cloud server device 100 if it needs a unique identifier for the data record. It will then wait for and receive the compressed and encoded globally unique ID returned by the cloud server device 100, and apply this ID to core business scenarios such as business data primary key identification, business end-to-end tracing, distributed transaction marking, data sharding and partitioning, and abnormal data location. During the operation of the overall distributed system, each cloud server device 100 completes the entire ID issuance calculation process based on its internal modular collaborative logic: the node manager 130 completes local multi-dimensional factor collection, automatic node ID negotiation and persistent storage, realizing automated cluster adaptation of multiple service nodes without manual configuration and ID conflict; the time engine 110 calibrates physical time in real time and dynamically compensates for clock rollback anomalies, ensuring that the global output timestamp is monotonically and irreversibly increasing throughout the process; the counter engine 120's batch number segment pre-allocation and lock-free counting mechanism stably supports the ultra-high concurrency ID requests from a massive number of clients 200; at the same time, the entropy factor module 140 introduces lightweight random disturbances to complete ID security enhancement and optimization; finally, the ID assembly encoder 150 uniformly completes the structured splicing and high-level compression encoding of IDs, outputting a compliant, concise and unique final identifier. The entire distributed ID generation system achieves decentralized deployment, multi-node adaptive scaling, ultra-high concurrency throughput, clock anomaly fault tolerance, and high-security anti-predictability integrated ID generation capabilities. It perfectly solves the technical shortcomings of traditional distributed ID systems, such as central component dependence, poor cluster adaptability, clock rollback conflicts, high-concurrency performance jitter, strong ID predictability, and poor database storage adaptability. It is fully adaptable to various complex enterprise-level business scenarios such as cloud-native dynamic scaling, large-scale cluster deployment, ultra-high concurrency transactions, and cross-regional distributed deployment.

[0034] Those skilled in the art can merge, split, or reconstruct the functional modules in the cloud server according to business logic, program encapsulation structure, and functional iteration requirements. For example, the time engine 110 and counter engine 120 used to generate timestamps and serial numbers can be merged into a first acquisition module, specifically responsible for completing anti-cashback timestamp calibration and high-concurrency batch generation of serial numbers; the node manager 130 and entropy factor module 140 used to generate unique node identifiers and security random factors can be merged into a second acquisition module, specifically responsible for automatic node negotiation and ID entropy enhancement encryption; the ID assembly encoder 150 can be used independently as a transcoding module, responsible for final ID structured assembly and compressed short code output. Regardless of the division, merging, or splitting method adopted for the internal functional modules of the cloud server device 100, its core technical logic remains unchanged. It can independently respond to the ID generation requests of each client 200, autonomously complete the entire decentralized numbering process from time calibration, serial number allocation, node identity confirmation, entropy enhancement to assembly encoding, without relying on any external central components, and has extremely strong architectural adaptability and scalability. Figure 2 This is a flowchart illustrating a method for generating unique identifiers provided in an embodiment of this disclosure. Figure 2 As shown, the method includes: Step 201: Upon receiving a unique identifier (ID) request from the current client, obtain the current timestamp and the current sequence number. The timestamp is obtained based on logical clock rollback compensation, and the sequence number is obtained through batch pre-allocation.

[0035] The client can be a business request terminal, specifically including various functional units that require a globally unique identifier as a business identifier, such as microservice business nodes, container service instances, business application servers, and terminal business systems. During business operation, when the client performs business operations that require a unique primary key identifier, such as order creation, user registration, payment transactions, device reporting, log recording, and database sharding and table writing, it initiates a unique identifier ID generation request to the cloud server device.

[0036] The client currently sending the ID request is considered the current client. Upon receiving the unique ID request from the current client, the cloud server device invokes the underlying core engine to retrieve the current valid timestamp and the current valid sequence number. The timestamp is not directly collected from the server's native physical time, but rather a monotonically increasing logical timestamp after clock rollback detection, delay window verification, and logical clock compensation calibration, fundamentally avoiding the timestamp backtracking problem caused by system time rollback. The sequence number is not generated in real-time for each request, but rather is an auto-incrementing sequence number within milliseconds obtained through batch number segment pre-allocation, memory buffer reuse, and dynamic number segment replenishment mechanisms, enabling continuous, overflow-free number retrieval under ultra-high concurrency request scenarios.

[0037] In some embodiments, obtaining the current timestamp includes: obtaining the current physical timestamp and the previously output logical timestamp; if the current physical timestamp is greater than or equal to the previously output logical timestamp, determining the current logical timestamp from the current physical timestamp and outputting the current logical timestamp as the current timestamp; if the current physical timestamp is less than the previously output logical timestamp, generating a monotonically increasing current logical timestamp based on a preset security delay window mechanism combined with a logical clock advancement mechanism, and outputting the current logical timestamp as the current timestamp.

[0038] The system collects the server's current physical timestamp (currentTimestamp) in real time, and simultaneously reads the previous logical timestamp (lastTimestamp) stored in the local persistent cache corresponding to the last successfully generated ID. A dual timestamp comparison mechanism is used to monitor for clock rollback anomalies in real time. If the current physical timestamp (currentTimestamp) is greater than or equal to the previous logical timestamp (lastTimestamp), the server time is considered normal and there is no rollback anomaly. The current physical timestamp is then directly calibrated to the latest logical timestamp, and this logical timestamp is output as the base timestamp for this ID generation. This ensures that the timestamp aligns with the system's physical time under normal circumstances, preserving the sequential order of the IDs. If the current physical timestamp (currentTimestamp) is less than the previous logical timestamp (lastTimestamp), it is accurately determined that the server has experienced clock rollback or system time reversal. In this case, the system is prohibited from directly using the incorrect physical timestamp. Instead, a security delay window mechanism combined with a logical clock advance mechanism is activated to adaptively compensate and generate a continuously monotonically increasing current logical timestamp, ensuring that the timestamp only increases and does not decrease under any abnormal scenario.

[0039] In some embodiments, the method of generating a monotonically increasing current logical timestamp based on a preset security delay window mechanism combined with a logical clock advance mechanism includes: determining the relative difference between the current physical timestamp and the previous logical timestamp as the clock rollback magnitude; when the clock rollback magnitude is less than or equal to a first threshold, gradually increasing the current logical timestamp in nanosecond steps at the end of the current millisecond of the previous logical timestamp until the increased current logical timestamp is greater than or equal to the previous logical timestamp, and determining the final increased timestamp as the current logical timestamp; when the clock rollback magnitude is greater than the first threshold, determining the current logical timestamp as the sum of the previous logical timestamp and the millisecond step.

[0040] Specifically, the relative difference between the current physical timestamp and the previous logical timestamp is first calculated. This difference is defined as the current clock rollback magnitude. A fixed time threshold is pre-configured as the first threshold (exemplarily set to 5ms, which can be flexibly configured according to business scenarios) to distinguish between minor and major rollback scenarios, thereby achieving layered fault tolerance processing. When a clock rollback amplitude is detected to be less than or equal to a first threshold, it is determined to be a slight, short-term clock rollback. In this case, instead of immediately initiating a logical time offset, a preset safety delay window is opened. At the end of the current millisecond period corresponding to the previous logical timestamp, the timestamp is gradually increased in nanosecond-level fine steps, continuously waiting for the physical time to gradually catch up with and surpass the historical logical timestamp, until the increased logical timestamp is greater than or equal to the previous logical timestamp. The finally stabilized timestamp is then determined as the current logical timestamp. This mechanism can avoid unnecessary logical time offsets caused by small time jitters, maximizing the authenticity of the ID time dimension. The value range corresponding to the nanosecond-level fixed step size can be 1ns to 100ns.

[0041] When a clock rollback exceeding the first threshold is detected, it is considered a significant clock rollback. Continuing to wait for physical time to catch up would cause service congestion and business delays. In this case, the system immediately closes the waiting window, terminates the delay, and triggers a logical clock advance mechanism for forced time compensation. The time compensation offset is calculated using the preset compensation formula logicalOffset = lastTimestamp - currentTimestamp + 1. A new current logical timestamp is generated by adding a fixed millisecond step size to the previous logical timestamp as a baseline, ensuring that the timestamp continuously and monotonically increases, preventing service interruption and blocking. The fixed millisecond step size can be 1ms, or it could be 0.5ms or 2ms, etc.

[0042] The cloud server needs to obtain not only the current timestamp but also the current sequence number. In some embodiments, obtaining the current sequence number includes: if no batch sequence numbers matching the current timestamp are stored, allocating a set number of current batch sequence numbers and extracting the starting sequence number from the current batch sequence numbers to determine the current sequence number; if batch sequence numbers matching the current timestamp are stored, and if there are unextracted sequence numbers in the current batch sequence numbers, determining the first unextracted sequence number as the current sequence number; and if all current batch sequence numbers have been extracted, reallocating a set number of current batch sequence numbers and extracting the starting sequence number from the current batch sequence numbers to determine the current sequence number.

[0043] After the cloud server performs timestamp calibration, it simultaneously executes the entire process of batch pre-allocation of the current serial number, lock-free memory counting, and asynchronous persistence. The batch pre-allocation mechanism employs a segment-based batch caching mode for efficient serial number retrieval. Instead of generating serial numbers per single request, the cloud server requests consecutive serial numbers in batches at the granularity of "entire segment." For example, it can pre-allocate 1024 consecutive serial numbers to form an independent sequence range, pre-loading and storing the entire consecutive sequence range in a local memory buffer pool for persistent caching. Thus, when a large number of concurrent ID requests arrive from clients, the cloud server only needs to perform a lightweight memory increment operation to complete the serial number allocation, without frequently triggering underlying resource requests, lock contention, and system kernel calls. This significantly reduces CPU and I / O overhead in high-concurrency scenarios and significantly increases the single-machine concurrent throughput limit.

[0044] Meanwhile, a lock-free memory counting mechanism can be adopted to adapt to ultra-high concurrency scenarios. In some embodiments, the AtomicLong atomic class combined with the CAS lock-free spin method can be used to achieve concurrent auto-increment of the sequence number within milliseconds. Relying on CPU instruction-level atomic operations to ensure multi-threaded concurrency safety, the sequence number is continuously incremented under the premise of lock-free and non-blocking, completely avoiding the performance jitter and thread blocking problems caused by lock contention, and adapting to ultra-high concurrency number generation scenarios of hundreds of thousands or millions per second.

[0045] Building upon number segment pre-allocation and lock-free memory counting, some embodiments further incorporate an asynchronous persistence mechanism to ensure service status recovery and prevent sequence number rollback. A separate background daemon thread can be started independently, without consuming resources from the main business's number issuance thread. It uses a periodic polling asynchronous method to uniformly store the core operational status data of the current service node. This includes key parameters such as the current maximum used sequence number value, the current node's operational status, the latest valid logical timestamp, and the number segment cache usage progress. The persistence carrier can be a local disk file or lightweight KV local storage. This mechanism employs asynchronous non-blocking write logic and will not affect the performance of the main process ID generation.

[0046] Through the asynchronous persistence mechanism, after each restart of the cloud server device, node restart, or recovery from an unexpected crash, the historical maximum sequence number and logical time status stored locally can be automatically read. Based on the historical succession status, new sequence numbers are continuously allocated, effectively avoiding the problem of reusing sequence numbers from the beginning and causing global ID duplication conflicts caused by sequence rollback after service restart. This enables breakpoint resume transmission and self-healing recovery of the number issuance status, greatly improving the stability and reliability of the system under abnormal scenarios.

[0047] Based on the above-mentioned mechanism, the specific logic for obtaining the serial number in this invention is as follows: The system maintains a batch serial number segment cache that corresponds one-to-one with the current logical timestamp after calibration, prioritizing the reuse of pre-allocated memory segments to reduce real-time allocation overhead. If no valid batch serial number matching the current timestamp is stored in the memory buffer pool, it indicates that the current time dimension is the first issuance of serial numbers. The system will automatically allocate a fixed number (1024 in the example) of consecutive serial numbers as the current batch serial number segment, cache the entire segment in the local memory buffer pool, and then extract the starting serial number from the current batch serial number as the current serial number for this ID generation, completing the first serial number retrieval.

[0048] If the memory buffer pool already contains a batch of serial numbers matching the current timestamp, then it further determines whether there are any unextracted free serial numbers in the current cached number segment. If there are still unextracted free serial numbers in the current batch of serial numbers, then the first unextracted serial number in the current number segment can be determined as the current serial number in the auto-incrementing order using a CAS lock-free auto-incrementing method, achieving ultra-high concurrency continuous number retrieval within milliseconds; if all the current batch of serial numbers has been retrieved and there are no remaining free serial numbers, then the dynamic expansion and replenishment logic will be triggered, automatically reallocating the same set number of new batch serial numbers and updating them to the memory buffer pool, clearing the old number segment status, and retrieving the starting serial number of the new batch of serial numbers as the current serial number, ensuring continuous, uninterrupted, and overflow-free number retrieval within the same millisecond / logical time, completely eliminating the defects of traditional algorithm serial number overflow waiting and lag.

[0049] Furthermore, this embodiment of the disclosure deeply integrates the batch pre-allocation mechanism, lock-free counting mechanism, and asynchronous persistence mechanism with the aforementioned clock rollback compensation mechanism and logical clock mode to form a complete fault-tolerant closed loop. The system employs two completely independent and non-overlapping sets of serial number ranges for normal physical time scenarios and logical clock compensation abnormal scenarios, achieving physical isolation and preventing cross-scenario ID collisions at the data structure level. For example, in normal physical time scenarios, the basic serial number range of 0~4095 is used; in logical clock rollback compensation scenarios, it switches to the compensation serial number range of 4096~8191. Through this dual-range isolation design, the problem of ID duplication and conflict between the clock rollback stage and the normal operation stage is completely eliminated, greatly improving the stability of serial number issuance in extreme abnormal scenarios.

[0050] Step 202: Obtain the node ID and corresponding lightweight entropy value of the current client. The node ID is generated based on local multidimensional factors, and the lightweight entropy value is obtained based on random perturbation.

[0051] The cloud server needs to generate the current ID of the corresponding client based on the current timestamp, current sequence number, node ID, and lightweight entropy value. Therefore, it is also necessary to obtain the node ID and corresponding lightweight entropy value of the current client.

[0052] In some embodiments, obtaining the node ID of the current client includes: if a pre-generated persistent metadata file exists, using the historically stable node ID stored in the persistent metadata file as the node ID of the current client, wherein the persistent metadata file is created and persistently stored after the node ID of the current client is first generated; if no pre-generated persistent metadata file exists, obtaining a local multidimensional factor and obtaining a first node ID based on the local multidimensional factor, wherein the local multidimensional factor includes two or more of the following: local communication address information, random salt information, startup timestamp, and device information; if the first node ID passes conflict detection, determining the first node ID as the node ID of the current client; and if the first node ID fails conflict detection, generating new random salt information and obtaining the first node ID, until the first node ID passes conflict detection.

[0053] The node ID is automatically generated and maintained by the cloud server device. The generation and update of the node ID rely entirely on local multi-dimensional environmental factors, random salt encryption calculation and local metadata persistence mechanism. No manual intervention is required throughout the process. It is suitable for cloud-native business scenarios such as dynamic start and stop of containers, horizontal expansion of clusters and frequent service restarts. Specifically, after the cloud server starts, it first checks whether a pre-generated persistent metadata file exists locally. In one embodiment, the persistent metadata file is the node.meta local metadata file. This metadata file is a dedicated configuration file that is automatically created and permanently stored locally after the node successfully generates a valid and unique node ID for the first time. The file stores one or more parameters such as a unique random salt value generated when the node is first initialized, a device fingerprint digest, a service startup time digest, container running information, and a historical unique nodeId, which are used to ensure the consistency and stability of the node identifier during the long-term operation of the service. If a pre-generated persistent metadata file exists locally, it indicates that the current service node is in a restart and reuse scenario. The historical stable nodeId stored in the metadata file can be directly read and used as the node ID of the current service, which is also the node ID of the current client. This eliminates the need for recalculation, rehashing, and conflict checking, ensuring that the node identifier remains constant after multiple service restarts, container rebuilds, and process restarts, thus avoiding cluster adaptation chaos caused by frequent changes in node ID. If the pre-generated persistent metadata file does not exist locally, it means that the current node is a newly deployed node that is starting for the first time. The cloud server device needs to start the fully automatic node negotiation and generation logic: First, collect local multi-dimensional factors, which include two or more of the following: local communication address information (IP address), hardware device information (MAC address), process PID, container instance ID, service startup timestamp, and random salt information. By fusing multi-dimensional hardware and software features, the node features are guaranteed to be highly unique. The cloud server device needs to mix the collected multidimensional factors with dynamically generated random salt values, and perform an overall hash operation using the SHA-256 secure hash algorithm or the MurmurHash efficient hash algorithm. A preset fixed number of bits are extracted from the hash result to generate the initial first node ID. This first node ID integrates device hardware characteristics, network characteristics, running process characteristics, and random salt characteristics, possessing a very strong foundation for uniqueness. Furthermore, to avoid duplicate node IDs due to hash collisions across multiple nodes in the cluster, a global conflict detection process needs to be performed on the generated first node ID. If the first node ID passes the cluster conflict detection, proving that it is unique and valid in the entire distributed cluster, then this first node ID is designated as the current official node ID. A local persistent metadata file can also be created simultaneously, permanently storing key information such as the current node ID, random salt value, device fingerprint, and startup time summary in the local file for reuse in subsequent service restarts. If the first node ID fails the cluster conflict detection, it means that the currently generated first node ID collides with an existing node ID in the cluster. The system automatically iterates and updates, regenerating a completely new random salt information, and then performs a new hash operation using local multi-dimensional factors to generate a new first node ID. The cluster conflict check is then performed again, and this process is repeated until the newly generated node ID passes the conflict detection. Finally, the automatic negotiation and initialization of the current node ID is completed. Through the iterative conflict correction mechanism, the global uniqueness of all node IDs in the distributed cluster is completely guaranteed, eliminating the need for manual input and maintenance configuration, and achieving fully automatic adaptation to cloud-native clusters.

[0054] The cloud server device also needs to further obtain a lightweight entropy value for security enhancement. In some embodiments, obtaining the lightweight entropy value includes: concatenating the thread ID, random salt information, and hardware random number to obtain an initial entropy value; and truncating the initial entropy value with a bitmask to obtain a lightweight entropy value with a set number of bits.

[0055] The entropy value collection dimensions encompass three independent perturbation factors: thread ID, node-specific random salt information, and hardware-generated true random numbers. These multi-source factors are coupled together, significantly increasing the difficulty of cracking the entropy value. Specifically, the thread ID serves as the running identifier for the current business request processing thread, exhibiting dynamic change characteristics; different concurrent threads have different thread IDs, distinguishing different concurrent requests on the same node at the same time. The node-specific random salt information is a unique salt value fixed during the node's initialization; each service node has an independent and unique salt value, distinguishing the entropy characteristics of different service nodes. The hardware-generated true random numbers are generated at the server hardware level, unlike software pseudo-random numbers, possessing the characteristics of being irregular and unreproducible. This ensures the true randomness of the perturbation factors at the hardware level, preventing the random sequence from being predicted or reproduced. During a single ID generation request, the cloud server device collects the currently valid thread ID, the local node's fixed random salt information, and hardware-generated true random numbers in real time. It then performs character concatenation and bit fusion on these three types of perturbation parameters to generate a relatively long initial entropy value with rich random dimensions. This initial entropy value integrates thread dynamic characteristics, node fixed characteristics, and hardware random characteristics, exhibiting extremely high levels of disorder and uniqueness. To avoid excessively long entropy values ​​leading to overflow of the total number of ID bits, increased storage consumption, and decreased database indexing performance, this embodiment of the disclosure also employs a bitmask truncation mechanism to lightweight the initial entropy value. In this way, by using a preset fixed-length bitmask to truncate and regularize the excessively long initial entropy value, redundant high-order bits are discarded, and low-order valid random bits are retained, ultimately generating a fixed-length, lightweight standard entropy value. The lightweight entropy value generated by this mechanism retains the high security and unpredictability brought about by multi-dimensional random perturbations, while strictly controlling the length of the entropy value, thus not disrupting the overall ID structure arrangement rules and short code compression effect. Simultaneously, the lightweight entropy value design ensures extremely low computational overhead for entropy value generation, concatenation, and truncation in ultra-high concurrency scenarios, without causing any loss to the system's number issuance performance. This achieves a security optimization effect of zero performance loss, high security enhancement, and a unified and standardized format, effectively solving the security defects of traditional distributed IDs, such as strong regularity, susceptibility to cracking, and easy leakage of business data.

[0056] Step 203: Compress and encode the current timestamp, current sequence number, node ID, and lightweight entropy value to obtain the client's current ID, and send it to the current client.

[0057] The client's current ID can be obtained based on the current timestamp, current sequence number, node ID, and lightweight entropy value. In some embodiments, obtaining the client's current ID includes: structurally combining the current timestamp, current sequence number, node ID, and lightweight entropy value to obtain an initial ID; and compressing the initial ID into a high-radix short code format for the current ID.

[0058] In this way, four independent core fields—calibrated monotonically increasing logical timestamp, lock-free auto-incrementing sequence number, globally unique node ID, and lightweight random entropy value—are sequentially combined according to a preset fixed bit order and structural rules to generate an initial ID with a unified format, regular structure, and complete information. Each field performs its own function and mutually constrains each other, jointly ensuring the global uniqueness and completeness of the ID from multiple dimensions: the logical timestamp is the core time sequence dimension, ensuring that the ID as a whole has temporal order and supports business time sequence tracing and link sorting; the sequence number is the concurrency differentiation dimension of a single node and a single time dimension, ensuring that the IDs of ultra-high concurrency requests on the same node and within the same logical time are not duplicated; the node ID is the cluster node differentiation dimension, completely isolating the ID generation range of different service nodes in the distributed cluster and eliminating cross-node ID collisions; the lightweight entropy value is the security perturbation dimension, breaking the fixed rules of structured IDs and achieving the security characteristics of unpredictable, anti-enumeration, and anti-deduction IDs. The four types of fields are structured and superimposed to build multiple uniqueness guarantees from the four dimensions of time sequence, concurrency, node, and security, eliminating the possibility of ID duplication and conflict from the algorithm level. Meanwhile, by adopting a fixed-structure assembly logic, all fields are arranged with fixed length and fixed order, eliminating the problem of random disorder splicing. This makes the initial ID structure regular, parsable, and traceable, retaining the advantages of the traditional Snowflake algorithm in terms of order and traceability, while making up for its defects of poor security and easy to cause conflicts.

[0059] The initial ID obtained through structured concatenation is an extremely long decimal string. While it offers excellent uniqueness and order, it suffers from problems such as excessive character length, large storage space consumption, high database index dispersion, and poor read / write performance, hindering large-scale business deployment. Therefore, this invention adds an independent encoder module to perform high-radix compression encoding on the structured initial ID, achieving lightweight ID optimization. Specifically, the cloud server supports two mainstream high-base compression formats: Base36 and Base62, which can be flexibly adapted to different business scenarios. Base36 uses a combination of lowercase letters 0-9 and az, with no special characters, offering strong compatibility and adaptability to all databases, caches, and business systems. Base62 uses a combination of uppercase and lowercase letters 0-9, az, and AZ, resulting in higher base density and better compression ratio, minimizing ID length. Compared to traditional decimal representation, Base36 / Base62 high-base encoding significantly increases the information capacity per character, performing overall compression, character mapping, and simplified output on extremely long structured initial IDs. This significantly shortens the final ID's character length without losing uniqueness, order, or traceability. The final current ID, after high-radix compression, has a shorter character length, a uniform format, and no special or illegal characters. This greatly reduces the storage overhead of database fields, reduces the length of index keys, and improves the hit rate and read / write efficiency of database B+ tree indexes. It completely solves the technical pain points of UUID disorder, index fragmentation, and redundant storage of traditional long numeric IDs. It is highly adaptable to high-frequency business scenarios such as database primary keys, unique indexes, sharding identifiers, and distributed transaction IDs. Ultimately, the cloud server device will send the standard unique ID generated through structured assembly and high-level compression encoding as the response result of this request to the current client that initiated the request in real time, completing the business logic of generating and sending a single distributed unique identifier.

[0060] As can be seen, this embodiment constructs a full-link distributed ID generation system, encompassing time-tolerance calibration, high-concurrency sequence number generation, fully automatic node negotiation, enhanced security entropy, and structured compression output. This embodiment abandons the reliance on traditional centralized number generation components, relying on logical clock layered compensation and a dual-interval sequence isolation mechanism to fundamentally solve the ID duplication conflict problem caused by server clock rollback and time jitter. Through batch pre-allocation of sequence numbers, CAS lock-free counting, and asynchronous persistence mechanisms, it overcomes the performance shortcomings of traditional ID algorithms, such as high-concurrency overflow, severe lock contention, and loss of service restart state. Relying on local multi-dimensional factor hashing, cluster conflict detection, and local metadata persistence mechanisms, it achieves fully automatic node ID generation and stable reuse without manual configuration, perfectly adapting to complex scenarios of cloud-native dynamic scaling and frequent cluster start-stop. Simultaneously, by combining multi-source random perturbation entropy injection and high-radix compression encoding optimization, it not only solves the defects of predictable patterns and low security in traditional structured IDs but also improves the problems of redundant storage of ultra-long numeric IDs and poor database indexing performance. In addition, this embodiment, through deep coupling of multiple modules and mechanisms, ensures the global uniqueness and temporal order of the distributed ID, while also taking into account the system's high availability, ultra-high concurrency throughput, extreme anomaly tolerance, business security, and database storage adaptability. It effectively solves the industry technical pain points of existing distributed ID technologies that cannot simultaneously achieve high performance, high stability, high adaptability, and high security, and has strong engineering feasibility and scenario universality.

[0061] The following describes the operation process in a specific embodiment, illustrating the process of generating a system unique identifier provided by the embodiments of the present invention.

[0062] In this embodiment, the cloud server device integrates multiple functional collaboration modules, mainly including: ID service, time engine, counter engine, node manager, entropy factor module, and ID assembly encoder. The cloud server device supports bidirectional network communication with each client, and can receive client ID generation requests in real time and provide feedback on the final generation result. Based on this modular distributed interactive architecture, Figure 3 This is a schematic diagram of the signaling interaction for the unique identifier generation method provided in this embodiment of the disclosure. (In conjunction with...) Figure 3 The interactive logic shown in the invention, specifically the complete unique identifier generation interaction process, includes the following steps: Step 301: The client's cloud server sends a unique identifier (ID) request.

[0063] As the terminal for business requests, the client proactively initiates a unique identifier generation request to the cloud server device when performing business logic that requires globally unique identification, such as business data creation, transaction marking, and tracing, thus triggering the business request. Correspondingly, the ID service inside the cloud server device receives and carries this ID request, serving as the unified scheduling entry point for the entire ID generation process.

[0064] Step 302: The ID service sends a timestamp request to the time engine.

[0065] After receiving an ID request from a client, the ID service first triggers the time-series calibration capability, sending a standardized timestamp retrieval request to the time engine to provide time-series reference parameters for subsequent ID generation.

[0066] Step 303: The time engine returns the current timestamp to the ID service.

[0067] The time engine, after processing through clock rollback detection, delay window verification, and logical clock compensation calibration, obtains the corresponding current timestamp and returns it to the ID service. The specific process is as described above and will not be repeated here.

[0068] Step 304: The ID service sends a serial number request to the counter engine.

[0069] While acquiring valid timing parameters or executing in parallel, the ID service sends a sequence number acquisition request to the counter engine to obtain the high-concurrency auto-incrementing sequence number under the current logical time dimension, distinguishing massive concurrent requests within the same timestamp.

[0070] Step 305: The timer engine returns the current serial number to the ID service.

[0071] The timer engine can rely on the batch pre-allocation of serial numbers, lock-free memory counting, and asynchronous persistence process. Combined with the dual serial number interval isolation strategy for normal and clock abnormal scenarios, it can dynamically allocate and adaptively supplement the serial number to generate a valid, non-repeating, and continuously incrementing current serial number in the current time dimension, and return it to the ID service. The specific serial number high concurrency generation and state persistence process is the same as described above, and will not be repeated here.

[0072] Step 306: The ID service sends a node ID request to the node manager.

[0073] To ensure the global uniqueness of IDs in multi-node cluster scenarios and avoid cross-node ID collisions, the ID service synchronously sends a request to the node manager to obtain the unique identifier of the node.

[0074] Step 307: The node manager returns the node ID of the current client to the ID service.

[0075] The node ID is automatically generated and maintained by the node manager inside the cloud server device. The core technology achieves the effects of no manual configuration, automatic node negotiation, stable restart identifier, and no cluster conflict. Therefore, the node manager relies on local multi-dimensional environmental factors, random salt encryption calculation and local metadata persistence mechanism to obtain the corresponding node ID of the current client and return the ID service.

[0076] Step 308: The ID service sends an entropy factor request to the entropy factor module.

[0077] To address the security vulnerabilities of traditional structured IDs, such as fixed rules, high predictability, and potential for business data leakage, the ID service initiates a lightweight entropy value retrieval request to the entropy factor module. This is used to add random perturbation features to the standard ID, thereby improving overall security.

[0078] Step 309: The entropy factor module returns the corresponding lightweight entropy value to the ID service.

[0079] The entropy factor module integrates three independent perturbation factors: thread ID, node-specific random salt information, and hardware true random numbers. These multi-source factors are coupled together, greatly increasing the difficulty of cracking the entropy value. The entropy factor module concatenates the thread ID, random salt information, and hardware random numbers to obtain the initial entropy value. The initial entropy value is then truncated using a bitmask to obtain a lightweight entropy value with a set number of bits, which can be returned to the ID service.

[0080] Step 310: The ID server sends the current timestamp, current sequence number, node ID, and lightweight entropy value to the ID assembly encoder.

[0081] After synchronously acquiring four core fields—current timestamp, current sequence number, node ID, and lightweight entropy value—the ID service pushes all structured parameters to the ID assembly encoder, entering the ID integration and encoding stage.

[0082] Step 311: The ID assembly encoder standardizes and integrates the four core fields and performs lightweight compression to generate a globally unique, time-ordered, highly secure, short-character standard current ID, which is then sent to the ID service.

[0083] Step 312: The ID service sends the current ID to the corresponding client.

[0084] After receiving the standard unique ID output by the ID assembly encoder, the ID service uses this ID as the final response result of this request and sends it to the client that initiated the request in real time, completing the entire process of modular scheduling, calculation, generation and distribution of a single distributed unique identifier. As can be seen, in this embodiment, the standardized, modular, and automated closed-loop process of unique identifier generation is achieved through the layered decoupling, collaborative scheduling, and signaling interaction of the multi-functional modules within the cloud server device. This architecture uses the ID service as a unified scheduling hub, linking the time engine, counter engine, node manager, and entropy factor module to independently complete specialized capabilities such as time-series fault tolerance, concurrent counting, node negotiation, and security enhancement. Finally, the ID assembly encoder uniformly completes structural integration and short code compression, with each component performing its own function, logically decoupled, and efficiently collaborating. This interaction process requires no manual intervention and has no reliance on centralized third-party components. It solves the problems of traditional distributed IDs being prone to duplication, conflict, high maintenance costs, and poor cluster adaptability through clock compensation, dual-range sequence isolation, and persistent node negotiation. Furthermore, it ensures ultra-high concurrency throughput performance through lock-free batch counting, improves ID unpredictability through multi-source entropy value perturbation, and optimizes storage index performance through high-radix compression. With clear overall interaction logic, strong fault tolerance, excellent concurrency performance, and high security level, it can fully adapt to various complex enterprise-level business scenarios such as cloud-native elastic scaling, large-scale cluster deployment, ultra-high concurrency transactions, and cross-regional distributed deployment, and has extremely high practical engineering implementation value and universal applicability.

[0085] Based on the process of generating unique identifiers described above, a device for generating unique identifiers can be constructed. Figure 4 This is a schematic diagram of the result of a unique identifier generation device provided in an embodiment of this disclosure, such as... Figure 4 As shown, the unique identifier generation device 400 includes: a first acquisition module 410, a first acquisition module 420, and an assembly coding module 430.

[0086] The first module 410 is configured to obtain the current timestamp and the current sequence number upon receiving a unique identifier ID request from the current client. The timestamp is obtained based on logical clock rollback compensation, and the sequence number is obtained through batch pre-allocation.

[0087] The second acquisition module 420 is configured to acquire the node ID of the current client and the corresponding lightweight entropy value, wherein the node ID is generated based on local multidimensional factors and the lightweight entropy value is obtained based on random perturbation.

[0088] Assembly encoding module 430 is configured to compress and encode the current timestamp, current sequence number, node ID, and lightweight entropy value to obtain the current ID of the client and send it to the current client.

[0089] In some embodiments, the first acquisition module 410 includes: The first acquisition unit is configured to acquire the current physical timestamp and the previous logical timestamp output last time; if the current physical timestamp is greater than or equal to the previous logical timestamp, the current physical timestamp is used to determine the current logical timestamp and the current logical timestamp is output as the current timestamp; if the current physical timestamp is less than the previous logical timestamp, a monotonically increasing current logical timestamp is generated based on a preset safety delay window mechanism combined with a logical clock advancement mechanism, and the current logical timestamp is output as the current timestamp.

[0090] In some embodiments, the first acquisition unit is specifically configured to determine the relative difference between the current physical timestamp and the previous logical timestamp as the clock rollback magnitude; if the clock rollback magnitude is less than or equal to a first threshold, the current logical timestamp is gradually increased in nanosecond steps at the end of the current millisecond of the previous logical timestamp until the increased current logical timestamp is greater than or equal to the previous logical timestamp, and the finally increased timestamp is determined as the current logical timestamp; if the clock rollback magnitude is greater than the first threshold, the sum of the previous logical timestamp and the millisecond step is used to determine the current logical timestamp.

[0091] In some embodiments, the first acquisition module 410 includes: The second acquisition unit is configured to, when no batch serial numbers matching the current timestamp are saved, allocate a set number of current batch serial numbers and extract the starting serial number from the current batch serial numbers to determine the current serial number; when batch serial numbers matching the current timestamp are saved, if there are serial numbers in the current batch serial numbers that have not been extracted, determine the first unextracted serial number as the current serial number; and if all current batch serial numbers have been extracted, reallocate a set number of current batch serial numbers and extract the starting serial number from the current batch serial numbers to determine the current serial number.

[0092] In some embodiments, the second acquisition module 420 includes: The third acquisition unit is configured to, if a pre-generated persistent metadata file exists, use the historical stable node ID stored in the persistent metadata file as the node ID of the current client, wherein the persistent metadata file is created and persistently stored after the current client's node ID is first generated; if no pre-generated persistent metadata file exists, acquire local multidimensional factors and obtain the first node ID based on the local multidimensional factors, wherein the local multidimensional factors include two or more of the following: local communication address information, random salt information, startup timestamp, and device information; if the first node ID passes conflict detection, determine the first node ID as the node ID of the current client; and if the first node ID fails conflict detection, generate new random salt information and obtain the first node ID, until the first node ID passes conflict detection.

[0093] In some embodiments, the second acquisition module 430 includes: The fourth acquisition unit is configured to concatenate the thread ID, random salt information, and hardware random number to obtain an initial entropy value; and to truncate the initial entropy value with a bitmask to obtain a lightweight entropy value with a set number of bits.

[0094] The specific structure and ID generation implementation process of the device for generating unique identifiers provided in this embodiment of the invention are illustrated below with reference to specific embodiments. Figure 5 This is a schematic diagram of a unique identifier generation apparatus provided in an embodiment of this disclosure. Figure 5 As shown in the embodiments of this disclosure, the unique identifier generation device 400 is specifically deployed inside a cloud server device, providing hardware logic and software functional support for the cloud server device to achieve fully automatic, highly reliable, and highly secure distributed ID generation capabilities. The unique identifier generation device 400 specifically includes: a first acquisition module 410, a second acquisition module 420, and an assembly coding module 430. The first acquisition module 410 includes a first acquisition unit 411 and a second acquisition unit 412, and the second acquisition module 420 includes a third acquisition unit 421 and a fourth acquisition unit 422. Each module and unit has clearly defined functional layers, logical decoupling, and collaborative cooperation to jointly complete the automated generation of globally unique identifiers. In conjunction with the preceding text Figure 1The system architecture shown corresponds one-to-one with the core engine in the cloud server device, ensuring complete functional compatibility. Specifically, the first acquisition unit 411 fully encompasses and implements all anti-rollback time calibration functions of the aforementioned time engine 110; the second acquisition unit 412 fully encompasses and implements the high-concurrency serial number generation function of the aforementioned counter engine 120; the third acquisition unit 421 fully encompasses and implements the automatic node negotiation and persistence functions of the aforementioned node manager 130; the fourth acquisition unit 422 fully encompasses and implements the security entropy value perturbation enhancement function of the aforementioned entropy factor module 140; and the assembly encoding module 430 is functionally equivalent to the aforementioned ID assembly encoder 150, responsible for implementing multi-field structured assembly and high-level compression encoding functions. This device adopts a modular integrated design, serving as a modular integrated carrier for the functions of the cloud server device. Without altering the core technical principles, it improves the device's encapsulation, portability, and adaptability through unit-based decomposition. Specifically, the first acquisition module 410 is the core module for timing and concurrency counting of the device. It is mainly used to respond to client ID requests, output a standard logical timestamp that is anti-callback and monotonically increasing, and an auto-incrementing serial number that is high-concurrency and overflow-free, providing a timing reference and concurrency differentiation parameters for ID generation. Among them, the first acquisition unit 411 is a timestamp calibration unit, which is specifically responsible for server clock monitoring, clock callback detection, and hierarchical logical time compensation; the second acquisition unit 412 is a serial number generation unit, which is specifically responsible for batch pre-allocation of serial numbers, lock-free concurrency counting, and asynchronous persistence of running status. During device operation, when the first acquisition module 410 receives the unique identifier ID request from the current client, it first calls the first acquisition unit 411 to execute the anti-rollback timestamp acquisition logic. Specifically, the first acquisition unit 411 collects the server's current physical timestamp in real time, and simultaneously reads the previous logical timestamp corresponding to the last successfully generated ID stored in the local persistent cache. It monitors clock anomalies through a real-time comparison mechanism of the two timestamps and adaptively outputs a monotonically increasing valid current logical timestamp. If the real-time collected current physical timestamp is greater than or equal to the previous logical timestamp, it is determined that the server clock is running normally, with no time rollback or time jitter anomalies. The first acquisition unit 411 directly calibrates the current physical timestamp to a valid current logical timestamp and outputs this timing parameter as the base timestamp for this ID generation, ensuring that the ID timing is consistent with physical time under normal business scenarios and possessing good timing traceability. If the real-time collected current physical timestamp is less than the previous logical timestamp, it accurately determines that the server has experienced clock rollback or system time reversal anomalies. The first acquisition unit 411 prohibits the use of abnormal physical time and immediately activates the layered fault tolerance compensation mechanism. First, the relative difference between the current physical timestamp and the previous logical timestamp is calculated. This difference is determined as the current clock rollback magnitude. Then, a preset first threshold (5ms for example) is used to distinguish between slight rollback and large rollback scenarios, thereby achieving differentiated fault tolerance compensation.

[0095] When the clock rollback amplitude is less than or equal to the first threshold, it is determined to be a minor time jitter or short-term small rollback scenario. In this case, the first acquisition unit 411 activates the security delay correction logic. At the end of the current millisecond period corresponding to the previous logical timestamp, it gradually increases the logical time with a fixed, fine step size at the nanosecond level, continuously and smoothly raising the timing parameters until the increased current logical timestamp is greater than or equal to the previous logical timestamp. Finally, the stable, compliant timestamp is determined as the current logical timestamp, thus avoiding ID timing errors caused by minor time jitter and preserving the time accuracy to the greatest extent. However, when the clock rollback amplitude exceeds the first threshold, it is determined to be a large clock rollback, and the delay will cause service congestion and stuttering. In this case, the first acquisition unit 411 immediately terminates the waiting logic and initiates a forced logical clock advancement mechanism. Using the previous logical timestamp as a base, it adds a fixed millisecond step size (1ms) to generate a new, monotonically increasing current logical timestamp, completely avoiding the timestamp regression problem caused by a large clock rollback, ensuring the timing parameters remain valid and the service is uninterrupted. While the first acquisition unit 411 completes the anti-rollback timestamp output, the second acquisition unit 412 simultaneously executes the sequence number generation logic. The second acquisition unit 412 relies on a batch number segment pre-allocation mechanism, a CAS lock-free memory counting mechanism, and a background asynchronous persistence mechanism, combined with a dual-range sequence number isolation strategy for normal and clock anomaly scenarios, to dynamically allocate valid sequence numbers under the current logical time dimension. By pre-allocating a fixed number of consecutive sequence numbers at a time and caching them in memory, coupled with lock-free spin-increment, ultra-high concurrency continuous number retrieval is achieved. Simultaneously, a background daemon thread periodically persists the maximum sequence number, number segment usage status, and logical time information to ensure that sequence numbers do not roll back or duplicate after service restarts or abnormal crashes. For example, in normal physical time scenarios, the basic sequence number range of 0~4095 is used; in logical clock compensation anomaly scenarios, it switches to the compensation sequence number range of 4096~8191, achieving dual-scenario physical isolation and completely eliminating sequence number reuse conflicts caused by clock anomalies. The second acquisition module 420 is a uniqueness hardening and security enhancement module for the device. It is mainly used to provide globally stable and unique node identifiers and highly random security disturbance factors, eliminating ID duplication and improving ID anti-prediction capabilities from the two dimensions of cluster isolation and security encryption. The third acquisition unit 421 is responsible for realizing fully automatic node negotiation and persistent reuse functions. By detecting local persistent metadata files, it realizes the reuse of historical node IDs during service restarts, and the automatic generation of unique node IDs for newly deployed nodes based on multi-dimensional software and hardware factors, random salt hash operations, and cluster conflict iteration detection. The entire process requires no manual configuration, adapts to cloud-native dynamic scaling and frequent cluster start-stop scenarios, and ensures that the distributed cluster node identifiers are globally unique and stable in the long term. The fourth acquisition unit 422 is responsible for generating and outputting lightweight entropy values. By real-time fusion of three independent perturbation factors—the current business thread ID, the node-specific fixed random salt, and the server hardware's true random number—it splices together an initial entropy value with high disorder. Then, it completes bit truncation and regularization through a preset bitmask, outputting a fixed-bit, lightweight, and performance-loss-free secure entropy value. This injects random perturbation features into the structured ID, breaking the traditional fixed arrangement pattern of IDs and effectively resisting security risks such as ID enumeration, deduction, and web crawling. The assembly coding module 430 is the final output module of the device. It receives the current logical timestamp and current sequence number output by the first acquisition module 410, and the stable node ID and lightweight entropy value output by the second acquisition module 420, completing the integrated output of multi-dimensional parameters. Specifically, the assembly coding module 430 first performs standardized and structured assembly of the four types of core parameters according to a preset fixed position order and fixed structure, generating a structurally regular, multi-unique, and time-traceable original ID; then, it performs lightweight compression coding of the ultra-long original ID using a Base36 or Base62 high-base compression algorithm, shortening the ID character length without losing uniqueness, orderliness, and traceability, generating a short-format standard unique ID adapted to database primary keys, index storage, and distributed business identifiers, and finally outputting it to the client. As can be seen, the unique identifier generation device provided in this embodiment, through modular and unit-based layered design, decouples and integrates the core capabilities of time-to-fault calibration, high-concurrency sequence number generation, automatic node negotiation, enhanced security entropy, and structured compression coding. Each unit performs its own function and collaborates in a coordinated manner, fully replicating the core technical logic of the distributed ID generation of this invention. This device does not rely on third-party centralized components and solves the technical defects of traditional distributed IDs, such as easy conflict, low availability, poor concurrency performance, strong predictability, and weak storage adaptability, from the hardware logic level. It has the comprehensive advantages of high availability, high concurrency, high fault tolerance, high security, and high adaptability, and can stably adapt to various large-scale, high-concurrency, and dynamic cloud-native distributed business scenarios, with extremely strong engineering feasibility and scenario versatility.

[0096] This disclosure provides an apparatus 600 for generating unique identifiers, the structure of which is as follows: Figure 6 As shown, it includes: The processor 1000 and memory 1001 may further include a communication interface 1002 and a bus 1003. The processor 1000, communication interface 1002, and memory 1001 can communicate with each other via the bus 1003. The communication interface 1002 can be used for information transmission. The processor 1000 can invoke logical instructions stored in the memory 1001 to execute the method for generating unique identifiers described in the above embodiments.

[0097] Furthermore, the logic instructions in the aforementioned memory 1001 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium.

[0098] The memory 1001, as a computer-readable storage medium, can be used to store software programs and computer-executable programs, such as program instructions / modules corresponding to the methods in the embodiments of this disclosure. The processor 1000 executes functional applications and data processing by running the program instructions / modules stored in the memory 1001, that is, it implements the method for generating unique identifiers in the above method embodiments.

[0099] The memory 1001 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the terminal device. Furthermore, the memory 1001 may include high-speed random access memory and may also include non-volatile memory.

[0100] This disclosure provides an apparatus for generating a unique identifier, including a processor and a memory storing program instructions, wherein the processor is configured to execute a method for generating a unique identifier when executing the program instructions.

[0101] This disclosure provides a cloud server device, such as... Figure 7 As shown, the device includes a device body 700, in which the aforementioned device 400 (600) for generating a unique identifier is installed. The installation relationship described herein is not limited to placement within the product, but also includes installation connections with other components of the product, including but not limited to physical connections, electrical connections, or signal transmission connections. Those skilled in the art will understand that the device 400 (600) for generating a unique identifier can be adapted to suitable corresponding device bodies 700 to achieve other feasible embodiments.

[0102] This disclosure provides a storage medium storing program instructions that, when executed, perform the method for generating a unique identifier as described above.

[0103] This disclosure provides a computer program product, which includes a computer program stored on a storage medium. The computer program includes program instructions that, when executed by a computer, cause the computer to perform the data retrieval method described above.

[0104] The aforementioned storage medium can be a transient computer-readable storage medium or a non-transitory computer-readable storage medium.

[0105] The technical solutions of this disclosure can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes one or more instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in this disclosure. The aforementioned storage medium can be a non-transitory storage medium, including: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code; it can also be a transient storage medium.

[0106] The foregoing description and accompanying drawings fully illustrate embodiments of the present disclosure to enable those skilled in the art to practice them. Other embodiments may include structural, logical, electrical, procedural, and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Parts and features of some embodiments may be included or replace parts and features of other embodiments. The scope of the embodiments of this disclosure includes the entire scope of the claims and all available equivalents of the claims. While the terms “first,” “second,” etc., may be used in this application to describe elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first element may be called a second element without changing the meaning of the description, and similarly, a second element may be called a first element, provided that all occurrences of “first element” are consistently renamed and all occurrences of “second element” are consistently renamed. First and second elements are both elements, but may not be the same element. Moreover, the terminology used in this application is only for describing embodiments and is not intended to limit the claims. As used in the description of the embodiments and claims, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” are intended to also include the plural forms. Similarly, the term “and / or” as used herein means including one or more of the associated listed any and all possible combinations. Additionally, when used herein, the terms “comprise” and its variations “comprises” and / or “comprising” refer to the presence of stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof. Without further limitations, an element defined by the phrase “comprising an…” does not exclude the presence of additional identical elements in the process, method, or apparatus that includes said element. In this document, each embodiment may focus on the differences from other embodiments, and similar or identical parts between embodiments can be referred to mutually. For methods, products, etc., disclosed in the embodiments, if they correspond to the method section disclosed in the embodiments, the relevant parts can be referred to the description of the method section.

[0107] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the embodiments of this disclosure. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0108] The methods and products disclosed in the embodiments herein (including but not limited to devices and equipment) can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units may be merely a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to implement this embodiment according to actual needs. In addition, the functional units in the embodiments of this disclosure may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0109] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than that shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. In the descriptions corresponding to the flowcharts and block diagrams in the accompanying drawings, the operations or steps corresponding to different blocks may also occur in a different order than disclosed in the description, and sometimes there is no specific order between different operations or steps. For example, two consecutive operations or steps may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. Each block in a block diagram and / or flowchart, and combinations of blocks in a block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

Claims

1. A method for unique identifier generation, characterized by, include: Upon receiving a unique identifier (ID) request from the current client, obtain the current timestamp and the current sequence number. The timestamp is obtained based on logical clock rollback compensation, and the sequence number is obtained through batch pre-allocation. Get the node ID and corresponding lightweight entropy value of the current client. The node ID is generated based on local multidimensional factors, and the lightweight entropy value is obtained based on random perturbation. The current timestamp, current sequence number, node ID, and lightweight entropy value are compressed and encoded to obtain the client's current ID, which is then sent to the current client.

2. The method for unique identifier generation of claim 1, wherein, The process of obtaining the current timestamp includes: Get the current physical timestamp and the previous logical timestamp of the last output; If the current physical timestamp is greater than or equal to the previous logical timestamp, determine the current logical timestamp from the current physical timestamp and output the current logical timestamp as the current timestamp; If the current physical timestamp is less than the previous logical timestamp, a monotonically increasing current logical timestamp is generated based on a preset safe delay window mechanism combined with a logical clock advancement mechanism, and the current logical timestamp is output as the current timestamp.

3. The method for unique identifier generation of claim 2, wherein, The method of generating a monotonically increasing current logical timestamp based on a preset security delay window mechanism combined with a logical clock advancement mechanism includes: The relative difference between the current physical timestamp and the previous logical timestamp is determined as the clock rollback magnitude; If the clock rollback magnitude is less than or equal to the first threshold, at the end of the current millisecond of the previous logical timestamp, the current logical timestamp is gradually increased in nanosecond increments until the increased current logical timestamp is greater than or equal to the previous logical timestamp, and the finally increased timestamp is determined as the current logical timestamp. If the clock rollback magnitude is greater than the first threshold, the sum of the previous logical timestamp and the millisecond step size is used to determine the current logical timestamp.

4. The method for unique identifier generation of claim 1, wherein, The step of obtaining the current serial number includes: If no batch serial number matching the current timestamp is saved, allocate a set number of current batch serial numbers, extract the starting serial number from the current batch serial numbers, and determine it as the current serial number; If a batch of serial numbers matching the current timestamp has been saved, and if there are unextracted serial numbers in the current batch, the first unextracted serial number will be determined as the current serial number. If all the current batch serial numbers have been extracted, a set number of current batch serial numbers will be reallocated, and the starting serial number in the current batch will be extracted and determined as the current serial number.

5. The method for unique identifier generation as claimed in claim 1 wherein, The process of obtaining the current client's node ID includes: If a pre-generated persistent metadata file exists, the historical stable node ID stored in the persistent metadata file is used as the node ID of the current client. The persistent metadata file is created and persistently stored after the node ID of the current client is generated for the first time. In the absence of a pre-generated persistent metadata file, obtain the local multidimensional factors and get the first node ID based on the local multidimensional factors. The local multidimensional factors include two or more of the following: local communication address information, random salt information, startup timestamp, and device information. If the first node ID passes the conflict detection, the first node ID is determined as the node ID of the current client. If the first node ID fails the conflict detection, new random salt information is generated and the first node ID is obtained, until the first node ID passes the conflict detection.

6. The method for generating unique identifiers according to claim 1, characterized in that, The process of obtaining the lightweight entropy value includes: The initial entropy value is obtained by concatenating the thread ID, random salt information, and hardware random number. The initial entropy value is truncated by a bitmask to obtain a lightweight entropy value with a set number of bits.

7. The method for generating unique identifiers according to any one of claims 1-6, characterized in that, The current ID of the client obtained includes: The current timestamp, current sequence number, node ID, and lightweight entropy value are combined in a structured manner to obtain the initial ID; Compress the initial ID into the current ID in a high-radix short code format.

8. An apparatus for generating a unique identifier, the apparatus comprising a processor and a memory storing program instructions, characterized in that, The processor is configured to perform the method for generating a unique identifier as described in any one of claims 1-7 when executing the program instructions.

9. A cloud server device, characterized in that, include: Equipment body; The apparatus for generating a unique identifier as described in claim 8 is installed on the device body.

10. A storage medium storing program instructions, characterized in that, When the program instructions are executed, they perform the method for generating a unique identifier as described in any one of claims 1-7.

Images