Method and apparatus for allocating an identity

Abstract

The specification provides an identification allocation method and device, wherein the identification allocation method comprises: in response to a start request for a machine node, selecting an unallocated target identification in an identification database; establishing an association between the target identification and the machine node; recording the target identification in the identification database as in use based on the association; in the case where it is detected that the machine node meets an identification recovery condition, recording the target identification in the identification database as idle, and releasing machine node information associated with the target identification. Thus, the released target identification can be used by other machine nodes when other machine nodes start, the reuse of identifications in the identification database is achieved, and the situation of being unable to provide services due to the use-up of identifications is avoided.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to an identifier allocation method. This specification also relates to an identifier allocation device, a computing device, and a computer-readable storage medium. Background Technology

[0002] Machine nodes, as processes running on a server, can be started in various business scenarios to provide corresponding services. Starting a machine node typically requires acquiring an ID; only after successfully acquiring an ID can it provide services for the relevant business. In distributed ID generation scenarios, a set number of IDs usually needs to be generated to provide business services based on these IDs. In existing technologies, since the number of IDs that can be generated is limited, when a machine node starts, it first uses its IP address to check if an ID has already been assigned. If so, it reuses the already assigned ID; otherwise, it creates an auto-incrementing ID. If the number of IDs is exhausted, the machine node cannot start successfully, meaning it cannot provide services. Therefore, a new ID allocation method is urgently needed to solve the above problems. Summary of the Invention

[0003] In view of this, embodiments of this specification provide an identifier allocation method. This specification also relates to an identifier allocation apparatus, a computing device, and a computer-readable storage medium to address the technical deficiencies existing in the prior art.

[0004] According to a first aspect of the embodiments of this specification, an identifier allocation method is provided, comprising:

[0005] In response to a startup request for a machine node, select an unassigned target identifier from the identifier database;

[0006] Establish the association between the target identifier and the machine node;

[0007] Based on the aforementioned association, the target identifier in the identifier database is recorded as a usage status;

[0008] If the machine node is detected to meet the identifier reclamation conditions, the target identifier in the identifier database is recorded as idle, and the machine node information associated with the target identifier is released.

[0009] Optionally, before the step of selecting an unassigned target identifier in the identifier database in response to a startup request for a machine node is executed, it further includes:

[0010] At least one pair of identifier databases are created based on a preset storage space. Each pair of identifier databases includes a primary identifier database and a backup identifier database. Both the primary identifier database and the backup identifier database contain an identifier table, which records at least one identifier.

[0011] Accordingly, in response to a startup request for a machine node, an unassigned target identifier is selected from the identifier database, including:

[0012] In response to a startup request for the machine node, a local identity database is determined from at least one pair of identity databases, and an unassigned target identity is selected from the primary identity database of the local identity database.

[0013] Optionally, in response to a startup request for a machine node, determining a local identity database in at least one pair of identity databases and selecting an unassigned target identity in the primary identity database of the local identity database includes:

[0014] Receive a startup request for the machine node, and generate an identifier lookup instruction based on the startup request;

[0015] Determine the local identifier database corresponding to the identifier lookup instruction from the at least one pair of identifier databases, and select the primary identifier database from the local identifier database;

[0016] Search for at least one intermediate identifier in the identifier table contained in the main identifier database, wherein each intermediate identifier is in an idle state.

[0017] The target identifier is determined from the at least one intermediate identifier according to the identifier selection strategy.

[0018] Optionally, determining the target identifier from at least one intermediate identifier according to the identifier selection strategy includes:

[0019] Determine the intermediate historical timestamp information corresponding to each intermediate identifier in at least one intermediate identifier;

[0020] Based on the intermediate historical timestamp information corresponding to each intermediate identifier, select the intermediate identifier corresponding to the largest or smallest timestamp information as the target identifier.

[0021] Optionally, establishing the association between the target identifier and the machine node includes:

[0022] Based on the target identifier, the node information corresponding to the machine node is stored in the identifier database, and the storage result is used as the association relationship.

[0023] Optionally, before the step of searching for at least one intermediate identifier in the identifier table contained in the main identifier database is performed, the method further includes:

[0024] Determine whether an intermediate identifier exists in the main identifier database;

[0025] If so, perform the step of searching for at least one intermediate identifier in the identifier table contained in the main identifier database.

[0026] Optionally, if the result of determining whether an intermediate identifier exists in the main identifier database is negative, the following steps are performed:

[0027] Determine a backup identifier database from the local identifier database;

[0028] If the identifier table included in the backup identifier database contains an intermediate identifier, at least one intermediate identifier is searched in the identifier table included in the backup identifier database; or, if the identifier table included in the backup identifier database does not contain an intermediate identifier, an intermediate identifier is selected from the off-site identifier database in the at least one pair of identifier databases.

[0029] Optionally, after the step of recording the target identifier in the identifier database as a usage status is performed, the method further includes:

[0030] Receive the timestamp reporting information corresponding to the machine node;

[0031] Determine the target identifier table contained in the identifier database, and determine the target historical timestamp information corresponding to the target identifier in the target identifier table;

[0032] Update the target historical timestamp information corresponding to the target identifier in the target identifier table to the timestamp reporting information.

[0033] Optionally, the step of recording the target identifier in the identifier database as idle when the machine node is detected to meet the identifier reclamation conditions includes:

[0034] Upon receiving a shutdown request for the machine node, it is determined that the machine node meets the identifier reclamation conditions, and the step of recording the target identifier in the identifier database as idle is executed; or,

[0035] If no timestamp information is received within a preset time period, the machine node is determined to meet the identifier reclamation condition, and the step of recording the target identifier in the identifier database as idle is executed; or,

[0036] If the timestamp corresponding to the server and the timestamp corresponding to the machine node are found to be inconsistent, it is determined that the machine node meets the tag reclamation conditions, and the step of recording the target tag in the tag database as an idle state is executed.

[0037] Optionally, after the step of recording the target identifier in the identifier database as a usage status is performed, the method further includes:

[0038] If no timestamp record information is received within a preset time period, it is determined whether the machine node is in a running state;

[0039] When the machine node is in the running state, an unassigned recovery identifier is selected from the identifier database, an association is established between the recovery identifier and the machine node, and based on the association, the recovery identifier in the identifier database is recorded as being in use.

[0040] Optionally, after the steps of recording the target identifier in the identifier database as idle and releasing the machine node information associated with the target identifier are executed, the method further includes:

[0041] Generate a cancellation timestamp for the target identifier and store it in the identifier database in the identifier record corresponding to the target identifier.

[0042] According to a second aspect of the embodiments of this specification, an identifier allocation device is provided, comprising:

[0043] The selection module is configured to select an unassigned target identifier from the identifier database in response to a startup request for a machine node.

[0044] The module is configured to establish an association between the target identifier and the machine node;

[0045] The recording module is configured to record the target identifier in the identifier database as a usage status based on the association relationship;

[0046] The release module is configured to, when the machine node is detected to meet the identifier reclamation conditions, record the target identifier in the identifier database as idle and release the machine node information associated with the target identifier.

