CN117473010A

CN117473010A - Distributed ID generation method, device, terminal equipment and storage medium

Info

Publication number: CN117473010A
Application number: CN202311399677.2A
Authority: CN
Inventors: 赵志瑞
Original assignee: China Merchants Bank Co Ltd
Current assignee: China Merchants Bank Co Ltd
Priority date: 2023-10-25
Filing date: 2023-10-25
Publication date: 2024-01-30

Abstract

The application discloses a distributed ID generation method, a device, terminal equipment and a storage medium, which belong to the technical field of distributed systems, and the distributed I D generation method comprises the following steps: when the starting of the application instance is detected, inquiring whether a return record exists in a preset record table, wherein the return record comprises a distributed I D in a cache queue when the application instance is recently terminated; if the return record exists in the preset record table, adding the distributed I D in the return record to the cache queue for consumption of the application instance. The present application may avoid a sequence loss of the distributed I D generation policy to promote performance of application instances that generate distributed I D using the distributed I D generation policy.

Description

Distributed ID generation method, device, terminal equipment and storage medium

Technical Field

The application belongs to the technical field of distributed systems, and particularly relates to a distributed ID generation method, a device, terminal equipment and a storage medium.

Background

With the continuous development of technology, more and more network technologies are layered endlessly, and particularly in data processing systems with massive data features, distributed systems are widely applied by virtue of self cohesiveness and transparency.

