Unique number distribution method, program product, electronic equipment and storage medium

Abstract

The invention provides a unique number distribution method, a program product, electronic equipment and a storage medium. The method comprises the following steps: acquiring a service type identifier of a to-be-processed service; the service type identifier is used for distinguishing different service types; determining a service node corresponding to the to-be-processed service from a distributed node cluster according to the service type identifier, and sending the to-be-processed service to the corresponding service node; and receiving the unique number of the to-be-processed service distributed by the service node according to the service type. The service type identifiers are accurately routed to the corresponding service nodes, and complete isolation of cross-service types and strict orderliness of the same service type are simultaneously realized in a distributed environment. The isolation enables unique numbers of different service types to be distributed independently, and even if a certain service type encounters a flow flood peak or a node fault, normal number sending processes of other service types cannot be interfered. The problem of disorder possibly caused by the fact that the to-be-processed tasks are dispersed to different service nodes in a distributed scene is solved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to a unique numbering distribution method, program product, electronic device, and storage medium. Background Technology

[0002] In some business systems, it is often necessary to distribute unique numbers to large amounts of data or information to identify them. Current unique number generation schemes rely on third-party components such as Redis caching components to generate unique numbers for data or information via commands. However, this method can result in later-issued numbers being higher than earlier-issued numbers, failing to guarantee the order of unique numbers. Summary of the Invention

[0003] The purpose of this application is to provide a unique number distribution method, program product, electronic device, and storage medium to improve the above-mentioned problems and enhance the orderliness of unique numbers.

[0004] In a first aspect, embodiments of this application provide a unique number distribution method, comprising: obtaining a service type identifier for a service to be processed; the service type identifier is used to distinguish different service types; determining the corresponding service node for the service to be processed from a distributed node cluster based on the service type identifier, and sending the service to be processed to the corresponding service node; and receiving a unique number for the service to be processed distributed by the service node based on the service type.

[0005] In the above implementation process, requests from different business types enter the system carrying their respective business type identifiers. Precise routing based on these identifiers leads to the corresponding service nodes, achieving both complete isolation across business types and strict ordering within the same business type in a distributed environment. This isolation ensures that unique identifiers for different business types are distributed independently, preventing disruption to the normal identifier issuance process for other business types even if one business type experiences a traffic surge or node failure. This improves upon the potential out-of-order issues that can arise in distributed scenarios when tasks are distributed across different service nodes.

[0006] Optionally, in this embodiment of the application, determining the corresponding service node of the service to be processed from the distributed node cluster according to the service type identifier includes: calculating a hash value according to the service type identifier; mapping the hash value to a virtual hash ring, and determining the corresponding service node of the service to be processed based on the virtual hash ring; the virtual hash ring includes virtual nodes corresponding to multiple service nodes in the distributed node cluster.

[0007] In the above implementation process, requests with the same business type identifier are routed to the same service node through a hash algorithm because their hash values ​​are fixed. Combined with the ordered allocation mechanism of the same service node number range, a globally strictly increasing sequence is achieved. Virtual nodes are distributed and set up in a virtual hash ring to improve load balancing and reduce service node overload. Using the virtual hash ring as a bridge, business type identifiers are dynamically bound to service nodes, ensuring strict increasing sequence while achieving high availability and high performance through distributed fault tolerance and load balancing strategies.

[0008] Optionally, in this embodiment, mapping the hash value to a virtual hash ring and determining the corresponding service node for the service to be processed based on the virtual hash ring includes: mapping the hash value to the virtual hash ring to determine the initial node corresponding to the service to be processed; if the initial node is normal, using the initial node as the corresponding service node for the service to be processed; if the initial node is abnormal, removing the virtual node corresponding to the abnormal service node from the virtual hash ring to obtain an updated virtual hash ring; and re-determining the corresponding service node for the service to be processed based on the updated virtual hash ring.

[0009] In the above implementation process, under normal conditions, the initial node is used as the service node to maintain the routing stability of requests of the same business type, providing a foundation for strict incremental routing. In the event of a service node failure, a rerouting mechanism is initiated, and the virtual node corresponding to the failed node is removed, causing it to exit the routing candidate set. Consequently, its corresponding service node will not receive new requests, reducing service interruptions caused by service node failures. This achieves seamless route switching in fault scenarios, enhancing the system while maintaining strict incremental routing capabilities.

[0010] Optionally, in this embodiment of the application, receiving the unique number of the pending service distributed by the service node according to the service type includes: the service node obtaining the cached number segment corresponding to the service type from the database according to the service type, and caching the cached number segment; the database recording the current number segment sending value of each service type; the cached number segment being determined based on the current number segment sending value and the step size; the cached number segment including consecutive numbers for distribution; and receiving the unique number of the pending service determined and distributed by the service node from the cached number segment.

[0011] In the above implementation process, by preloading cached number segments into memory, the frequency of database access is greatly reduced. This transforms the allocation of high-frequency unique numbers into a pure memory operation, reducing network overhead, improving distribution efficiency, and lowering distribution latency. The database always records the current number segment sending value for each service type. Regardless of service node failure or number segment exhaustion, the latest cached number segment can be recovered from the database, ensuring that unique numbers for the same service type are not duplicated and are continuously increasing.