[0047] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising:

[0048] Memory and processor;

[0049] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions:

[0050] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions that, when executed by a processor, implement the steps of the identifier allocation method.

[0051] The identifier allocation method provided in this specification, in response to a startup request for a machine node, selects an unassigned target identifier from the identifier database; establishes an association between the target identifier and the machine node; based on the association, records the target identifier in the identifier database as being in use; and when it is detected that a machine node meets the identifier reclamation conditions, records the target identifier in the identifier database as being in an idle state and releases the machine node information associated with the target identifier. This allows the released target identifier to be used by other machine nodes when they start up, realizing the reuse of identifiers in the identifier database and thus avoiding the situation where service cannot be provided due to the exhaustion of identifiers. Attached Figure Description

[0052] Figure 1 This is a flowchart of an embodiment of an identifier allocation method provided in this specification;

[0053] Figure 2 This is a flowchart illustrating an identifier allocation method for machine node identifier allocation provided in one embodiment of this specification.

[0054] Figure 3 This is a schematic diagram of the structure of an identification distribution device provided in one embodiment of this specification;

[0055] Figure 4 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0056] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0057] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0058] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0059] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0060] The SnowFlake algorithm is an open-source distributed ID generation algorithm widely used in distributed systems. Its core idea is to use a 64-bit long integer as a globally unique ID.

[0061] In existing technologies, the Snowflake algorithm is typically used to generate distributed, unique worker IDs, i.e., identifiers. The length of these worker IDs is fixed, ranging from 0 to 1023. If worker IDs are continuously consumed until all 1024 worker IDs are exhausted, service will become unavailable. Therefore, this specification provides an identifier allocation method to solve the aforementioned problem.

[0062] In this specification, upon receiving a startup request for a machine node, in response to the request, an unassigned target identifier is selected from the identifier database. The target identifier is assigned to the machine node, and an association is established between the target identifier and the machine node. Based on this association, the target identifier in the identifier database is recorded as being in use. If a machine node is detected to meet the identifier reclamation conditions, the target identifier in the identifier database is recorded as being in an idle state. Upon receiving a startup request from another machine node, that machine node can then use the target identifier in the idle state. This achieves identifier reuse, determines whether an identifier can be assigned to a machine node by checking its status, and avoids the situation where the same identifier is used by multiple machine nodes simultaneously.

[0063] This specification provides an identifier allocation method, and also relates to an identifier allocation device, a computing device, and a computer-readable storage medium, which will be described in detail in the following embodiments.

[0064] Figure 1 A flowchart of an identifier allocation method according to an embodiment of this specification is shown, which specifically includes the following steps:

[0065] In step S102, in response to the startup request for the machine node, an unassigned target identifier is selected from the identifier database.

[0066] Specifically, a machine node refers to a process running on a server. Applications can be deployed on machine nodes, and the machine nodes provide services to the applications. The identifier database is a pre-created database used to store information corresponding to the identifiers used by the machine nodes when they start up, as well as the machine node's IP address, port number, etc. Correspondingly, the target identifier refers to the identifier selected in the identifier database, which is used to assign to the machine node so that the machine node can start up successfully.

[0067] Based on this, when a machine node starts up, it sends a startup request to the server to obtain an identifier that supports the startup of the machine node. When the server receives the startup request for the machine node, it sends a search instruction to the identifier database to determine the identifiers that have not been assigned in the identifier database, that is, the identifiers that are in an idle state. An identifier is selected from the identifiers in the idle state as the target identifier, which is the identifier required for the machine node to start.

[0068] For example, in a scenario where an application is running and providing services to users, users can place orders for goods through the application. However, the server provides the corresponding service during the order number generation process. A machine node can be a process running on the server, and the application relies on machine nodes to provide services to users. A machine node can only provide services after it has started. Therefore, when a machine node needs to start, it sends a start request to the server, selects an unassigned target identifier from the server's stored identifier database, and assigns it to the machine node. The machine node uses this target identifier during its operation. It should be noted that this embodiment does not impose any limitations on the method of starting the machine node.

[0069] Furthermore, before starting the machine node, an identifier database needs to be created. To ensure service stability, a primary identifier database and a backup identifier database can be created separately, as detailed below:

[0070] At least one pair of identifier databases are created based on a preset storage space, wherein each pair of identifier databases includes a primary identifier database and a backup identifier database, and both the primary identifier database and the backup identifier database contain an identifier table, wherein the identifier table records at least one identifier; accordingly, in response to a startup request for a machine node, an unassigned target identifier is selected in the identifier database, including: in response to a startup request for the machine node, determining a local identifier database in the at least one pair of identifier databases, and selecting an unassigned target identifier in the primary identifier database of the local identifier database.

[0071] Specifically, the primary identifier database is the identifier database that is searched first when an identifier is selected from the identifier databases at the start of a machine node. Correspondingly, if there is no target identifier available for use by the machine node in the primary identifier database, the target identifier is selected from the backup identifier database. When creating at least one pair of identifier databases, a local identifier database is created locally. The local identifier database contains a primary identifier database and a backup identifier database. Then, an identifier table is created in both the primary identifier database and the backup identifier database. The identifier table is used to record the information corresponding to the identifiers that can be used by the machine node.

[0072] Based on this, before a machine node starts, at least one pair of identifier databases is created based on a preset storage space. A primary identifier database and a backup identifier database form one pair. Then, in each pair of identifier databases, a separate identifier table is created based on a preset identifier range in both the primary and backup identifier databases. Each identifier table records at least one identifier, along with its corresponding sequence number and status. The status includes usage status and idle status. When an identifier is not used by a machine node, its corresponding status is idle; when an identifier is being used by a machine node, its corresponding status is usage. Correspondingly, in response to a startup request for a machine node, an unassigned target identifier is selected from the identifier databases. This includes: in response to a startup request for a machine node, determining a local identifier database from the at least one pair of identifier databases, and selecting a target identifier in an idle state from the primary identifier database within the local identifier database.

[0073] Continuing the previous example, before a machine node starts, at least one pair of identifier databases is created based on local storage space or the storage space corresponding to the cloud server. Each pair of identifier databases includes a primary identifier database and a backup identifier database. A pair of local identifier databases is created in region A (primary identifier database A and backup identifier database A), a pair of identifier databases is created in region B (primary identifier database B and backup identifier database B), and identifier databases are created in regions C, D, etc., where regions A, B, C, and D are different geographic spaces. Correspondingly, when selecting a target identifier from the identifier databases, priority is given to selecting unassigned target identifiers from the primary identifier database A corresponding to region A where machine node A is located. The number of available identifiers in the primary and backup identifier databases can be determined according to actual needs. Both the primary and backup identifier databases contain an identifier table, which provides a continuous range of selectable identifiers, i.e., worker IDs. In addition, the identifier table also records the IDs of the selectable identifiers, the region where the identifier table is located, and the identifier status (idle status, usage status), etc.