At present, in a distributed system, a large amount of services, data and messages often need to be uniquely identified, and a common generation mode of a distributed ID ((Identity document, identity) is a database number segment mode, which is a method for generating and storing the distributed ID in advance, and can be understood as that the distributed ID is obtained in batches from a database, and then the distributed ID is cached in a local memory (i.e. a cache queue, where the distributed ID in the cache queue is an ID to be consumed) in a queue form, so as to improve the efficiency of obtaining the distributed ID by the service, however, when a current application instance (an application instance is a specific service application program or a single running instance in the distributed system) is suspended, the distributed ID in the cache queue is lost, so that the performance of the application instance is reduced.

In summary, how to provide a distributed ID generation policy to improve the performance of an application instance that generates a distributed ID by using the distributed ID generation policy has become a technical problem to be solved in the technical field of distributed systems.

Disclosure of Invention

The main object of the present application is to provide a distributed ID generation method, a device, a terminal device and a storage medium. The purpose is to improve the performance of an application instance that generates a distributed ID using the distributed ID generation policy.

In order to achieve the above object, the present application provides a distributed ID generation method including the steps of:

inquiring whether a return record exists in a preset record table when the starting of an application instance is detected, wherein the return record comprises a distributed ID in a cache queue when the application instance is recently terminated;

and if the return record exists in the preset record table, adding the distributed ID in the return record into the cache queue for consumption by the application instance.

Optionally, the method further comprises:

under the condition that the application instance violents are terminated, detecting whether a cache record in a preset record table is updated in preset time, wherein the cache record comprises a largest distributed ID and a smallest distributed ID in the cache queue;

and if the cache record is detected not to be updated in the preset time, updating or deleting the return record based on the cache record.

Optionally, the step of updating or deleting the return record based on the cache record includes:

determining the largest target distributed ID in the used ID queue based on a service table corresponding to the application instance;

Judging whether a distributed ID larger than the target distributed ID exists in the cache record or not;

if the distributed ID larger than the target distributed ID exists in the cache record, determining the distributed ID larger than the target distributed ID in the cache record as a first unused distributed ID in the cache record, and updating the return record based on the first distributed ID;

and if the distributed ID larger than the target distributed ID does not exist in the cache record, deleting the return record.

Optionally, the method further comprises:

detecting whether a second distributed ID to be consumed exists in the cache queue under the condition that the application instance is gracefully terminated;

if the second distributed ID exists in the cache queue, updating the return record based on the second distributed ID;

and if the fact that the second distributed ID does not exist in the cache queue is detected, deleting the return record.

Optionally, the method further comprises:

detecting whether a distributed ID to be consumed exists in the cache queue or not when an ID request triggered by a user is received;

if the distributed ID to be consumed exists in the cache queue, returning the minimum distributed ID in the cache queue to the user;

If the fact that the distributed IDs to be consumed do not exist in the cache queue is detected, acquiring batch distributed IDs from the database corresponding to the application instance based on the ID request, returning the minimum distributed ID in the cache queue to the user.

Optionally, the ID request includes a repository number and a sequence name of the application instance, and the step of obtaining, based on the ID request, a batch of distributed IDs from a database corresponding to the application instance to the cache queue includes:

determining a database corresponding to the application instance based on the database dividing number;

determining an ID queue to be fetched corresponding to the sequence name in the database based on the sequence name, wherein the ID queue to be fetched comprises a plurality of continuous distributed IDs which are generated in advance;

taking the smallest distributed ID in the ID queue to be fetched as an initial sequence value;

and obtaining a preset number of continuous third distributed IDs from the ID queue to be fetched to the cache queue, wherein the minimum value in the third distributed IDs is the initial sequence value.

Optionally, after the step of obtaining, based on the ID request, a batch of distributed IDs from the database corresponding to the application instance to the cache queue, the method further includes:

Deleting the third distributed ID from the ID waiting queue to update the ID waiting queue.

In addition, to achieve the above object, the present application further provides a distributed ID generation apparatus, including:

the query module is used for querying whether a return record exists in a preset record table when the starting of the application instance is detected, wherein the return record comprises a distributed ID in a cache queue when the application instance is recently terminated;

and the return module is used for adding the distributed ID in the return record to the cache queue for consumption of the application instance if the return record exists in the preset record table.

In addition, to achieve the above object, the present application also provides a distributed ID generating apparatus including: the distributed ID generation device comprises a memory, a processor and a distributed ID generation program which is stored in the memory and can run on the processor, wherein the distributed ID generation program of the distributed ID generation device realizes the steps of the distributed ID generation method when being executed by the processor.

In addition, in order to achieve the above object, the present application also provides a computer-readable storage medium having stored thereon a distributed ID generation program which, when executed by a processor, implements the steps of the distributed ID generation method described above.

According to the embodiment of the application instance consumption method, whether the return record exists in the preset record table or not is inquired when the application instance is detected to be started, wherein the return record comprises the distributed IDs in the cache queue when the application instance is recently terminated, and when the return record exists in the preset record table, the distributed IDs in the return record are added into the cache queue for the application instance consumption. In this way, compared with the traditional distributed ID generation mode which may cause sequence loss when the application instance is terminated, the method and the device generate the return record containing the distributed IDs in the cache queue when the application instance is terminated and store the return record into the preset record table, so that when the application instance is restarted, the lost distributed IDs are preferentially retrieved from the return record and added into the cache queue for subsequent use, the sequence loss is avoided, and the consistency, the integrity and the traceability of all the used distributed IDs are ensured, and further, the performance of the application instance for generating the IDs by using the distributed ID generation strategy is improved.

Drawings

FIG. 1 is a schematic device architecture diagram of a hardware operating environment of a distributed ID generating device according to an embodiment of the present application;

FIG. 2 is a flowchart illustrating steps of a first embodiment of a distributed ID generation method according to the present application;

FIG. 3 is a schematic diagram of a distributed ID generation flow according to an embodiment of the distributed ID generation method of the present application;

FIG. 4 is a schematic diagram of a sequence caching process according to an embodiment of the distributed ID generation method of the present application;

fig. 5 is a schematic functional block diagram of an embodiment of a distributed ID generation device of the present application.

The realization, functional characteristics and advantages of the present application will be further described with reference to the embodiments, referring to the attached drawings.

Detailed Description

It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the present application.

Referring to fig. 1, fig. 1 is a schematic device structure diagram of a hardware running environment of a distributed ID generating device according to an embodiment of the present application.

It should be noted that the embodiments of the present application relate to a distributed ID generating device in the technical field of distributed systems. Specifically, the distributed ID generation device may be a smart phone, a PC (PerSonal Computer ), a tablet computer, a portable computer, or the like.

As shown in fig. 1, the distributed ID generating device may include: a processor 1001, such as a CPU, a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. Wherein the communication bus 1002 is used to enable connected communication between these components. The user interface 1003 may include a DiSplay (diselay), an input unit such as a Keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface, a wireless interface. The network interface 1004 may optionally include a standard wired interface, a wireless interface (e.g., wi-Fi interface). The memory 1005 may be a high-speed RAM memory or a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may also optionally be a storage device separate from the processor 1001 described above. The execution bodies of the method steps in the embodiments are omitted below for convenience of description.

Those skilled in the art will appreciate that the distributed ID generating device structure shown in fig. 1 does not constitute a limitation of the distributed ID generating device and may include more or fewer components than shown, or may combine certain components, or a different arrangement of components.

As shown in fig. 1, an operating system, a network communication module, a user interface module, and a distributed ID generation program may be included in the memory 1005, which is one type of computer storage medium.

In the terminal shown in fig. 1, the network interface 1004 is mainly used for connecting to a background server and performing data communication with the background server; the user interface 1003 is mainly used for connecting a client and communicating data with the client; and the processor 1001 may be configured to call a distributed ID generation program stored in the memory 1005 and perform the following operations:

Further, the processor 1001 may be further configured to call a distributed ID generation program stored in the memory 1005 to perform the following operations:

Further, the operation of updating or deleting the return record based on the cache record includes:

Further, the ID request includes a repository number and a sequence name of the application instance, and the operation of obtaining, based on the ID request, a batch of distributed IDs from a database corresponding to the application instance to the cache queue includes:

Further, after the step of obtaining, based on the ID request, a batch of distributed IDs from the database corresponding to the application instance to the cache queue, the processor 1001 may be further configured to invoke a distributed ID generator stored in the memory 1005, to perform the following operations:

Based on the above-described structure, various embodiments of a distributed ID generation method are presented.

Referring to fig. 2, fig. 2 is a flowchart of a first embodiment of a distributed ID generation method according to the present application. It should be noted that although a logical order is illustrated in the flowchart, in some cases, the distributed ID generation method of the present application may of course perform the steps illustrated or described in a different order than that illustrated herein. In this embodiment, the execution subject of the distributed ID generation method may be a personal computer, a smart phone, or the like, and is not limited in this embodiment. The distributed ID generation method comprises S10-S20:

step S10, inquiring whether a return record exists in a preset record table when the starting of the application instance is detected, wherein the return record comprises a distributed ID in a cache queue when the application instance is stopped last time.

The application instance is a specific service application program or a single operation instance in the distributed system, and the application instance is a sub-library application program in the distributed system or a subsystem in the distributed system, wherein one sub-library corresponds to one sub-library database, the sub-library database is used for storing a plurality of continuous distributed IDs generated in advance, and a plurality of services can exist under one sub-library, each service has a corresponding ID queue to be fetched in the sub-library database, and the ID queue to be fetched is a plurality of continuous integer sequences. A sequence usage record table, namely the preset record table, is preset for each sub-database, and the sequence names corresponding to the sequence usage records (the sequence names are in one-to-one correspondence with the services under the sub-databases and can be preset to represent the identities of the services), the start value and the end value of the sequence usage records, the state of the sequence usage records and the heartbeat time when the record is refreshed are recorded in the preset record table. And under the condition that the current application example is terminated, if the distributed ID to be consumed exists in the cache queue, generating a sequence use record with the state of returning based on the distributed ID in the cache queue, namely the returning record, wherein the sequence name of the returning record is the sequence name of the current application example, the starting value of the returning record is the smallest distributed ID in the cache queue, the ending value of the returning record is the largest distributed ID in the cache queue, the state of the returning record is the returning state, and the time for generating the returning record is taken as the heartbeat time of the returning record.

In this embodiment, when it is detected that an application instance is started, whether a return record exists in the preset record table is firstly queried, if the return record exists in the preset record table, it indicates that there is a missing sequence when the current application instance is last terminated, that is, there is a distributed ID that is not consumed in the cache queue when the current application instance is last terminated, that is, the distributed ID stored in the return record, and if the return record does not exist in the preset record table, it indicates that there is no missing sequence when the current application instance is last terminated, that is, there is a distributed ID in the cache queue when the current application instance is last terminated that is consumed and used.

In a possible implementation manner, for example, a sequence usage record including a sequence name of a current application instance may be traversed in a preset record table based on the sequence name, and whether a state of the sequence usage record is a return state is detected to determine whether a return record exists in the preset record table.

At present, the distributed ID generation modes commonly used in the industry mainly include: 1. UUID (Universally Unique Identifier, universally unique identification code). The advantages are that: the local generation and the performance are very high. Disadvantages: the ID is too long, the trend increment cannot be guaranteed, and the query efficiency as the primary key index is low; 2. the database increments the ID. The advantages are that: the use is simple, the basic business requirements are met, and the method is natural and orderly. Disadvantages: the method is not applicable to a distributed system, global uniqueness cannot be guaranteed for a database and a table, and the generation rate of ID numbers depends on the read-write performance of a database to be used; 3. database number segment pattern. The number segment mode can be understood as that the IDs are obtained from a database in batches and then cached locally, so that the efficiency of obtaining the IDs by the service is improved. The advantages are that: the absolute increment order of ID generation is ensured; the pressure of the database is greatly reduced. Disadvantages: the service is still a single point, and if the service hangs, the continuous generation of the ID may not be continuous after the service is restarted, and a hole appears in the middle. It should be noted that, the present application is mainly based on the database number segment mode for optimization; 4. redis generates an ID. The advantages are that: independent of the database, flexible use and better performance than the database. Disadvantages: introducing a new component Redis, and if the Redis has a single-point fault problem, affecting the availability of serial number service; 5. a snofflake algorithm. The advantages are that: the stability is high, and the system is not dependent on third party systems such as a database and the like; the method is flexible and convenient to use, and bit positions in the algorithm can be adjusted according to the characteristics of service requirements. Disadvantages: if the clock on the machine dials back, this may result in repeated signaling or service being unavailable and the IDs not ordered.

In view of the above disadvantage of UUID, the present application may customize the format of the distributed ID in the application instance, and may be configured according to the actual requirement of the user, specifically, the present application sets the distributed ID to 1 as a repository number+21 as a serial number, and under the dimension of the service type, the serial number of 21 bits is continuously ordered, and illustratively, the repository number of the repository 1 is 1, and then the configuration of the distributed ID used by the service a under the repository 1 may be 1000000000000000000001, 1000000000000000000002, 1000000000000000000003.

Each sub-library application (i.e., application instance) is only connected to a corresponding sub-library database, and each sub-library database has a corresponding sequence ID-related table, namely a sequence configuration table and a sequence usage record table, which are shown as follows:

the structure of the sequence configuration table is a sequence name, an associated service table, a current value, a start value and a state, wherein the sequence name is a name of a service type in a preset current application example; the related service table is various data using distributed IDs, for example, in a service scenario of purchasing goods for a user, an order table is provided in the database for storing order information of the user, the order table is a form of the related service table, an ID column is provided in the order table, an ID value is obtained from a serial service, an ID represents a unique order, and it is to be noted that the serial service is a component or class for processing serial generation, buffering and consumption in an application instance; the current value is the maximum value of the distributed IDs fetched from the trouser database, for example, if the sequence name in the sequence configuration table is the sequence name of the service a under the sub-database 1, the current value 2065 indicates that the maximum distributed ID fetched from the sub-database is 1000000000000000002065, and the start value 1 indicates that the minimum distributed ID used by the service a is 1000000000000000000001; the states may be a deactivated state, a normal state, and a locked state, where the deactivated state indicates that the current application instance has terminated, the normal state indicates that the current application instance is running normally, and the locked state indicates that the current application instance is acquiring a batch of distributed IDs from the database. The sequence usage record table is as follows:

The structure of the sequence usage record table is a sequence name, a start value, an end value, a state and a heartbeat time, wherein the state comprises a cache state, a runaway state and a return state, and for example, the cache record of the application state is a maximum value (taking the maximum value as the end value) and a minimum value (taking the minimum value as the start value) in a cache queue, and the start value and the end value are refreshed once every preset time, and the refreshing moment is the heartbeat moment; under the condition that the current application instance is violently terminated, when the fact that the cache records are not refreshed according to expectations is detected, generating a runaway record with a runaway state based on the current cache records, wherein the runaway record is consistent with the starting value and the ending value of the current cache records. Then, the unused distributed ID in the uncontrolled record is determined based on the associated service table, the return record is updated based on the distributed ID, the start value of the return record is set as the minimum value in the unused distributed ID, and the end value of the return record is set as the maximum value in the unused distributed ID.

Step S20, if the return record exists in the preset record table, adding the distributed ID in the return record to the cache queue for consumption by the application instance.

If the fact that the return record corresponding to the current application instance exists in the preset record table is detected, the distributed ID in the return record is added into a cache queue for application instance consumption.

Further, in a possible embodiment, the distributed ID generation method of the present application further includes steps a10 to a20:

and step A10, under the condition that the application instance violently terminates, detecting whether a cache record in a preset record table is updated within preset time, wherein the cache record comprises the largest distributed ID and the smallest distributed ID in the cache queue.

It should be noted that, the graceful stop and the violent stop describe different ways of closing the application program, and the graceful stop refers to that the application program can perform some cleaning work when closing, so as to ensure that incomplete operations can be completed, and resources can be released to avoid data damage or other problems; violence stopping: this means that the application is not doing any cleaning work while it is closed, and is terminated directly, possibly resulting in data corruption or other problems.

In this embodiment, the interval duration, that is, the preset time, is preset, and specifically, the background thread of the current application instance is set to update the cache record once every interval T1 duration. Under the condition that the application instance is violently terminated, detecting whether a cache record in a preset record table is updated within preset time, wherein the cache record is recorded with a maximum value and a minimum value in a cache queue, if the cache record is detected to be updated within the preset time, determining that the current application instance is in the normal operation process, and if the cache record in the cache record table is detected to be updated within the preset time, determining that the application instance is violently terminated.

The present application is not limited to a specific manner of how the termination type of the application instance is determined, for example, in one possible implementation, timeout processing logic may be implemented in the application, i.e., if the application does not exit normally within a specified time, it may be considered as a violent termination. In particular by recording a time stamp or a timer. As another example, in another possible implementation, the operating system typically sends a termination signal (e.g., sigtherm) to the application. When the application receives these signals, some cleanup operations may be performed and then exit normally. This is considered to be a graceful termination. The application may capture these signals and perform appropriate termination operations by registering with the signal processing program.

In a specific embodiment, when it is determined that the current application instance is violently terminated or otherwise becomes an unavailable state, the background threads of other application instances can scan for updating of the cache record in the preset record table at intervals of T2 (which can be reasonably set according to actual requirements) so as to determine whether the cache record is updated within a preset time.

And step A20, if the cache record is detected not to be updated in the preset time, updating or deleting the return record based on the cache record.

In this embodiment, if it is detected that the cache record in the preset record table is not updated within the preset time, the return record in the preset record table is updated or deleted based on the cache record, and it should be noted that each application instance corresponds to one return record in the preset record table.

In a specific embodiment, the background thread of other application examples scans whether the cache record in the preset record table is updated once at a time interval T2, and updates or deletes the return record based on the current cache record when detecting that the cache record is not updated within the preset time.

Further, in one possible embodiment, the step a20 includes steps a201 to a204:

and step A201, determining the largest target distributed ID in the used ID queue based on the service table corresponding to the application instance.

In this embodiment, the service table is the above-mentioned associated service table, and one application instance corresponds to one service table, where the service table records the used distributed IDs. The used ID queue is a queue formed by the distributed IDs used in the service table. And determining the largest distributed ID in the used ID queue based on the service table corresponding to the current application instance, namely the target distributed ID.

In a specific embodiment, a service table corresponding to a current application instance is obtained, a used distributed ID is found in the service table, and the largest distributed ID in the service table is determined as a target distributed ID.

Step a202, determining whether a distributed ID greater than the target distributed ID exists in the cache record.

In the present embodiment, the range of the distributed IDs is determined based on the start value and the end value in the cache record in the preset record table, and it is determined whether or not there is a distributed ID larger than the target distributed ID in this ID range.

In a specific embodiment, a runaway record with a runaway state is generated based on a cache record which is not refreshed in time currently, wherein the sequence name of the runaway record is also the sequence name of the current application instance, the starting value of the runaway record is the same as the starting value in the cache record, and the ending value of the runaway record is the same as the ending value in the cache record. Determining an ending value of the uncontrolled record in a preset record table, judging whether the ending value is larger than a target distributed ID, if the ending value is larger than the target distributed ID, determining that the distributed ID larger than the target distributed ID exists in the cache record, and if the ending value is smaller than or equal to the target distributed ID, determining that the distributed ID larger than the target distributed ID does not exist in the cache record.

And step A203, if the distributed ID larger than the target distributed ID exists in the cache record, determining the distributed ID larger than the target distributed ID in the cache record as a first unused distributed ID in the cache record, and updating the return record based on the first distributed ID.

In this embodiment, if it is detected that a distributed ID larger than a target distributed ID exists in the cache record, a distributed ID larger than the target distributed ID (hereinafter referred to as a first distributed ID to show distinction) is determined in the ID range of the cache record, and the return record is updated based on the first distributed ID, that is, the start value of the return record is updated to the minimum value in the first distributed ID, and the end value of the return record is updated to the maximum value in the first distributed ID.

In a specific embodiment, when detecting that the cache record has a distributed ID greater than the target distributed ID, it indicates that in the current termination of the application instance, there is a missing sequence, where the missing sequence is the distributed ID greater than the target distributed ID, so that the missing sequence needs to be retrieved and saved in the return record. Illustratively, a time of run-away record corresponds to a continuous segment of distributed ID, called a sequence List. Because the IDs are consumed in ascending order, the maximum ID value maxUseId already used in the sequence list (i.e., the target distributed ID described above) is checked against the traffic table. The value after maxuseid+1 is unused, maxuseid+1 is updated to the start value field of the sequence usage record corresponding to the out of control record, and the state is changed to the return state for subsequent use.

And step A204, deleting the return record if the distributed ID larger than the target distributed ID does not exist in the cache record.

In this embodiment, if it is detected that there is no distributed ID greater than the target distributed ID in the cache record, the current return record is deleted, so when the application instance is restarted, it may be detected that there is no return record in the preset record table, which indicates that there is no sequence loss when the last application instance is terminated.

Further, in a possible embodiment, the distributed ID generation method of the present application further includes steps B10 to B20:

and step B10, detecting whether a second distributed ID to be consumed exists in the cache queue under the condition that the application instance is gracefully terminated.

Upon graceful termination of an application instance, the application instance may perform some specific steps at shutdown to avoid data loss. In the present embodiment, in the case where the application instance gracefully terminates, it is detected whether or not there is a distributed ID to be consumed (hereinafter referred to as a second distributed ID to show distinction) in the cache queue.

And step B20, if the existence of the second distributed ID in the cache queue is detected, updating the return record based on the second distributed ID.

In this embodiment, if it is detected that there is a second distributed ID to be consumed in the current cache queue, the return record is updated based on the second distributed ID, the start value of the return record is updated to be the minimum value in the second distributed ID, and the end value of the return record is updated to be the maximum value in the second distributed ID.

And step B30, deleting the return record if the fact that the second distributed ID does not exist in the cache queue is detected.

In this embodiment, if it is detected that the second distributed ID to be consumed is still present in the current cache queue, the current return record is deleted, so when the application instance is restarted, it may be detected that there is no return record in the preset record table, which indicates that there is no sequence loss when the last application instance is terminated.

In a specific embodiment, a sequence service object (the sequence service object is the sequence service) is responsible for caching and consuming a sequence, and the destroying lifecycle Spring IOC (Inversion of control, control inversion) of the object updates an ID that is not used in a memory to a sequence usage record table, and changes a state of a corresponding record to a return state. And if the cache is used up, deleting the corresponding return record.

The distributed ID generation method supports self-defined prefix and length, is suitable for a distributed system, allocates a prefix to each subsystem or the sub-library application, independently generates continuous sequence IDs by the subsystem or the sub-library application, automatically recovers abandoned sequence numbers, can avoid single-point faults to affect the overall situation, and can improve performance. Specifically, the implementation thinking of the application is that a format of a self-defined sequence ID is applied, a one-bit ID prefix and an n-bit length can be configured, and a subsystem is applied to independently generate a continuous sequence ID and automatically recover a waste sequence number; when the application consumes the serial ID, a section of continuous ID is loaded into the cache, and the serial ID is consumed according to the ascending order. Registering the current ID use condition of each service table in the sequence configuration table; when the application stops gracefully, the unused cache is updated to the sequence usage record table. When the next application is started, the ID of the sequence use record table is loaded to a cache preferentially; the application may cause a loss of application cache sequence when the application is forcibly terminated. The background thread can check the record of the sequence using record table in a runaway state at regular time, locate the actually lost ID through the patrol service table, and update the unused ID to the sequence using table for subsequent use.

In this way, when the application instance is detected to be started, whether a return record exists in the preset record table is inquired, wherein the return record contains the distributed ID in the cache queue when the application instance is recently terminated, and when the return record exists in the preset record table, the distributed ID in the return record is added into the cache queue for consumption of the application instance. In this way, compared with the traditional distributed ID generation mode which may cause sequence loss when the application instance is terminated, the method and the device generate the return record containing the distributed ID in the cache queue when the application instance is terminated and store the return record in the preset record table, so that when the application instance is restarted, the lost distributed ID is preferentially retrieved from the return record and added into the cache queue for subsequent use, thereby avoiding sequence loss and further improving the performance of the application instance for generating the ID by using the distributed ID generation strategy.

Further, based on the above-described first embodiment of the distributed ID generation method of the present application, a second embodiment of the distributed ID generation method of the present application is proposed.

In this embodiment, the distributed ID generation method further includes steps C10 to C30:

And step C10, detecting whether the distributed ID to be consumed exists in the cache queue when receiving the ID request triggered by the user.

In this embodiment, the user may initiate a request for obtaining the distributed ID, that is, the ID request, and when receiving the ID request triggered by the user, detect whether the distributed ID to be consumed exists in the cache queue. Because the cache queue is stored in the local memory, the local memory can be accessed at any time to check the cache queue in the running process of the application instance.

And step C20, if the distributed ID to be consumed exists in the cache queue, returning the smallest distributed ID in the cache queue to the user.

In this embodiment, if it is detected that the cache queue has a distributed ID to be consumed, that is, the cache queue is not empty, the smallest distributed ID in the cache queue is returned to the user, so that sequential consumption of the distributed IDs in ascending order is ensured, consistency and continuity of the sequence are further ensured, and performance of the application instance is improved.

And step C30, if the fact that the distributed IDs to be consumed do not exist in the cache queue is detected, acquiring batch distributed IDs from the database corresponding to the application instance to the cache queue based on the ID request, and returning the smallest distributed ID in the cache queue to the user.

In this embodiment, if it is detected that there is no distributed ID to be consumed in the cache queue, a batch of distributed IDs is obtained from a database corresponding to the application instance based on an ID request triggered by the user, the obtained distributed IDs are added to the cache queue, and then the smallest distributed ID in the cache queue is returned to the user.

As shown in fig. 3, an exemplary flow chart of the generation of the distributed IDs is shown, app1 is a service (i.e. an application instance) under the sub-library 1, app2 is a service (i.e. an application instance) under the sub-library 2, app-n is a service under the sub-library n, and each service may obtain the distributed IDs from the respective corresponding sub-library databases in batches to the sequence cache (i.e. the cache queue) for consumption by the sequence service.

Further, in a possible embodiment, the ID request includes a repository number and a sequence name of the application instance, and the step C30 includes steps C301 to C304:

step C301, determining a database corresponding to the application instance based on the database dividing number;

a sequence name corresponds to a service type, where the IDs of each service type are managed independently, and the IDs of the same service type that belong to the application instance (which may be multiple instances) of the same repository are continuous and non-repeatable. The sub-library number is the number of the sub-library where the application instance is located, and each sub-library corresponds to a database, which is also called a sub-library database. When the user initiates an ID request, the sequence name of the current application instance and the database number are used as the ID request to be sent to the application service by the user, so that the database corresponding to the application instance is determined based on the database number by the application service. In a specific embodiment, the corresponding sub-database is searched based on the sub-database number provided by the user.

Step C302, determining a to-be-fetched ID queue corresponding to the sequence name in the database based on the sequence name, wherein the to-be-fetched ID queue comprises a plurality of pre-generated continuous distributed IDs;

in this embodiment, a service type corresponds to a queue to be fetched, where the queue to be fetched is a queue to be fetched including a plurality of continuous distributed IDs generated in advance according to an ascending order, and a sequence name is determined based on the sequence name, where the sequence name corresponds to the queue to be fetched in the database.

Step C303, taking the smallest distributed ID in the ID queue to be fetched as a starting sequence value;

in this embodiment, the smallest distributed ID in the ID queue to be fetched corresponding to the current sequence name is used as the starting sequence value, where the starting sequence value is the smallest value in the distributed IDs to be fetched recorded in the database of the database, so as to ensure that the next fetch starts from the starting sequence value, thereby ensuring sequence consistency.

And step C304, a preset number of continuous third distributed IDs are obtained from the ID queue to be fetched to the cache queue, wherein the minimum value in the third distributed IDs is the initial sequence value.

The preset sequence service obtains the number of distributed IDs from the database of the database, that is, the preset number, in this embodiment, a preset number of consecutive distributed IDs (hereinafter referred to as a third distributed ID to show a distinction) from the ID queue to be obtained corresponding to the current sequence name, and adds the third distributed ID to the cache queue, where the minimum value in the third distributed ID is the starting sequence value.

Illustratively, as shown in the sequence caching flow diagram of fig. 4, a consumer initiates a request sequence ID (i.e., an ID request) containing a sequence name and a repository number of a current application instance to an application service; judging whether a cache (the cache is a distributed ID in a local memory of the cache) exists or not through an application service, namely, whether a cache queue is empty or not; if the cache is detected to be absent, acquiring a lock; judging whether the cache exists again to perform double checking, and avoiding repeated refreshing of the cache (refreshing the cache means obtaining the distributed ID from the database); if the cache is detected to be absent again, sequencing the sequence from the database area to the cache queue in batches based on the sequence name in the user request, and simultaneously updating the sequence value of the sequence control table by the database, wherein the sequence value can be refreshed by deleting the fetched distributed ID; releasing the lock; popping a sequence ID from the cache queue; and after the stack is successfully popped, returning the sequence ID to the user.

It should be noted that, the step of consuming the ID uses a recursive algorithm, so that the failure rate can be reduced maximally in a high concurrency scene; and meanwhile, a synchronous queue data structure is used, so that the linear safety of the concurrent scene is ensured. And refreshing the sequence to the memory, wherein double check locks are adopted to avoid repeated refreshing of the cache. Updating data, preferably using returned sequence and then using unused sequence of configuration table. Pessimistic locks of the database are used to ensure consistency of the database sequences. The detailed flow is as follows: the configuration table state is changed into a locking state; query sequence usage record table: caching the record with the minimum value and the state of return to the memory; if the last step does not exist, updating the current value (current value + total batch) using the sequence value of the configuration table; if the last step uses the sequence value of the configuration table, inserting a record (the start value, the end value and the state are the cache state) into the sequence use record table; the configuration table state changes to a normal state. When the same business of the same application instance is added to the database sequence of the database to be cached in parallel, only one request can be successfully loaded under the control of the double lock, and other requests can directly use the cached sequence; when the database sub-pessimistic lock is used for loading the database sub-sequences into the caches concurrently under the same service scene of a plurality of application instances, the plurality of instances load the database sequence value caches in series through pessimistic lock control.

Further, in a possible embodiment, after said step C30, step D10 is further included:

and D10, deleting the third distributed ID from the ID waiting queue to update the ID waiting queue.

In this embodiment, the third distributed ID is deleted from the ID queue to be fetched, so as to update the ID queue to be fetched, and thus, the smallest distributed ID in the updated ID queue to be fetched is used as the starting sequence value, so as to ensure the consistency and the order of the sequences.

Therefore, when the distributed IDs in the cache queue are preferentially consumed and the cache queue is empty, the sequence is refreshed from the database corresponding to the current application instance to the cache queue for subsequent use, so that the consistency, the order, the data integrity and the traceability of the sequence are ensured, and the performance of the application instance is further improved.

In addition, the embodiment of the application also provides a distributed ID generation device.

Referring to fig. 5, fig. 5 is a schematic functional block diagram of an embodiment of a distributed ID generation device according to the present application, and as shown in fig. 5, the distributed ID generation device according to the present application includes:

the query module 10 is configured to query whether a return record exists in a preset record table when an application instance is detected to be started, where the return record includes a distributed ID in a cache queue when the application instance is recently terminated;

And the return module 20 is configured to add the distributed ID in the return record to the cache queue for consumption by the application instance if the return record exists in the preset record table.

Further, the distributed ID generation device of the present application further includes:

the violent termination module is used for detecting whether a cache record in a preset record table is updated in preset time under the condition that the application instance violent is terminated, wherein the cache record comprises a largest distributed ID and a smallest distributed ID in the cache queue;

and the non-updating module is used for updating or deleting the return record based on the cache record if the cache record is detected not to be updated in the preset time.

Further, the non-updated module is further configured to determine a maximum target distributed ID in the used ID queue based on a service table corresponding to the application instance; judging whether a distributed ID larger than the target distributed ID exists in the cache record or not; if the distributed ID larger than the target distributed ID exists in the cache record, determining the distributed ID larger than the target distributed ID in the cache record as a first unused distributed ID in the cache record, and updating the return record based on the first distributed ID; and if the distributed ID larger than the target distributed ID does not exist in the cache record, deleting the return record.

the graceful termination module is used for detecting whether a second distributed ID to be consumed exists in the cache queue or not under the condition that the application instance is gracefully terminated;

the updating module is used for updating the return record based on the second distributed ID if the second distributed ID exists in the cache queue;

and the deleting module is used for deleting the return record if the second distributed ID does not exist in the cache queue.

the detection module is used for detecting whether the distributed ID to be consumed exists in the cache queue or not when an ID request triggered by a user is received;

the first return module is used for returning the minimum distributed ID in the cache queue to the user if the distributed ID to be consumed exists in the cache queue;

and the second return module is used for acquiring batch distributed IDs from the database corresponding to the application instance to the cache queue based on the ID request if the distributed IDs to be consumed do not exist in the cache queue, and returning the minimum distributed ID in the cache queue to the user.

Further, the ID request includes a database number and a sequence name of the application instance, and the second return module is further configured to determine a database corresponding to the application instance based on the database number; determining an ID queue to be fetched corresponding to the sequence name in the database based on the sequence name, wherein the ID queue to be fetched comprises a plurality of continuous distributed IDs which are generated in advance; taking the smallest distributed ID in the ID queue to be fetched as an initial sequence value; and obtaining a preset number of continuous third distributed IDs from the ID queue to be fetched to the cache queue, wherein the minimum value in the third distributed IDs is the initial sequence value.

and the queue updating module is used for deleting the third distributed ID from the ID waiting queue to update the ID waiting queue.

The present application also provides a computer storage medium having stored thereon a distributed ID generation program which, when executed by a processor, implements the steps of the distributed ID generation program method according to any one of the embodiments above.

The specific embodiments of the computer storage medium of the present application are substantially the same as the embodiments of the distributed ID generation program method of the present application, and are not described herein.

The present application further provides a computer program product comprising a computer program which, when executed by a processor, implements the steps of the distributed ID generation method of the present application as described in any of the above embodiments, which is not described herein in detail.

It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or system. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or system that comprises the element.

The foregoing embodiment numbers of the present application are merely for describing, and do not represent advantages or disadvantages of the embodiments.

From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) as described above, comprising several instructions for causing a distributed ID generating device (which may be a TWS headset or the like) to perform the method described in the various embodiments of the present application.