[0012] Optionally, in this embodiment of the application, determining and distributing the unique number of the pending service from the cached number segment includes: obtaining the sent number of the pending service; if the sent number is greater than the unique number to be sent in the cached number segment, deleting the cached number segment and obtaining the updated number segment of the service type again according to the sent number; and determining and distributing the unique number of the pending service from the updated number segment.

[0013] In the above implementation process, by verifying the logical relationship between the issued number and the cached number segment, the problem of dirty number segment caused by route jump (such as server scaling down, network jitter) is accurately identified, the cached number segment is refreshed and a unique number is distributed based on the updated number segment, thereby reducing the out-of-order problem caused by switching across service nodes.

[0014] Optionally, in this embodiment, obtaining the corresponding cached number segment according to the service type includes: obtaining the traffic characteristics of the service type identifier and the resource characteristics of the service node; the resource characteristics include at least one of memory usage, number segment utilization, or number segment application delay time; using a pre-trained number segment prediction model to predict the traffic characteristics and resource characteristics to obtain the traffic status; if the traffic status indicates an increase in traffic, then the corresponding cached number segment is obtained based on the expansion rule; if the traffic status indicates a decrease in traffic, then the corresponding cached number segment is obtained based on the shrinkage rule.

[0015] In the above implementation process, by dynamically sensing traffic and resource status, the system pre-expands the number segment capacity when traffic increases, such as automatically increasing the step size from 1000 to 5000 before a major promotion, avoiding throughput bottlenecks caused by repeated database accesses under high-frequency requests; and shrinks the step size when traffic decreases, such as reducing the step size from 1000 to 200 during off-peak hours at night, reducing node memory usage and improving resource utilization. It can also cope with sudden traffic surges, reducing the impact on distribution services due to number segment exhaustion.

[0016] Optionally, in this embodiment of the application, determining the corresponding service node of the service to be processed from the distributed node cluster based on the service type identifier includes: performing semantic parsing based on the service type identifier to obtain service features; matching the service features with multiple candidate nodes in the service node capability graph to obtain the corresponding service node of the service to be processed; the service node capability graph is obtained by modeling the attributes of candidate nodes in the distributed node cluster.

[0017] In the above implementation process, business requirements are transformed into structured features through semantic parsing and accurately matched to nodes with corresponding capabilities. This reduces performance waste caused by resource mismatch, makes reasonable use of the performance of each service node, and improves the processing efficiency of high-concurrency traffic. The capability graph incorporates node load indicators (such as memory utilization of 70%) in real time, automatically avoiding overloaded nodes in the matching calculation, and prioritizing the routing of new requests to lightly loaded nodes to prevent crashes caused by local hotspots.

[0018] Secondly, embodiments of this application also provide a unique number distribution device, including: a service type identification module, used to obtain a service type identification of a service to be processed; the service type identification is used to distinguish different service types; a service node determination module, used to determine the corresponding service node of the service to be processed from the distributed node cluster according to the service type identification, and send the service to be processed to the corresponding service node; and a unique number module, used to receive the unique number of the service to be processed distributed by the service node according to the service type.

[0019] Thirdly, embodiments of this application also provide a computer program product, including computer program instructions, which are executed by a processor to perform the method provided in the first aspect or any implementation thereof.

[0020] Fourthly, embodiments of this application also provide an electronic device, including: a processor and a memory, the memory storing computer program instructions, which are executed by the processor to perform the method provided in the first aspect or any implementation thereof.

[0021] Fifthly, embodiments of this application also provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, perform the method provided in the first aspect or any implementation thereof.

[0022] This application provides a unique numbering distribution method, program product, electronic device, and storage medium. Requests of different business types enter the system carrying their respective business type identifiers. Precise routing based on these identifiers leads to the corresponding service nodes, achieving both complete isolation across business types and strict ordering within the same business type in a distributed environment. This isolation ensures independent distribution of unique numbers for different business types, preventing disruption to the normal numbering process for other business types even if one business type experiences traffic surges or node failures. It also improves upon the potential out-of-order issues that can arise in distributed scenarios when tasks are distributed across different service nodes. Attached Figure Description

[0023] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 A flowchart illustrating a unique number distribution method provided in an embodiment of this application; Figure 2 A schematic diagram of the structure of the unique number distribution device provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit this application.

[0027] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0028] Please see Figure 1 The illustration shows a flowchart of a unique number distribution method provided in an embodiment of this application. The unique number distribution method provided in this application can be applied to electronic devices, which may include physical devices such as servers, PCs, tablets, or smartphones, or virtual devices such as virtual machines or containers. The electronic device can be a single device, a combination of multiple devices, or a cluster of a large number of devices. The unique number distribution method may include: Step S110: Obtain the business type identifier of the business to be processed; the business type identifier is used to distinguish different business types.

[0029] Step S120: Determine the corresponding service node for the service to be processed from the distributed node cluster based on the service type identifier, and send the service to be processed to the corresponding service node.

[0030] Step S130: Receive the unique number of the pending service distributed by the service node according to the service type.

[0031] In step S110, the pending business refers to the specific business operation instance that requires the generation of a unique number, such as: a user-submitted order creation request, a transaction record generation request initiated by the payment system, or a package tracking number generation request generated by the logistics system. The unique number can be a sequential unique ID or a unique code, etc.