[0074] In summary, by creating at least one pair of identifier databases, each pair including a primary identifier database and a backup identifier database, and creating an identifier table in both the primary and backup identifier databases, the target identifier can be obtained from either the primary or backup identifier database when a machine node starts up. This ensures that if one identifier database is unable to provide service, the other identifier database can still provide service, thus improving service stability.

[0075] Furthermore, when selecting a target identifier for a machine node, considering that there may be multiple intermediate identifiers in the identifier database that can be selected as the target identifier, the intermediate identifiers that can be used as the target identifier can be filtered out first, and then the target identifier can be selected from the intermediate identifiers. The specific implementation is as follows:

[0076] Receive a startup request for the machine node and generate an identifier lookup instruction based on the startup request; determine the local identifier database corresponding to the identifier lookup instruction in the at least one pair of identifier databases, and select a primary identifier database in the local identifier database; search for at least one intermediate identifier in the identifier table contained in the primary identifier database, wherein the usage status of each intermediate identifier is idle; determine the target identifier from the at least one intermediate identifier according to the identifier selection strategy.

[0077] Specifically, an identifier lookup command refers to a computer command used to search for identifiers that meet the search criteria in an identifier database. When the identifier database is a database such as MySQL, the identifier lookup command can be a database command. Correspondingly, an intermediate identifier refers to an identifier obtained by searching the identifier database based on the identifier lookup command. The intermediate identifiers are all in an idle state, which means that the intermediate identifiers are not used by any machine node. The identifier selection strategy refers to the method of selecting the target identifier from the intermediate identifiers.

[0078] Based on this, when the server receives a startup request for a machine node, it generates an identifier lookup instruction based on the startup request. This instruction carries identifier database information, which identifies the identifier database to which the lookup instruction will be executed. The local identifier database corresponding to the identifier lookup instruction is determined from at least one pair of created identifier databases, and then a primary identifier database is selected from the local identifier database. At least one intermediate identifier in an idle state is searched in the identifier table contained in the primary identifier database. A target identifier is then determined from the identified at least one intermediate identifier according to the identifier selection strategy.

[0079] Continuing with the previous example, when machine node A starts up, it searches for idle identifiers (i.e., intermediate identifiers) in the main identifier database A corresponding to region A. The main identifier database A includes an identifier table A, which provides 100 selectable identifiers from 0 to 99. When selecting a target identifier from these 100 selectable identifiers, since identifier table A records the status of each identifier, identifiers in an idle state are considered selectable identifiers. Therefore, the intermediate identifiers 0-5 in an idle state are identified, and then one identifier is selected from these identified idle identifiers as the target identifier.

[0080] In summary, by first determining at least one intermediate identifier and then determining the target identifier from among at least one intermediate identifier, the selection range of the target identifier is narrowed, thereby improving the accuracy of the target identifier determination.

[0081] Furthermore, when determining the target identifier from at least one intermediate identifier according to the identifier selection strategy, the identifier selection strategy can be determined according to actual needs, as specifically implemented as follows:

[0082] Determine the intermediate historical timestamp information corresponding to each intermediate identifier in at least one intermediate identifier; based on the intermediate historical timestamp information corresponding to each intermediate identifier, select the intermediate identifier corresponding to the maximum or minimum timestamp information as the target identifier.

[0083] Specifically, intermediate historical timestamp information refers to the timestamp information corresponding to the intermediate identifier in the identifier table. That is, the machine node will periodically report the timestamp information when using the identifier in the identifier table, and each reported timestamp information will replace the previous reported timestamp information. Therefore, intermediate historical timestamp information refers to the timestamp information corresponding to the intermediate identifier in the identifier table. Correspondingly, the maximum timestamp information refers to the timestamp information that is the longest time since the machine node's start request was received, and the minimum timestamp information refers to the timestamp information that is the shortest time since the machine node's start request was received.

[0084] Based on this, when determining the target identifier from at least one intermediate identifier according to the identifier selection strategy, the intermediate historical timestamp information corresponding to each intermediate identifier in the at least one intermediate identifier is determined, the maximum timestamp information is determined from the intermediate historical timestamp information corresponding to each intermediate identifier, and the intermediate identifier corresponding to the maximum timestamp information is used as the target identifier; or, the minimum timestamp information is determined from the intermediate historical timestamp information corresponding to each intermediate identifier, and the intermediate identifier corresponding to the minimum timestamp information is used as the target identifier; or, after determining at least one intermediate identifier, an intermediate identifier is randomly selected from the at least one intermediate identifier as the target identifier.

[0085] Following the previous example, after identifying the idle intermediate identifiers 0-5, the target identifier can be selected from these idle identifiers. The timestamp information of each intermediate identifier, i.e., the intermediate historical timestamp information, is read from identifier table A. Since the timestamp information corresponding to each intermediate identifier is different, it can be sorted according to time to determine the maximum or minimum timestamp information. The timestamp information corresponding to intermediate identifiers 0-4 are: 0: 2022-06-20 14:43:14.617, 1: 2022-06-16 12:21:58.054, 2: 2022-05-26 18:21:52.258, 3: 2022-05-23 17:14:40.664, and 4: 2022-06-21 21:06:58.052. Therefore, the maximum timestamp is determined to be 4: 2022-06-21 21:06:58.052, and the minimum timestamp is determined to be 3: 2022-05-23 17:14:40.664. Either the maximum timestamp (4) or the minimum timestamp (3) can be selected as the target identifier. Alternatively, any intermediate timestamp between 0 and 4 can be randomly selected as the target identifier. It should be noted that both the maximum and minimum timestamps must be less than the current timestamp of machine node A. That is, when selecting a target identifier, the timestamp of the target identifier must be less than the current timestamp of the machine node.

[0086] In summary, determining the target identifier from at least one intermediate identifier through multiple selection methods improves the flexibility of target identifier selection.

[0087] Furthermore, before searching for at least one intermediate identifier in the identifier table contained in the main identifier database, considering that the identifier table in the main identifier database may or may not contain an intermediate identifier, it is necessary to first determine whether an intermediate identifier exists in the main identifier database. The specific implementation is as follows:

[0088] Determine whether an intermediate identifier exists in the main identifier database; if so, perform the step of searching for at least one intermediate identifier in the identifier table contained in the main identifier database.

[0089] Based on this, before searching for at least one intermediate identifier in the identifier table contained in the main identifier database, it is determined whether an intermediate identifier exists in the main identifier database. If an intermediate identifier exists, at least one intermediate identifier is searched in the identifier table contained in the main identifier database so that the target identifier can be selected from at least one intermediate identifier in the subsequent process.

[0090] In summary, before searching for at least one intermediate identifier in the identifier table contained in the main identifier database, it is first determined whether an intermediate identifier exists in the main identifier database. This avoids the situation where the target identifier cannot be determined if the intermediate identifier does not exist in the main identifier database, thus increasing the success rate of determining the target identifier.

[0091] Furthermore, since the local identifier database includes a primary identifier database and a backup identifier database, when selecting a target identifier for a machine node, it can be selected from either the primary identifier database or the backup identifier database. If the intermediate identifier does not exist in the primary identifier database, it is selected from the backup identifier database. The specific implementation is as follows:

[0092] If the result of determining whether an intermediate identifier exists in the primary identifier database is negative, the following steps are performed: determine a backup identifier database in the local identifier database; if the identifier table contained in the backup identifier database contains an intermediate identifier, search for at least one intermediate identifier in the identifier table contained in the backup identifier database; or, if the identifier table contained in the backup identifier database does not contain an intermediate identifier, select an intermediate identifier from the remote identifier database in the at least one pair of identifier databases.

[0093] Specifically, the off-site identifier database is the identifier database corresponding to the local identifier database. For machine node A in region A, when machine node A starts up, it will select a target identifier from the identifier database in region A. At this time, an identifier database also exists in region B, and the identifier database in region B also contains identifiers that can be used by any machine node. In this scenario, the identifier database in region A is the local identifier database relative to machine node A, and the identifier database in region B is the off-site identifier database relative to machine node A.

[0094] Based on this, if the determination that an intermediate identifier exists in the primary identifier database is negative, a backup identifier database is determined in the local identifier database. If the backup identifier database contains an intermediate identifier, at least one intermediate identifier is searched in the identifier tables contained in the backup identifier database; or, if the backup identifier database does not contain an intermediate identifier, an intermediate identifier is selected from the remote identifier databases of at least one pair of identifier databases. That is, a primary identifier database corresponding to the remote identifier database is determined from the remote identifier databases of at least one pair of identifier databases, and an intermediate identifier is selected from the primary identifier database corresponding to the remote identifier database. If no intermediate identifier exists in the primary identifier database corresponding to the remote identifier database, an intermediate identifier is selected from the backup identifier database corresponding to the remote identifier database.

[0095] Continuing with the previous example, after determining the local identifier database corresponding to machine node A, before searching for an idle intermediate identifier in the primary identifier database A, it first checks whether an idle identifier (i.e., an intermediate identifier) ​​exists in the primary identifier database A. If so, it searches for the intermediate identifier in identifier table A contained in the primary identifier database A. If not, it checks whether an intermediate identifier is contained in identifier table a contained in the backup identifier database A. If so, it searches for the intermediate identifier in identifier table a contained in the backup identifier database A. If not, it selects one identifier database from the identifier databases corresponding to region B, region C, and region D, and chooses the identifiers contained in that database as the target identifier. It should be noted that when selecting an identifier database, the identifier database corresponding to the region closest to region A can be selected based on the actual distance between region A and other regions.

[0096] In summary, if no intermediate identifier is found in the local identifier database, an intermediate identifier can be selected from the remote identifier database, and then the target identifier can be selected from the intermediate identifier, which increases the probability of successfully identifying the target identifier.

[0097] Step S104: Establish the association between the target identifier and the machine node.

[0098] Specifically, in this embodiment, the association refers to the relationship between the target identifier and the machine node, which indicates that when the machine node starts up, the target identifier is assigned to the machine node for use.

[0099] Based on this, after determining the target identifier required for machine node startup, an association relationship is established between the target identifier and the machine node to indicate that the target identifier is occupied when the machine node starts up. That is, the target identifier is assigned to the machine node and will be occupied during the operation of the machine node.

[0100] Furthermore, after selecting a target identifier in the identifier database, in order to prevent the target identifier from being used by other machine nodes, the record corresponding to the target identifier in the identifier database needs to be updated. That is, the node information corresponding to the machine node is stored in the identifier database. The specific implementation is as follows:

[0101] Based on the target identifier, the node information corresponding to the machine node is stored in the identifier database, and the storage result is used as the association relationship.

[0102] Specifically, node information refers to the information corresponding to a machine node, including but not limited to the IP address and port number of the machine node; storage result refers to the storage result obtained by storing the node information corresponding to the machine node in the identifier database.

[0103] Based on this, after determining the target identifier required for machine node startup, the node information corresponding to the machine node is stored in the identifier database. That is, the identifier table in the identifier database is determined, the record corresponding to the target identifier is determined in the identifier table, the node information is stored in the record corresponding to the target identifier, and the storage result is obtained. The storage result is the association between the machine node and the target identifier.

[0104] Following the previous example, after determining the target identifier 3 of machine node A in the identifier table A of the main identifier database A, the node information corresponding to machine node A, such as IP address, port number, association creation time, and timestamp reporting time, is stored in the identifier table A of the main identifier database A to obtain the storage result. The storage result represents the association relationship between machine node A and target identifier 3.

[0105] In summary, by establishing the association between target identifiers and machine nodes, it is shown that a target identifier in the identifier database is being used by a machine node, thus preventing the target identifier from being used by other machine nodes. This ensures that the same identifier in the identifier database is not occupied by other machine nodes at the same time.

[0106] Step S106: Based on the association relationship, record the target identifier in the identifier database as a usage status.

[0107] Specifically, the usage status is a mutable data stored in the identifier database, used to indicate that the target identifier in the identifier database is in a state of being used. While the target identifier is in a state of being used, the target identifier will not be assigned to other machine nodes that need to be started.

[0108] Based on this, after establishing the association between the target identifier and the machine node, the record information corresponding to the target identifier in the identifier database is updated based on the association, that is, the target identifier in the identifier database is recorded as being in use.

[0109] Using the previous example, the identifier table A records the status corresponding to each identifier, which is used to indicate whether each identifier in the identifier table A is occupied. After establishing the association between machine node A and target identifier 3, that is, machine node A uses target identifier 3, the NOT_USING (not used) status corresponding to target identifier 3 in the identifier table A is recorded as the usage status, that is, USING (in use), which means that target identifier 3 is being used by machine node and cannot be used by other machine nodes.

[0110] Furthermore, after recording the target identifier in the identifier database as being in use, it indicates that the machine node has started successfully. Considering that there may be situations where machine nodes stop running due to network factors, the machine node needs to send timestamp reporting information at fixed intervals. The specific implementation is as follows:

[0111] Receive the timestamp reporting information corresponding to the machine node; determine the target identifier table contained in the identifier database, and determine the target historical timestamp information corresponding to the target identifier in the target identifier table; update the target historical timestamp information corresponding to the target identifier in the target identifier table to the timestamp reporting information.

[0112] Specifically, timestamp reporting information refers to the timestamp information stored in the identifier database at fixed intervals after the machine node starts and the target identifier is determined. That is, after the machine node starts, it generates a timestamp reporting message at fixed intervals. The target identifier table refers to the identifier table corresponding to the target identifier. The target identifier table stores the target identifier. Correspondingly, the target historical timestamp information refers to the timestamp information corresponding to the target identifier in the target identifier table. After the server receives the timestamp reporting information corresponding to the machine node, it replaces the target historical timestamp information corresponding to the target identifier in the target identifier table with the timestamp reporting information.

[0113] Based on this, after the machine node completes startup and records the target identifier in the identifier database as being in use, the server receives the timestamp reporting information periodically reported by the machine node. The server then starts a target identifier table containing the target identifier in the identifier database and determines the target historical timestamp information corresponding to the target identifier in the target identifier table. The server updates the target historical timestamp information corresponding to the target identifier in the target identifier table with the timestamp reporting information, thus updating the target historical timestamp information corresponding to the target identifier in the target identifier table at fixed intervals.