The foregoing description is only of the preferred embodiments of the present application, and is not intended to limit the scope of the claims, and all equivalent structures or equivalent processes using the descriptions and drawings of the present application, or direct or indirect application in other related technical fields are included in the scope of the claims of the present application.

Claims

1. A distributed ID generation method, characterized in that the distributed ID generation method comprises the steps of:

2. The distributed ID generation method of claim 1, wherein the method further comprises:

3. The distributed ID generation method of claim 2, wherein the step of updating or deleting the return record based on the cache record comprises:

4. The distributed ID generation method of claim 1, wherein the method further comprises:

5. The distributed ID generation method of claim 1, wherein the method further comprises:

6. The method of claim 5, wherein the ID request includes a repository number and a sequence name of the application instance, and the step of obtaining, based on the ID request, a batch of distributed IDs from a database corresponding to the application instance to the cache queue includes:

7. The method of claim 6, wherein after the step of obtaining, based on the ID request, a batch of distributed IDs from the database corresponding to the application instance to the cache queue, the method further comprises:

8. A distributed ID generation apparatus, characterized in that the distributed ID generation apparatus comprises the steps of:

9. A distributed ID generating device, characterized in that the distributed ID generating device comprises: a memory, a processor storing a distributed ID generation program executable on the processor, the distributed ID generation program when executed by the processor implementing the steps of the distributed ID generation method of any of claims 1 to 7.

10. A computer-readable storage medium, characterized in that the computer-readable storage medium has stored thereon a distributed ID generation program which, when executed by a processor, implements the steps of the distributed ID generation method according to any one of claims 1 to 7.