[0032] The business type identifier, also known as a bizTag, is used to distinguish different business categories, thereby isolating the number distribution for different types of pending business. The business type identifier can be a string label. For example, "order" represents order business, "payment" represents payment business, and "logistics" represents logistics business. This identifier is predefined during system initialization to ensure that requests of the same business type use the same identifier, achieving business isolation.

[0033] When a business system needs to generate a unique ID (such as when creating a new order), it initiates a request through the client SDK integrated into the business system. The SDK extracts the business type identifier of the business to be processed from the request. The business type identifier can be predefined by business developers in the system configuration. For example, in an e-commerce system, when a user places an order, an order creation request is triggered. At this time, the business system will explicitly specify the business type identifier of the current request as "order"; when a user initiates a refund, the business system specifies the business type identifier as "refund". The business type identifier can be encapsulated in the parameter structure of the request within the SDK.

[0034] In step S120, the distributed node cluster is a server cluster composed of multiple physical or virtual machines, each physical or virtual machine being a service node. Each service node can provide a service for generating unique identifiers. The service nodes collaborate through a registry center (such as Zookeeper) to jointly provide the identifier generation capability.

[0035] Clients can send requests carrying a business type identifier (such as "order") to a distributed node cluster. As one implementation, the client SDK can send requests by calling the Dubbo framework's RPC interface. Dubbo has a built-in consistent hash load balancer that can use hash operations to map the business type identifier to the corresponding service node.

[0036] As another implementation method, other matching algorithms can be used to determine the correspondence between service type identifiers and service nodes. For example, the service node can be determined by matching the service characteristics of the service type identifier with the capabilities of the service node; or a preset lookup table can be used directly to determine the service node corresponding to the service type identifier.

[0037] It should be noted that regardless of which method is used to determine the correspondence between the business type identifier and the service node, all subsequent pending businesses carrying that business type identifier will be sent to that service node. The same service node will distribute multiple pending businesses of the same business type with unique numbers, which to a certain extent ensures the orderliness of the unique numbers of pending businesses of the same business type.

[0038] For example, pending transactions with a business type identifier of "order" are distributed with a unique number through service node A; pending transactions with a business type identifier of "refund" are distributed with a unique number through service node B.

[0039] In step S130, after receiving a request (e.g., node A receives an "order" request), the node first checks if a cache segment corresponding to the business type exists in the cache. The cache segment includes consecutive numbers used for distribution. If an undistributed cache segment exists, the next undistributed number in the cache segment is taken as the unique number of the business to be processed. If no undistributed cache segment exists, the node requests a cache segment corresponding to the business type from the database. After obtaining the cache segment, the next unassigned number in the cache segment is taken as the unique number of the business to be processed. The service node can encapsulate the generated unique number (e.g., 1002) into the response protocol and return the response to the client SDK through the original TCP connection.

[0040] Service nodes sequentially allocate unique IDs from the cache range using atomic operations (e.g., first allocate 1000, then allocate 1001), thus ensuring that the unique IDs distributed within a single service node are strictly incremental. Furthermore, cache ranges for different business types are isolated from each other, allowing requests of the same business type to exclusively occupy the current range, reducing concurrency conflicts.

[0041] In an optional embodiment, after receiving the unique number, the client records the routing relationship of the service node and optimizes the next request. That is, the next pending business with the same business type can directly request the unique number from the service node.

[0042] In the implementation of the above embodiments: requests of different business types enter the system carrying their respective business type identifiers, and are precisely routed to the corresponding service nodes through the precise routing of the business type identifiers. This achieves both complete isolation across business types and strict ordering within the same business type in a distributed environment. This isolation ensures that unique numbers for different business types are distributed independently, so even if a business type experiences a traffic surge or node failure, it will not interfere with the normal number issuance process for other business types. This improves the out-of-order problem that may occur when pending tasks are distributed to different service nodes in a distributed scenario.

[0043] Optionally, in this embodiment of the application, determining the corresponding service node for the service to be processed from the distributed node cluster based on the service type identifier includes: Calculate the hash value based on the business type identifier. For example, the client can calculate a fixed hash value based on the business type identifier (such as the string "order_service"), using hash algorithms such as MD5 or MurmurHash.

[0044] Hash values ​​are mapped to virtual hash rings, and the corresponding service nodes for the business to be processed are determined based on the virtual hash rings. The virtual hash rings include virtual nodes corresponding to multiple service nodes in the distributed node cluster. The virtual nodes represent the mapping positions of the service nodes on the virtual hash rings.

[0045] The system maintains a virtual hash ring, an enhanced consistent hashing structure used to implement dynamic load balancing and fault-tolerant routing in distributed systems. Physical service nodes are distributed across a fixed range of virtual hash rings via virtual node mapping (e.g., the range of the virtual hash ring can be 0 to 2^32-1). Each physical node corresponds to one or more virtual nodes. Each virtual node calculates its position on the ring using a hash function, and the virtual nodes are evenly (or unevenly) distributed across the virtual hash ring. For example, virtual node V1 is mapped to hash value H1, and V2 is mapped to hash value H2. Mapping the hash value of the business type identifier to a point on the ring allows searching clockwise on the virtual hash ring for the first virtual node with a hash value greater than the business type identifier; the service node corresponding to this virtual node is the service node for the task to be processed. For example, if the hash value of the business type identifier falls between virtual nodes V3 and V4, the physical node Server-B, to which V4 belongs, can be selected as the service node.