[0114] Following the previous example, after recording the NOT_USING (not used) status corresponding to target identifier 3 in identifier table A as the used status, the server registers a scheduled task for machine node A, which generates a timestamp every 3 seconds. The generated timestamp replaces the timestamp corresponding to target identifier 3 in identifier table A of the main identifier database A, thus updating the timestamp information of identifier table A every 3 seconds.

[0115] In summary, by replacing the target historical timestamp information corresponding to the target identifier in the target identifier table with the timestamp reporting information, the target historical timestamp information corresponding to the target identifier in the target identifier table is updated, thus avoiding the possibility that the target identifier may be occupied by other machine nodes due to the target historical timestamp information corresponding to the target identifier not being updated for a long time.

[0116] Furthermore, considering that network issues may prevent the receiving of timestamp records from machine nodes, if no timestamp records are received within a preset time period, it is necessary to determine whether the machine node is still running. The specific implementation is as follows:

[0117] If no timestamp record information is received within a preset time period, it is determined whether the machine node is in a running state; if the machine node is in a running state, an unassigned recovery identifier is selected from the identifier database, an association relationship is established between the recovery identifier and the machine node, and based on the association relationship, the recovery identifier in the identifier database is recorded as being in use.

[0118] Specifically, the timestamp record information refers to the timestamp information reported to the server at fixed intervals after the machine node has successfully started up and occupied the target identifier, which is used to indicate that the machine node is online; the recovery identifier refers to another identifier selected from the identifier database when the machine node does not receive the timestamp record information within a preset time period while using the target identifier.

[0119] Based on this, after a machine node starts up and occupies a target identifier, it will report timestamp record information to the server at fixed intervals and store the timestamp record information in the identifier table corresponding to the target identifier. If no timestamp record information is received within a preset time period, it is determined whether the machine node is still in the running state. If the machine node is still in the running state, an unassigned recovery identifier is selected from the identifier database, an association relationship is established between the recovery identifier and the machine node, and based on the association relationship, the recovery identifier in the identifier database is recorded as being in use.

[0120] Using the previous example, due to network issues or database crashes, the timestamp information reported by machine node A may not be received. That is, the timestamp information corresponding to target identifier 3 may not be updated for a long time. In this scenario, the running status of machine node A is detected. If machine node A is still running, another identifier in an idle state is selected from the identifier database A as the recovery identifier, and the status of the recovery identifier is recorded as the usage status.

[0121] In addition, if the machine node does not obtain the recovery flag, it is necessary to take machine node A offline. A shutdown command is sent to the port of machine node A and waits for 30 seconds. Within 30 seconds, the machine completes the shutdown callback of the components and the shutdown of the service, thereby stopping the machine node and reducing traffic loss.

[0122] In summary, if no timestamp record information is received within the preset time period, the system determines whether the machine node is still running. If the machine node is still running, a recovery flag is selected for the machine node, thereby ensuring the normal operation of the machine node and preventing the service from being interrupted.

[0123] Furthermore, when a machine node terminates and releases its occupied target identifier, considering that the target identifier can be reassigned to other machine nodes upon startup, it is necessary to record the deregistration timestamp information corresponding to the release of the target identifier. The specific implementation is as follows:

[0124] Generate a cancellation timestamp for the target identifier and store it in the identifier database in the identifier record corresponding to the target identifier.

[0125] Specifically, the deregistration timestamp information refers to the timestamp information corresponding to the end of the machine node's operation. It is used to store the deregistration timestamp information in the identifier database, indicating the time when the target identifier was released by the machine node. The identifier record refers to a record in the identifier table of the identifier database, that is, a row of information in the identifier table. A record is the basic unit of information storage in the database, and it is a row of data in the data table contained in the identifier database.

[0126] Based on this, when a machine node stops running and releases the occupied target identifier, a deregistration timestamp is generated for the target identifier, and the deregistration timestamp is stored in the identifier database in the identifier record corresponding to the target identifier.

[0127] Using the previous example, when machine node A goes offline and is deregistered, the timestamp at the time of offline deregistration is used as the deregistration timestamp, and the deregistration timestamp is stored in the identifier table A of the main identifier database A. That is, the current timestamp information corresponding to the target identifier in the identifier table A is updated with the deregistration timestamp information.

[0128] In summary, after the target identifier is released, it can be assigned to other machine nodes when they start up. The deregistration timestamp information corresponding to the release of the target identifier is recorded so that other machine nodes can select the released target identifier when they start up. This realizes the reuse of the target identifier, improves resource utilization, and makes the services provided by the server more stable.

[0129] Step S108: If the machine node is detected to meet the identifier recycling conditions, the target identifier in the identifier database is recorded as idle, and the machine node information associated with the target identifier is released.

[0130] Specifically, the tag recycling condition refers to the conditions for determining whether a tag can be recycled; the idle state refers to the state corresponding to the tag in the database. When the tag is not used, the state corresponding to the tag in the tag database is the idle state; the machine node information refers to information related to the machine node, including but not limited to the machine node's IP address, port number, and heartbeat timestamp. The heartbeat timestamp refers to the timestamp information that is periodically reported to the server when the machine node is in the running state, i.e., the current time information.

[0131] Based on this, after recording the target identifier in the identifier database as being in use based on the aforementioned association relationship, the machine nodes are checked. When a machine node is detected that meets the identifier reclamation conditions, the target identifier in the identifier database is recorded as being in an idle state. At the same time, the machine node information corresponding to the target identifier is released. That is, the usage state corresponding to the target identifier is changed to an idle state in the identifier database. The target identifier is then used to allocate to the next machine node that needs to be started.

[0132] Once the target identifier is switched to an idle state, it will become an optional identifier in the next allocation cycle, i.e., an identifier in an unallocated state. This allows it to be selected in response to a machine node's startup request in the next allocation cycle, thus enabling identifier reuse.

[0133] Following the previous example, after assigning target identifier 3 to machine node A, machine node A can be monitored to see if it meets the identifier reclamation conditions. If it does, target identifier 3 used by machine node A can be reclaimed, and the status of target identifier 3 can be recorded as idle, i.e., NOT_USING.

[0134] Furthermore, after recording the target identifier in the identifier database as being in use, the system begins to check whether the machine node meets the identifier reclamation conditions. These conditions can be manually set according to actual needs. If a machine node is detected to meet the reclamation conditions, the target identifier in the identifier database is recorded as being in an idle state. The specific implementation is as follows:

[0135] Upon receiving a shutdown request for the machine node, the system determines that the machine node meets the identifier reclamation conditions and executes the step of recording the target identifier in the identifier database as an idle state; or, if no timestamp information is received within a preset time period, the system determines that the machine node meets the identifier reclamation conditions and executes the step of recording the target identifier in the identifier database as an idle state; or, if it detects that the timestamp corresponding to the server and the timestamp corresponding to the machine node are inconsistent, the system determines that the machine node meets the identifier reclamation conditions and executes the step of recording the target identifier in the identifier database as an idle state.

[0136] Specifically, a shutdown request refers to a computer instruction used to terminate the operation of a machine node; the identifier reclamation condition refers to the conditions that must be met to reclaim a target identifier, that is, when the target identifier is not occupied, the target identifier is reclaimed so that it can be reassigned to other machine nodes that need to be started, thus realizing the reuse of the target identifier.

[0137] Based on this, when a machine node is detected to meet the identifier reclamation conditions, the target identifier in the identifier database is recorded as idle. The situations in which a machine node meets the identifier reclamation conditions include, but are not limited to, the following: If a shutdown request is received for the machine node, it is determined that the machine node meets the identifier reclamation conditions, and the target identifier in the identifier database can be recorded as idle; if no timestamp information is received within a preset time period, it is determined that the machine node meets the identifier reclamation conditions, and the target identifier in the identifier database can be recorded as idle; if the timestamp corresponding to the server and the timestamp corresponding to the machine node are inconsistent, it is determined that the machine node meets the identifier reclamation conditions, and the target identifier in the identifier database can be recorded as idle.

[0138] Following the previous example, after assigning target identifier 3 to machine node A, we monitor whether machine node A meets the identifier reclamation conditions. If a shutdown request is detected for machine node A, it indicates that machine node A has stopped running and no longer needs target identifier 3; in this case, machine node A meets the identifier reclamation conditions. If no timestamp information is received from machine node A within a preset 50-minute period, it may be due to network factors causing the machine node to shut down; in this case, machine node A meets the identifier reclamation conditions. If the timestamp corresponding to the server and the timestamp corresponding to the machine node are inconsistent, it may be due to a clock rollback; in this case, machine node A needs to stop running, i.e., machine node A meets the identifier reclamation conditions. When machine node A meets the identifier reclamation conditions, the target identifier 3 stored in the identifier table A of the identifier database A is recorded as idle, i.e., NOT_USING (not used), thus releasing target identifier 3 so that it can be used by other machine nodes.

[0139] In summary, when a machine node meets the conditions for tag reclamation, the target tag corresponding to the machine node is recorded as idle, thereby enabling the target tag to be used by other machine nodes, realizing the reuse of the target tag and improving resource utilization.

[0140] Furthermore, after the target identifier is recorded as idle, considering that other machine nodes may also need to obtain the identifier during startup, a target identifier that is in an idle state can be selected. The specific implementation is as follows:

[0141] Upon receiving a target startup command for a target machine node, a target machine identifier is selected from the main identifier database based on the target startup command. The target machine identifier can be any identifier in the identifier database that is in an idle state, or it can be a target identifier corresponding to the machine node that has been released.

[0142] Continuing with the previous example, after receiving the start command B for machine node B, an idle identifier is selected from the main identifier database A of the identifier database A based on the start command B. During the identifier selection process, target identifier 3, which is currently idle, can be selected as the identifier corresponding to machine node B. Alternatively, all idle identifiers can be identified in the main identifier database A, and any one of these idle identifiers can be selected as the identifier corresponding to machine node B.

[0143] In summary, after the target identifier is recorded as idle, upon receiving a start request for the target machine node, the target identifier can be reassigned to the target machine node, thereby reusing the target identifier, improving service stability, and increasing resource utilization.

[0144] The identifier allocation method provided in this specification, in response to a startup request for a machine node, selects an unassigned target identifier from the identifier database; establishes an association between the target identifier and the machine node; based on the association, records the target identifier in the identifier database as being in use; and when it is detected that a machine node meets the identifier reclamation conditions, records the target identifier in the identifier database as being in an idle state and releases the machine node information associated with the target identifier. This allows the released target identifier to be used by other machine nodes when they start up, realizing the reuse of identifiers in the identifier database and thus avoiding the situation where service cannot be provided due to the exhaustion of identifiers.

[0145] The following is in conjunction with the appendix Figure 2 Taking the application of the identifier allocation method provided in this specification to the identifier allocation of machine nodes as an example, the identifier allocation method will be further explained. Among them, Figure 2 This specification illustrates a flowchart of an identifier allocation method for machine node identifier allocation according to an embodiment of the present specification, which specifically includes the following steps:

[0146] Step S202: Create at least one pair of identifier databases, each pair of identifier databases including a primary identifier database and a backup identifier database.

[0147] Create a pair of identifier databases in region 1, and create a pair of identifier databases in other regions such as region 2 and region 3. Each pair of identifier databases includes a primary identifier database and a backup identifier database. Correspondingly, region 1 has a primary identifier database 1 and a backup identifier database 1. If the identifier database corresponding to region 1 is a local identifier database, the identifier databases corresponding to other regions are all remote identifier databases.

[0148] Step S204: Create an identifier table in each primary identifier database and backup identifier database.

[0149] An identifier table is created in each primary identifier database and each backup identifier database. The identifier table stores available identifiers with defined identifier ranges. For example, the identifier range in primary identifier database 1 is 0-99, and the identifier range in backup identifier database 1 is 100-149.

[0150] Step S206: Receive the startup command for the machine node.

[0151] Step S208: Generate an identifier lookup instruction based on the machine node's startup instruction.

[0152] Step S210: Determine at least one primary identifier database in the identifier database based on the identifier lookup instruction.

[0153] If the machine node 1 that needs to be started is the machine node corresponding to region 1, the main identifier database 1 is determined based on the identifier lookup instruction.

[0154] Step S212: Determine whether there is an idle identifier in the main identifier database. If yes, proceed to step S214; otherwise, proceed to step S216.

[0155] Determine whether there is an identifier in the main identifier database 1 that is in an idle state, i.e., in the NOT_USING state.

[0156] Step S214: Select the target identifier corresponding to the machine node from the identifiers in the idle state, and record the identifier status of the target identifier as the usage state.

[0157] Among the identified identifiers in the NOT_USING state, select one identifier as the target identifier for machine node 1, and change the state of the target identifier to the USING state.

[0158] Step S216: Select an identifier that is in use and whose timestamp information is more than a time threshold away from the current time from the main identifier database as the target identifier, and record the identifier status of the target identifier as the use status.

[0159] If no idle identifier exists in the main identifier database, then an identifier whose timestamp is more than one hour from the current time is searched among the identifiers in use and used as the target identifier.

[0160] Step S218: Determine whether the target identifier is recorded as being in use. If yes, proceed to step S220; otherwise, proceed to step S222.

[0161] When the status of a target identifier is changed, it is determined whether the target identifier has been recorded as being in use.

[0162] Step S220: Update the identifier table based on the timestamp information reported by the machine node.

[0163] Step S222: Determine whether there are available identifiers in the backup identifier database. If yes, proceed to step S224; otherwise, proceed to step S226.

[0164] Determine whether there is an idle identifier in the backup identifier database, or determine whether there is an identifier in the backup identifier database that is in use and whose timestamp information is more than one hour away from the current time.

[0165] Step S224: Select the target identifier corresponding to the machine node from the available identifiers in the standby database, and record the identifier status of the target identifier as the usage status.