[0046] In the implementation of the above embodiments: requests with the same business type identifier are routed to the same service node through a hash algorithm because their hash values ​​are fixed. Combined with the ordered allocation mechanism of the same service node number segment, a globally strict incremental distribution is achieved. Virtual nodes are distributed and set up in a virtual hash ring to improve load balancing and reduce service node overload. Using the virtual hash ring as a bridge, business type identifiers are dynamically bound to service nodes, ensuring strict incrementality while achieving high availability and high performance through distributed fault tolerance and load balancing strategies.

[0047] In an optional embodiment, if one service node corresponds to one virtual node, then one service node can handle pending tasks of multiple business types. To achieve business isolation, the cache number segments corresponding to different business types of the service node can be isolated. The physical node maintains an independent number segment pool for each business type identifier locally to store the cache number segment corresponding to that business type identifier. When allocating IDs, the service node locates the dedicated number segment pool according to the business type identifier in the request, and allocates IDs sequentially in the pool using a thread-safe counter (such as AtomicLong), thereby achieving ID isolation for requests of different business types.

[0048] Optionally, in this embodiment, the hash value is mapped to a virtual hash ring, and the corresponding service node for the service to be processed is determined based on the virtual hash ring, including: The hash value is mapped to a virtual hash ring to determine the corresponding initial node for the business to be processed.

[0049] Virtual nodes are determined based on hash values, and the corresponding service nodes are used as the initial nodes. This is because if the node mapped by the hash is faulty, directly using it as the service node for the task to be processed might lead to service interruption due to the service node failure. To address this situation, after determining the initial node, its status needs to be checked, and a healthy node is selected as the service node.

[0050] Under normal circumstances, the initial node is used as the corresponding service node for the pending business. Normal circumstances mean the service node responds to requests normally; abnormal circumstances mean the service node cannot respond to requests, such as no response or returning an error. The status of the initial node can be monitored by receiving heartbeat broadcasts from the server cluster. If a service node does not send heartbeat data within a preset timeout threshold, it is determined to be in an abnormal state.

[0051] In the event of an initial node failure, the virtual node corresponding to the service node that failed is removed from the virtual hash ring to obtain an updated virtual hash ring; the service node corresponding to the pending business is then determined based on the updated virtual hash ring.

[0052] When the initial node is determined to be abnormal, the consistent hash ring management interface (such as a memory-based ring structure object) can be invoked. Based on the identifier of the abnormal service node (e.g., IP:Port1), its associated virtual nodes are retrieved. The virtual hash ring is locked, and the ring structure is traversed to remove these virtual nodes associated with the abnormal service node. For example, deleting the hash value marker corresponding to V3 on the virtual hash ring deletes the V3 hash ring. Furthermore, the ordered hash value mapping relationship of the nodes on the virtual hash ring is re-maintained (e.g., after removing virtual node V3, the hash value range originally pointing to V3 is merged into the adjacent virtual node V4).

[0053] The system notifies other clients in the distributed node cluster to update their local virtual hash rings via broadcast or a distributed configuration center, ensuring all clients use a consistent ring topology. After the removal operation is complete, subsequent requests recalculate the routing service nodes based on the updated virtual hash ring.

[0054] In an optional embodiment, the system can proactively detect service node failures by periodically receiving heartbeat broadcasts from the server cluster. Even if no tasks are assigned to a particular service node, the system can identify the faulty node and remove its corresponding virtual node. This self-check of service node status before tasks arrive improves the stability of task request allocation and reduces routing latency caused by service node failures.

[0055] In the implementation of the above embodiments: Under normal conditions, the initial node is used as the service node to maintain the routing stability of requests of the same business type, providing a foundation for strict incremental routing. In the event of a service node failure, a rerouting mechanism is initiated, and the virtual node corresponding to the failure node is removed, causing the virtual node to exit the routing candidate set. Consequently, its corresponding service node will not receive new requests, reducing service interruptions caused by service node failures. This achieves seamless route switching in fault scenarios, enhancing the system while maintaining strict incremental routing capabilities.

[0056] Optionally, in this embodiment of the application, the unique number of the pending service distributed by the receiving service node according to the service type includes: The service node retrieves the corresponding cached number segment from the database based on the service type and caches the cached number segment; the database records the current number segment sending value for each service type; the cached number segment is determined based on the current number segment sending value and the step size; the cached number segment includes consecutive numbers used for distribution.

[0057] After receiving the service type identifier, the service node can first check if there is a cache number segment corresponding to the service type in the cache. If there is, it means that a cache number segment has been requested from the database before, and the unique number of the pending service can be determined and distributed directly from the existing cache number segment.

[0058] After receiving the service type identifier, if the service node checks and finds that there is no undistributed cache number segment in the cache, it may be that it is receiving a request for the service type identifier for the first time, or that all the numbers in the cache number segment have been distributed. In either case, it needs to request the cache number segment corresponding to the service type from the database.

[0059] The database stores the current number segment sending value corresponding to the service type. The current number segment sending value refers to the current maximum allocated number (denoted as current_max_id). Based on the current number segment sending value and a preset step size (e.g., step=1000), the service node or the database can calculate the next consecutive number segment interval as a cached number segment. The interval is, for example, [current_max_id + 1, current_max_id + step]. Of course, this interval can also be [current_max_id + step, current_max_id + 2step]. The above intervals are merely examples, and this application does not limit them. It should be noted that the minimum value of the determined cached number segment should be greater than the current number segment sending value, thereby achieving unique number increment.

[0060] The database will return the cached number segment value to the service node corresponding to the identified service type, and update the current number segment sending value in the database to the maximum value in the cached number segment (e.g., 6001) through an atomic transaction. The next time the database allocates a cached number segment, it will calculate a new cached number segment based on the updated current number segment sending value.

[0061] After obtaining a cached ID range (e.g., [5001, 6001]), the service node stores it in the cache. Locally, it sequentially allocates IDs from within the cached range using a thread-safe counter (e.g., allocating 5001 initially, then 5002). Once all IDs in the cached range have been allocated, the range is exhausted, and the process repeats: it re-accesses the database to obtain the next ID range (e.g., [6002, 7002]) and updates the cache. When a client request arrives, the service node directly allocates a currently available ID from its local cache, without needing to access the database in real time. The client receives the unique ID for the pending business, determined and allocated by the service node from the cached range.

[0062] In the implementation of the above embodiments: by preloading cached number segments into memory, the frequency of database access is greatly reduced, transforming high-frequency unique number allocation into a pure memory operation, reducing network overhead, improving distribution efficiency, and reducing distribution latency. The database always records the current number segment sending value for each service type. Regardless of service node failure or number segment exhaustion, the latest cached number segment can be recovered from the database, ensuring that unique numbers for the same service type are not duplicated and are continuously increasing.

[0063] In an optional embodiment, if service node A obtains a cached number segment for the service type identifier "order" but encounters a failure during the unique number distribution process, the virtual node corresponding to service node A is removed from the virtual hash ring. During this period, no requests will be sent to service node A. All pending tasks with the service type identifier "order" are assigned to the normal service node B determined by the rerouting mechanism. Service node B may be receiving a request task with the service type identifier "order" for the first time. Therefore, service node B requests a new cached number segment from the database, accepts the task request with the service type identifier "order", and distributes unique numbers in sequence.

[0064] However, if service node B has already cached "expired number segments," or if after service node A recovers from its failure, task requests with the business type identifier "order" are reprocessed by service node A, then service node A also has previously acquired cached number segments, which can also be "expired number segments." To avoid distributing unique numbers from "expired number segments" and disrupting ID ordering, this application embodiment uses already issued numbers to verify cached number segments. This solution is described below: The unique number of the pending business determined and distributed from the cache number range includes: Retrieve the sent ID of the pending service. For example, the client can include the most recent sent ID (e.g., oldId=4503) of the service type identifier (bizTag) in the request parameters. After receiving the request, the service node can check the status of the cached ID range in its local cache based on the sent ID of the pending service.

[0065] If the issued ID is less than the starting value of the current cached ID segment (the starting value is the minimum value, such as the cached ID segment [5001, 6000], oldId=4503<5001), it indicates that the client's historical ID belongs to the old ID segment, while the cached ID segment in the service node is the new ID segment. Normally, a new unique ID (such as 5001) will be assigned from the current cached ID segment.

[0066] If the issued number is greater than the starting value of the current cached number segment (e.g., oldId=5500, while the cache starting value is 5001), it is determined that the client may have accessed other service nodes due to node switching, causing the current cached number segment to be outdated (referred to as an "expired number segment" or "dirty number segment"). The cached number segment needs to be deleted, and an updated number segment for the business type needs to be obtained again based on the issued number.

[0067] As another implementation method, if the issued number is greater than the starting value of the current cached number segment but less than the ending value of the cached number segment, some numbers in the cached number segment may have expired while others have not. You can choose to delete the cached number segment and re-acquire the updated number segment for the service type; alternatively, you can choose to distribute the numbers in the cached number segment that are greater than the issued number in sequence.

[0068] Of course, if the issued number is greater than the end value of the current cached number segment (e.g., oldId=6500, while the cache end value is 6001), it means that the client may have accessed other service nodes due to node switching, and all the unique numbers in the current cached number segment have expired. The cached number segment needs to be deleted, and the updated number segment of the business type needs to be obtained again based on the issued number.

[0069] After updating the cache number segment, a unique number is determined and distributed from the updated number segment for the pending business.

[0070] Expired cached number segments can be discarded or recycled. For example, if a periodic monitoring strategy detects that service node A has failed and can no longer provide distribution services, and the end value of the cached number segment with the service type identifier "order" of service node A is equal to the current number segment sending value recorded in the database, it means that after service node A obtains the cached number segment, no other service node obtains the cached number segment for the service type identifier "order". In this case, the undistributed numbers in the cached number segment of service node A can be recycled to the database, and the database updates the current number segment sending value for the service type identifier "order".

[0071] In the implementation of the above embodiments: by verifying the logical relationship between the issued number and the cached number segment, the problem of dirty number segment caused by route jump (such as server scaling down, network jitter) is accurately identified, the cached number segment is refreshed and a unique number is distributed based on the updated number segment, thereby reducing the out-of-order problem caused by switching across service nodes.