[0166] Step S226: Stop the startup of the machine node, or select a remote identifier database from at least one pair of identifier databases, and select the target identifier from the remote identifier database.

[0167] Step S228: Update the identifier table based on the timestamp information reported by the machine node.

[0168] After machine node 1 starts up successfully, timestamp reporting information is generated at fixed intervals, and the timestamp information corresponding to the target identifier is replaced with the timestamp reporting information in the identifier table to realize the timed update of timestamp information.

[0169] Step S230: If the machine node is detected to meet the tag recycling conditions, the target tag in the tag table is recorded as idle.

[0170] If machine node 1 stops running and exits normally, or if a clock rollback is detected and machine node 1 is forced to exit, the target identifier is released and can be used by other machine nodes.

[0171] Step S232: After receiving the target startup instruction for the target machine node, the target machine node is treated as the machine node, the target startup instruction is treated as the startup instruction, and step S208 is executed.

[0172] After receiving the start command 2 for machine node 2, the target machine node is used as the machine node, the start command 2 is used as the start command, a new idle identifier is selected from the identifier database, or an already idle target identifier can be selected as the identifier corresponding to machine node 2.

[0173] In summary, in response to a startup request for a machine node, an unassigned target identifier is selected from the identifier database; an association is established between the target identifier and the machine node; based on the association, the target identifier in the identifier database is recorded as being in use; and when a machine node is detected to meet the identifier reclamation conditions, the target identifier in the identifier database is recorded as being in idle state, and the machine node information associated with the target identifier is released. This allows the released target identifier to be used by other machine nodes when they start up, achieving identifier reuse in the identifier database and thus avoiding the situation where service cannot be provided due to identifier exhaustion.

[0174] Corresponding to the above method embodiments, this specification also provides embodiments of an identifier allocation device. Figure 3 A schematic diagram of the structure of an identifier allocation device according to an embodiment of this specification is shown. Figure 3 As shown, the device includes:

[0175] Select module 302 is configured to select an unassigned target identifier from the identifier database in response to a startup request for a machine node;

[0176] Module 304 is configured to establish an association between the target identifier and the machine node;

[0177] The recording module 306 is configured to record the target identifier in the identifier database as a usage status based on the association relationship;

[0178] Release module 308 is configured to, when the machine node is detected to meet the identifier reclamation conditions, record the target identifier in the identifier database as idle and release the machine node information associated with the target identifier.

[0179] In an optional embodiment, the selection module 302 is further configured to:

[0180] At least one pair of identifier databases are created based on a preset storage space, wherein each pair of identifier databases includes a primary identifier database and a backup identifier database, and both the primary identifier database and the backup identifier database contain an identifier table, wherein the identifier table records at least one identifier; accordingly, in response to a startup request for a machine node, an unassigned target identifier is selected in the identifier database, including: in response to a startup request for the machine node, determining a local identifier database in the at least one pair of identifier databases, and selecting an unassigned target identifier in the primary identifier database of the local identifier database.

[0181] In an optional embodiment, the selection module 302 is further configured to:

[0182] Receive a startup request for the machine node and generate an identifier lookup instruction based on the startup request; determine the local identifier database corresponding to the identifier lookup instruction in the at least one pair of identifier databases, and select a primary identifier database in the local identifier database; search for at least one intermediate identifier in the identifier table contained in the primary identifier database, wherein the usage status of each intermediate identifier is idle; determine the target identifier from the at least one intermediate identifier according to the identifier selection strategy.

[0183] In an optional embodiment, the selection module 302 is further configured to:

[0184] Determine the intermediate historical timestamp information corresponding to each intermediate identifier in at least one intermediate identifier; based on the intermediate historical timestamp information corresponding to each intermediate identifier, select the intermediate identifier corresponding to the maximum or minimum timestamp information as the target identifier.

[0185] In an optional embodiment, the establishment module 304 is further configured to:

[0186] Based on the target identifier, the node information corresponding to the machine node is stored in the identifier database, and the storage result is used as the association relationship.

[0187] In an optional embodiment, the selection module 302 is further configured to:

[0188] Determine whether an intermediate identifier exists in the main identifier database; if so, perform the step of searching for at least one intermediate identifier in the identifier table contained in the main identifier database.

[0189] In an optional embodiment, the selection module 302 is further configured to:

[0190] If the result of determining whether an intermediate identifier exists in the primary identifier database is negative, the following steps are performed: determine a backup identifier database in the local identifier database; if the identifier table contained in the backup identifier database contains an intermediate identifier, search for at least one intermediate identifier in the identifier table contained in the backup identifier database; or, if the identifier table contained in the backup identifier database does not contain an intermediate identifier, select an intermediate identifier from the remote identifier database in the at least one pair of identifier databases.

[0191] In an optional embodiment, the recording module 306 is further configured to:

[0192] Receive the timestamp reporting information corresponding to the machine node; determine the target identifier table contained in the identifier database, and determine the target historical timestamp information corresponding to the target identifier in the target identifier table; update the target historical timestamp information corresponding to the target identifier in the target identifier table to the timestamp reporting information.

[0193] In an optional embodiment, the release module 308 is further configured to:

[0194] Upon receiving a shutdown request for the machine node, the system determines that the machine node meets the identifier reclamation conditions and executes the step of recording the target identifier in the identifier database as an idle state; or, if no timestamp information is received within a preset time period, the system determines that the machine node meets the identifier reclamation conditions and executes the step of recording the target identifier in the identifier database as an idle state; or, if it detects that the timestamp corresponding to the server and the timestamp corresponding to the machine node are inconsistent, the system determines that the machine node meets the identifier reclamation conditions and executes the step of recording the target identifier in the identifier database as an idle state.

[0195] In an optional embodiment, the recording module 306 is further configured to:

[0196] If no timestamp record information is received within a preset time period, it is determined whether the machine node is in a running state; if the machine node is in a running state, an unassigned recovery identifier is selected from the identifier database, an association relationship is established between the recovery identifier and the machine node, and based on the association relationship, the recovery identifier in the identifier database is recorded as being in use.

[0197] In an optional embodiment, the recording module 306 is further configured to:

[0198] Generate a cancellation timestamp for the target identifier and store it in the identifier database in the identifier record corresponding to the target identifier.

[0199] The identifier allocation device provided in this specification, in response to a startup request for a machine node, selects an unassigned target identifier from the identifier database; establishes an association between the target identifier and the machine node; records the target identifier in the identifier database as being in use based on the association; and, upon detecting that a machine node meets the identifier reclamation conditions, records the target identifier in the identifier database as being in an idle state and releases the machine node information associated with the target identifier. This allows the released target identifier to be used by other machine nodes when they start up, achieving identifier reuse in the identifier database and thus avoiding the inability to provide service due to identifier exhaustion.

[0200] The above is a schematic scheme of an identifier allocation device according to this embodiment. It should be noted that the technical solution of this identifier allocation device and the technical solution of the identifier allocation method described above belong to the same concept. For details not described in detail in the technical solution of the identifier allocation device, please refer to the description of the technical solution of the identifier allocation method described above.