[0072] Optionally, in this embodiment of the application, obtaining the corresponding cache number range according to the service type includes: Obtain the traffic characteristics of the service type identifier and the resource characteristics of the service node; the resource characteristics include at least one of memory usage, number segment utilization, or number segment application delay time. The traffic characteristics of the service type identifier include the request rate of the service type identifier, historical traffic fluctuation patterns, and sudden request volume (such as a surge in the number of requests within 10 seconds), and may also include traffic patterns for different time periods, such as weekdays / holidays and traffic during the 0:00-24:00 period.

[0073] Memory Usage: The proportion of memory occupied by cached number segments identified by the business type on the current service node. Number Segment Utilization: The rate at which cached number segments are consumed per unit of time (e.g., a number segment with a capacity of 1000 is exhausted within 5 seconds). Number Segment Request Delay Time: The average time taken to retrieve a new number segment from the database.

[0074] The number segment prediction model can include an input layer, an LSTM layer, an attention layer, and an output layer. The input layer receives traffic and resource features within a time window, along with labels between feature pairs (traffic increase, traffic decrease, or traffic fluctuation, etc.). The LSTM layer captures long-term traffic dependencies, such as hourly traffic peaks. The attention layer automatically weights key features, such as identifying traffic spikes before promotions. The output layer predicts traffic conditions for future time windows (e.g., 1 hour).

[0075] These features are input into a pre-trained number segment prediction model (such as a time series prediction model LSTM or Prophet): the number segment prediction model is trained based on the relationship between historical traffic and resource characteristics (for example: if the number segment utilization rate is >80% and the application delay is >100ms when traffic increases in the past, then capacity expansion is required in the next cycle). Real-time prediction outputs traffic status labels, including traffic increase and traffic decrease.

[0076] If the traffic status indicates an increase in traffic, a scaling rule is triggered, and a number segment with an expanded step size is requested from the database (e.g., the original step size of 1000 is expanded to 5000). For example, the calculation logic is: new cache number segment = [current maximum ID + 1, current maximum ID + expanded step size], so that more cache number segments will be obtained each time.

[0077] If the traffic status is decreasing, the scaling down rule is triggered, and a number range with a reduced step size is requested (e.g., the original step size of 1000 is reduced to 500). The allocation logic is the same as above, but a smaller range is used.

[0078] In the implementation of the above embodiments: by dynamically sensing traffic and resource status, the capacity of the number segment is pre-expanded when traffic increases, such as automatically increasing the step size from 1000 to 5000 before a major promotion, avoiding throughput bottlenecks caused by repeated database access under high-frequency requests; the step size is contracted when traffic decreases, such as reducing the step size from 1000 to 200 during off-peak hours at night, reducing node memory usage and improving resource utilization. It can also cope with the impact of sudden traffic surges and reduce the impact on distribution services due to number segment exhaustion.

[0079] Optionally, in this embodiment of the application, determining the corresponding service node for the service to be processed from the distributed node cluster based on the service type identifier includes: Semantic parsing is performed based on business type identifiers to obtain business features. Natural language processing models (such as BERT) can parse the semantic meaning of business type identifiers and extract multi-dimensional business features, including business scenarios such as orders, payments, and inventory; traffic levels such as high concurrency (flash sales), medium concurrency (daily transactions), and low concurrency (back-end approval); and priorities such as real-time requirements (millisecond response) or tolerance for latency (second-level response). For example, the server receives a business type identifier (bizTag="order_cancel"), parses its semantic meaning using a natural language processing model, and obtains the business features: {Scenario: Order, Traffic Level: High, Sensitivity: Strong Consistency, Priority: Real-time}.

[0080] The service node corresponding to the business to be processed is obtained by matching the business characteristics with multiple candidate nodes in the service node capability graph; the service node capability graph is obtained by modeling the attributes of candidate nodes in the distributed node cluster.

[0081] Each service node in the cluster registers its own attributes with the distributed coordination service (such as ZooKeeper) when it starts up, forming a dynamically updated service node capability graph. The attributes include at least one of the following: number of CPU cores, memory capacity, network bandwidth, maximum supported QPS, average number segment allocation latency, transaction consistency strength (strong / weak consistency), current number of connections, and memory number segment cache utilization.

[0082] The similarity of business characteristics with the attributes of all nodes in the capability graph is calculated using a weighted average: for example, high-concurrency businesses are preferentially matched with high-QPS nodes (weight W1). Strongly consistent businesses are forcibly matched with nodes that support strong consistency (weight W2, with a veto power). Real-time businesses are preferentially selected from low-latency nodes (weight W3). Load balancing is used as a basic constraint (weight W4). The node with the highest overall score is selected as the corresponding service node for the business to be processed.

[0083] Once the corresponding service node for the business to be processed is determined, the matching relationship can be stored. Subsequently, the service node matching the same business type can be directly found based on the matching relationship list.

[0084] In the implementation of the above embodiments: business requirements are transformed into structured features through semantic parsing and accurately matched to nodes with corresponding capabilities, reducing performance waste caused by resource mismatch, making reasonable use of the performance of each service node, and improving the processing efficiency of high-concurrency traffic. The capability graph incorporates node load indicators (such as memory utilization of 70%) in real time, automatically avoiding overloaded nodes in the matching calculation, so that new requests are preferentially routed to lightly loaded nodes, preventing local hotspots from causing crashes.