[0201] Figure 4 A structural block diagram of a computing device 400 according to an embodiment of this specification is shown. The components of the computing device 400 include, but are not limited to, a memory 410 and a processor 420. The processor 420 is connected to the memory 410 via a bus 430, and a database 450 is used to store data.

[0202] The computing device 400 also includes an access device 440, which enables the computing device 400 to communicate via one or more networks 460. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 440 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0203] In one embodiment of this specification, the aforementioned components of the computing device 400 and Figure 4 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 4The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0204] The computing device 400 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 400 can also be a mobile or stationary server.

[0205] The processor 420 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described identifier allocation method.

[0206] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described identifier allocation method belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described identifier allocation method.

[0207] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the above-described identifier allocation method.

[0208] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the above-described identifier allocation method belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the above-described identifier allocation method.

[0209] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0210] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0211] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this specification is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this specification. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this specification.

[0212] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0213] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. These embodiments have been selected and specifically described in this specification to better explain the principles and practical applications of this specification, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A method for assigning identifiers, characterized in that, Applied to a server, the server having an identifier database deployed thereon, including: In response to a startup request for a machine node, an unassigned target identifier is selected from the identifier database; Establish the association between the target identifier and the machine node; Based on the aforementioned association, the target identifier in the identifier database is recorded as a usage status; Upon receiving the timestamp reporting information corresponding to the machine node, the target identifier table contained in the identifier database is determined, and the target historical timestamp information corresponding to the target identifier is determined in the target identifier table. The target historical timestamp information corresponding to the target identifier in the target identifier table is then updated to the timestamp reporting information. If the timestamp reporting information is not received within a preset time period, it is determined whether the machine node is in a running state; if the machine node is in a running state, an unassigned recovery identifier is selected from the identifier database, an association relationship is established between the recovery identifier and the machine node, and based on the association relationship, the recovery identifier in the identifier database is recorded as a usage state, wherein the recovery identifier is different from the target identifier; If the machine node is detected to meet the identifier reclamation conditions, the target identifier in the identifier database is recorded as idle, and the machine node information associated with the target identifier is released.

2. The method according to claim 1, characterized in that, The step of selecting an unassigned target identifier from the identifier database in response to a startup request for a machine node also includes: At least one pair of identifier databases are created based on a preset storage space. Each pair of identifier databases includes a primary identifier database and a backup identifier database. Both the primary identifier database and the backup identifier database contain an identifier table, which records at least one identifier. Accordingly, in response to a startup request for a machine node, an unassigned target identifier is selected from the identifier database, including: In response to a startup request for the machine node, a local identity database is determined from at least one pair of identity databases, and an unassigned target identity is selected from the primary identity database of the local identity database.

3. The method according to claim 2, characterized in that, In response to a startup request for the machine node, determining a local identity database in at least one pair of identity databases and selecting an unassigned target identity in the primary identity database of the local identity database includes: Receive a startup request for the machine node, and generate an identifier lookup instruction based on the startup request; Determine the local identifier database corresponding to the identifier lookup instruction from the at least one pair of identifier databases, and select the primary identifier database from the local identifier database; Search for at least one intermediate identifier in the identifier table contained in the main identifier database, wherein each intermediate identifier is in an idle state. The target identifier is determined from the at least one intermediate identifier according to the identifier selection strategy.

4. The method according to claim 3, characterized in that, The step of determining the target identifier from the at least one intermediate identifier according to the identifier selection strategy includes: Determine the intermediate historical timestamp information corresponding to each intermediate identifier in at least one intermediate identifier; Based on the intermediate historical timestamp information corresponding to each intermediate identifier, select the intermediate identifier corresponding to the largest or smallest timestamp information as the target identifier.

5. The method according to claim 1, characterized in that, Establishing the association between the target identifier and the machine node includes: Based on the target identifier, the node information corresponding to the machine node is stored in the identifier database, and the storage result is used as the association relationship.

6. The method according to claim 3, characterized in that, Before the step of searching for at least one intermediate identifier in the identifier table contained in the main identifier database is performed, the method further includes: Determine whether an intermediate identifier exists in the main identifier database; If so, perform the step of searching for at least one intermediate identifier in the identifier table contained in the main identifier database.

7. The method according to claim 6, characterized in that, If the result of determining whether an intermediate identifier exists in the main identifier database is negative, the following steps are performed: Determine a backup identifier database from the local identifier database; If the identifier table included in the backup identifier database contains an intermediate identifier, at least one intermediate identifier is searched in the identifier table included in the backup identifier database; or, if the identifier table included in the backup identifier database does not contain an intermediate identifier, an intermediate identifier is selected from the off-site identifier database in the at least one pair of identifier databases.

8. The method according to claim 1, characterized in that, The step of recording the target identifier in the identifier database as idle when the machine node is detected to meet the identifier reclamation conditions includes: Upon receiving a shutdown request for the machine node, it is determined that the machine node meets the identifier reclamation conditions, and the step of recording the target identifier in the identifier database as idle is executed; or, If no timestamp information is received within a preset time period, the machine node is determined to meet the identifier reclamation condition, and the step of recording the target identifier in the identifier database as idle is executed; or, If the timestamp corresponding to the server and the timestamp corresponding to the machine node are found to be inconsistent, it is determined that the machine node meets the tag reclamation conditions, and the step of recording the target tag in the tag database as an idle state is executed.

9. The method according to claim 4, characterized in that, After the steps of recording the target identifier in the identifier database as idle and releasing the machine node information associated with the target identifier are executed, the method further includes: Generate a cancellation timestamp for the target identifier and store it in the identifier database in the identifier record corresponding to the target identifier.

10. A labeling and distributing device, characterized in that, Applied to a server, the server having an identifier database deployed thereon, including: The selection module is configured to select an unassigned target identifier from the identifier database in response to a startup request for a machine node. The module is configured to establish an association between the target identifier and the machine node; The recording module is configured to, based on the association relationship, record the target identifier in the identifier database as being in use; upon receiving timestamp reporting information corresponding to the machine node, determine the target identifier table contained in the identifier database, and determine the target historical timestamp information corresponding to the target identifier in the target identifier table, and update the target historical timestamp information corresponding to the target identifier in the target identifier table to the timestamp reporting information; if no timestamp reporting information is received within a preset time period, determine whether the machine node is in a running state; if the machine node is in a running state, select an unassigned recovery identifier in the identifier database, establish an association relationship between the recovery identifier and the machine node, and based on the association relationship, record the recovery identifier in the identifier database as being in use, wherein the recovery identifier is different from the target identifier; The release module is configured to, when the machine node is detected to meet the identifier reclamation conditions, record the target identifier in the identifier database as idle and release the machine node information associated with the target identifier.

11. A computing device, characterized in that, It includes a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the steps of the identifier allocation method according to any one of claims 1 to 9.

12. A computer-readable storage medium storing computer instructions, characterized in that, When executed by the processor, this instruction implements the steps of the identifier allocation method according to any one of claims 1 to 9.

Images