[0085] In an optional embodiment, the server maintains a dynamic authentication center (such as integrating OAuth2.0). When a business system first accesses the system, it needs to submit a bizTag registration application through the operation and maintenance platform. After the application is approved, a unique key pair (such as RSA public and private keys) is issued. Each client request must carry a bizTag and generate a digital signature based on the key (such as encrypting the request parameters and timestamp using HMAC-SHA256). After receiving the request, the server performs three levels of verification: (1) Whitelist verification: query the list of legal bizTags preloaded into memory (such as Redis cache) and reject unregistered identifiers; (2) Signature decryption: use the public key bound to the bizTag to verify the timeliness and integrity of the signature and intercept forged or tampered requests; (3) Source IP binding: in high-security scenarios, verify whether the client IP is in the pre-authorized network segment.

[0086] Unregistered or maliciously forged business type identifiers are intercepted during the signature verification stage, reducing the consumption of ID resources by illegal business activities and preventing the paralysis of normal business operations due to the malicious depletion of number segment resources. Key pairs are automatically updated regularly, ensuring that even if keys are accidentally leaked, attackers cannot impersonate them for extended periods. Combined with IP binding, this forms a two-factor protection system, meeting financial-grade security compliance requirements.

[0087] The distributed node cluster identifies a predefined traffic quota profile for each service type using the `bizTag` (e.g., S-level high-priority services are allowed 100,000 QPS (queries per second), and A-level ordinary services are allowed 10,000 QPS). This traffic quota profile can be stored in a distributed configuration center. The traffic quota profile can include the following two aspects: (1) Global token bucket allocation: An independent token bucket is set up for each bizTag based on the quota, and the bucket capacity is equal to the quota value. When a request arrives, if there are no tokens in the bucket, an over-limit error is returned.

[0088] (2) Dynamic weight adjustment: Monitor the load of the distributed node cluster and automatically trigger the degradation strategy: compress the quota proportionally according to the business priority (e.g., limit the S-level business to 80,000 QPS, and compress the A-level business to 8,000 QPS).

[0089] Through the above solution, high-priority services (such as payment transactions) always maintain sufficient quotas during resource competition, preventing low-priority services (such as log reporting) from crowding out resources and causing transaction failures, thus reducing the failure rate of core services. When database pressure surges, the rate limiting system automatically compresses the quotas of each service according to their weights, ensuring that the total number of requests does not exceed the capacity threshold.

[0090] Please see Figure 2 The diagram shown is a structural schematic of a unique number distribution device provided in an embodiment of this application; this embodiment of the application provides a unique number distribution device 200, including: The business type identification module 210 is used to obtain the business type identification of the business to be processed; the business type identification is used to distinguish different business types. The service node determination module 220 is used to determine the corresponding service node of the business to be processed from the distributed node cluster according to the business type identifier, and send the business to be processed to the corresponding service node. The unique number module 230 is used to receive the unique number of the pending business distributed by the service node according to the business type.

[0091] Optionally, in this embodiment, the unique number distribution device 200 and the service node determination module 220 are used to calculate a hash value based on the service type identifier; map the hash value to a virtual hash ring; and determine the corresponding service node of the service to be processed based on the virtual hash ring; the virtual hash ring includes virtual nodes corresponding to multiple service nodes in a distributed node cluster; the virtual node represents the mapping position of the service node on the virtual hash ring.

[0092] Optionally, in this embodiment, the unique number distribution device 200 and the service node determination module 220 are used to map the hash value to a virtual hash ring to determine the initial node corresponding to the service to be processed; when the initial node is normal, the initial node is used as the service node corresponding to the service to be processed; when the initial node is abnormal, the virtual node corresponding to the abnormal service node is removed from the virtual hash ring to obtain an updated virtual hash ring; and the service node corresponding to the service to be processed is re-determined based on the updated virtual hash ring.

[0093] Optionally, in this embodiment, the unique number distribution device 200 and the unique number module 230 are used to obtain the cached number segment corresponding to the service type from the database according to the service type, and cache the cached number segment; the database records the current number segment sending value of each service type; the cached number segment is determined based on the current number segment sending value and the step size; the cached number segment includes a continuous number for distribution; and the unique number of the pending service determined and distributed by the service node from the cached number segment is received.

[0094] Optionally, in this embodiment of the application, the unique number distribution device 200 and the unique number module 230 are used to obtain the issued number of the service to be processed; if the issued number is greater than the unique number to be issued in the cached number segment, the cached number segment is deleted, and the updated number segment of the service type is obtained again according to the issued number; the unique number of the service to be processed is determined and distributed from the updated number segment.

[0095] Optionally, in this embodiment, the unique number distribution device 200 and the unique number module 230 are used to obtain the traffic characteristics of the service type identifier and the resource characteristics of the service node; the resource characteristics include at least one of memory usage, number segment utilization, or number segment application delay time; using a pre-trained number segment prediction model, the traffic characteristics and resource characteristics are predicted to obtain the traffic status; if the traffic status indicates an increase in traffic, the corresponding cached number segment is obtained based on the expansion rule; if the traffic status indicates a decrease in traffic, the corresponding cached number segment is obtained based on the shrinkage rule.

[0096] Optionally, in this embodiment, the unique number distribution device 200 and the service node determination module 220 are used to perform semantic parsing based on the business type identifier to obtain business features; match the business features with multiple candidate nodes in the service node capability graph to obtain the corresponding service node for the business to be processed; the service node capability graph is obtained by modeling the attributes of candidate nodes in a distributed node cluster.

[0097] It should be understood that this device corresponds to the aforementioned unique number distribution method embodiment and is capable of performing the various steps involved in the aforementioned method embodiment. The specific functions of this device can be found in the description above, and detailed descriptions are omitted here to avoid repetition. The device includes at least one software functional module that can be stored in memory or embedded in the device's operating system (OS) in the form of software or firmware.

[0098] Please see Figure 3 The diagram shows a structural schematic of an electronic device provided in an embodiment of this application. An electronic device 300 provided in this application includes a processor 310 and a memory 320. The memory 320 stores machine-readable instructions executable by the processor 310. When the machine-readable instructions are executed by the processor 310, the method described above is performed.

[0099] Figure 3 The components shown can be implemented using hardware, software, or a combination thereof. Electronic device 300 may be a physical device, such as a server or PC, or a virtual device, such as a virtual machine or virtualization container. Furthermore, electronic device 300 is not limited to a single device; it can be a combination of multiple devices or a cluster of numerous devices.

[0100] This application also provides a storage medium storing a computer program, which is executed by a processor to perform the above-described method.

[0101] The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0102] This application also provides a computer program product, including computer program instructions, which are executed by a processor to perform the method described above.

[0103] It should be understood that the disclosed apparatus and methods can also be implemented in other ways, given the several embodiments provided in this application. The apparatus embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, 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.

[0104] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0105] The above description is only an optional implementation of the embodiments of this application, but the protection scope of the embodiments of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the embodiments of this application should be covered within the protection scope of the embodiments of this application.

Claims

1. A method for distributing unique identification numbers, characterized in that, include: Obtain the service type identifier of the service to be processed; the service type identifier is used to distinguish different service types. Based on the service type identifier, the corresponding service node for the service to be processed is determined from the distributed node cluster, and the service to be processed is sent to the corresponding service node; Receive the unique number of the pending service distributed by the service node according to the service type.

2. The method according to claim 1, characterized in that, Determining the corresponding service node for the service to be processed from the distributed node cluster based on the service type identifier includes: Calculate the hash value based on the business type identifier; The hash value is mapped to a virtual hash ring, and the corresponding service node for the service to be processed is determined based on the virtual hash ring; the virtual hash ring includes virtual nodes corresponding to multiple service nodes in the distributed node cluster.

3. The method according to claim 2, characterized in that, Mapping the hash value to a virtual hash ring, and determining the corresponding service node for the service to be processed based on the virtual hash ring, includes: The hash value is mapped to a virtual hash ring to determine the initial node corresponding to the service to be processed; Under normal circumstances, the initial node is used as the corresponding service node for the service to be processed. In the event of an anomaly in the initial node, the virtual node corresponding to the abnormal service node is removed from the virtual hash ring to obtain an updated virtual hash ring; the service node corresponding to the pending service is then determined based on the updated virtual hash ring.

4. The method according to claim 1, characterized in that, Receiving the unique number of the pending service distributed by the service node according to the service type includes: The service node retrieves the cached number segment corresponding to the service type from the database according to the service type, and caches the cached number segment; the database records the current number segment sending value for each service type; the cached number segment is determined based on the current number segment sending value and a step size; the cached number segment includes a consecutive number for distribution; The service node receives the unique number of the pending service, which it determines and distributes from the cache number segment.

5. The method according to claim 4, characterized in that, The unique number of the pending service determined and distributed from the cache number range includes: Obtain the sent number of the pending service; If the issued number is greater than the pending unique number in the cached number segment, then the cached number segment is deleted, and the update number segment for the service type is re-obtained based on the issued number; The unique number of the pending service determined and distributed from the update number segment.

6. The method according to claim 4, characterized in that, Obtain the corresponding cache number range according to the service type, including: Obtain the traffic characteristics of the service type identifier and the resource characteristics of the service node; the resource characteristics include at least one of memory usage, number segment utilization, or number segment application delay time; Using a pre-trained number segment prediction model, the traffic characteristics and resource characteristics are predicted to obtain the traffic status; If the traffic status indicates an increase in traffic, then the corresponding cache number segment is obtained based on the expansion rules; If the traffic status indicates a decrease in traffic, then the corresponding cache number segment is obtained based on the scaling down rule.

7. The method according to claim 1, characterized in that, Determining the corresponding service node for the service to be processed from the distributed node cluster based on the service type identifier includes: Semantic parsing is performed based on the business type identifier to obtain business characteristics; The corresponding service node for the service to be processed is obtained by matching the business characteristics with multiple candidate nodes in the service node capability graph; the service node capability graph is obtained by modeling the attributes of the candidate nodes in the distributed node cluster.

8. A computer program product, characterized in that, It includes computer program instructions that, when executed by a processor, perform the method as described in any one of claims 1 to 7.

9. An electronic device, characterized in that, include: A processor and a memory, the memory storing computer program instructions that, when executed by the processor, perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, perform the method as described in any one of claims 1 to 7.

Images