Method for realizing distributed id

Abstract

The invention belongs to the technical field of distributed systems, and discloses a method for realizing a distributed id (identity), which comprises the following specific steps: step 1, a client needs to apply for a corresponding service line identifier and a token for calling an interface before using the distributed id, and a server adds a corresponding record in a database table after receiving the application of the client; and 2, after the application is passed, the client calls an interface by using a business line represented by the client. According to the innovative mechanism for generating the distributed id, visibility between threads is achieved by using a current fragment object and a next fragment object which are modified by using a volatile, and the safety of the threads is ensured by using ConcurrentHashMap to store data and using a synchronized lock; the use of the next fragment object and the memory is preloaded, so that the id obtaining speed is effectively improved; third-party software is not used for implementation, and the situation that the distributed id cannot be obtained due to errors of a third party is avoided. And the bizType, the step length and the remainder are configured and stored in the form of a database table, so that the requirement of obtaining the customized interval id is met.

Description

Technical Field

[0001] The present invention belongs to the technical field of distributed systems, and in particular relates to a method for implementing a distributed ID. Background Art

[0002] A distributed ID generator is a tool for generating globally unique identifiers (IDs). It plays an important role in distributed systems. In a distributed environment, unique IDs need to be generated for multiple nodes or services to ensure data consistency and correctness. The use of distributed ID distributors is an indispensable scenario in the current Internet. For example, when multiple instances in a distributed system simultaneously create products or SKU numbers or are divided into tables, a unique product ID is required. This ID needs to be generated efficiently and quickly, which requires the implementation of an efficient and fast distributed ID distributor according to our needs.

[0003] One of the existing technical solutions is the snowflake algorithm, which uses the timestamp, machine ID, and serial number in a certain order to get a unique snowflake ID. The snowflake algorithm is a simple and effective distributed ID generator, but it also has some limitations and precautions, such as: the clock dial-back problem: if the system clock is dialed back, the generated ID may be repeated or discontinuous; the other is that UUID contains 32 hexadecimal digits, but it is not easy to store and is not applicable in many scenarios; information is not secure: the algorithm for generating UUID based on MAC address may cause MAC address leakage. This vulnerability was used to find the location of the creator of the Melissa virus. When ID is used as the primary key, there will be some problems in specific environments. For example, in the scenario of DB primary key, UUID is very unsuitable. Summary of the invention

[0004] The purpose of the present invention is to provide a method for implementing a distributed ID to solve the problems raised in the above background technology.

[0005] In order to achieve the above object, the present invention provides the following technical solution: a method for implementing a distributed ID, the specific steps are as follows:

[0006] Step 1:

[0007] Before using the distribution ID, the client needs to apply for the corresponding business line ID and the token for calling the interface. After receiving the client's application, the server adds the corresponding record to the database table.

[0008] Step 2:

[0009] After the application is approved, the client uses the business line it represents to call the interface. The server determines whether the interface caller has the authority to call the interface. If it has the authority to call the interface, it will call to obtain the ID.

[0010] Step 3:

[0011] Use the client identifier bizType to get the corresponding id distributor from the ConcurrentHashMap in memory. If it exists and is not empty, return it. Otherwise, you need to construct the id distributor.

[0012] Step 4:

[0013] Use a mutex to construct a distributor id. In constructing the distributor, you need to set bizType, load the current fragment object, and then return.

[0014] Step 5:

[0015] During the process of loading the current fragment object, it is necessary to determine whether the current fragment object modified by the volatility keyword is empty. If it is empty or the current fragment object has used the maximum id, if the condition is met, determine whether the next fragment object is empty. If it is not empty, assign the next fragment object to the previous fragment object and assign the next fragment object to be empty. If it is empty, it needs to be queried and loaded from the database.

[0016] Step 6:

[0017] Loading from the database requires querying the database according to bizType to obtain the fragment object corresponding to the next bizType, in which the maxId in the table needs to be updated = maxId + step in the table, version = version + 1, and setting loadingId = maxId + step * 0.2 in the returned object to assemble and return the current fragment object;

[0018] Step 7:

[0019] After returning, execute step 6 in a loop until the current fragment object is not null, then get the required id by using the attribute modified by AtomicLong;

[0020] Step 8:

[0021] Get the returned id and compare it with maxId. If it is greater than maxId, you need to reload the current fragment object and execute step 6.

[0022] Step 9:

[0023] If it is greater than loadingId, the next fragment object is asynchronously loaded, which is the same as step 6. Otherwise, the ID value of the current object is returned, which is the ID to be obtained.

[0024] Step 10:

[0025] Repeat steps 5 to 9 until the id is obtained.

[0026] As a preferred technical solution of the present invention, the relationship table between id and token described in step 1 includes the fields biz_type, begin_id, maxId, step, delta, remainder and version; the id setting table includes the fields biz_type and token (calling interface token value).

[0027] As a preferred technical solution of the present invention, the corresponding record described in step one includes the token required for calling the interface and the id starting value, step size, increment and remainder field required by the client.

[0028] As a preferred technical solution of the present invention, the mutex lock described in step 4 can prevent the same business line from being constructed at the same time.

[0029] As a preferred technical solution of the present invention, the query and loading from the database described in step 5 implements the preloading of the next fragment object.

[0030] As a preferred technical solution of the present invention, if the application described in step 2 is not approved, the process ends directly.

[0031] As a preferred technical solution of the present invention, the ConcurrentHashMap described in step 3 is a thread-safe hash table implementation in the Java collection framework.

[0032] As a preferred technical solution of the present invention, the looping of steps five to nine in step ten ensures the uniqueness of the ID acquisition.

[0033] As a preferred technical solution of the present invention, the client described in step 2 uses the business line represented by itself to call the interface, eliminating the use of third-party software.

[0034] The beneficial effects of the present invention are as follows:

[0035] The invention innovates the mechanism of generating distributed IDs: by using the current fragment object and the next fragment object modified by volatility, visibility between threads can be achieved, and ConcurrentHashMap is used to store data and synchronized locks are used to ensure thread safety; preloading the next fragment object and the use of memory can effectively improve the speed of obtaining IDs; third-party software is not used to avoid the failure to obtain distributed IDs due to third-party errors; the need to obtain customized interval IDs is realized by configuring and storing bizType, step size and remainder in the form of a database table. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] Figure 1 It is the business flow chart of the present invention;

[0037] Figure 2 The database table model of the present invention;

[0038] Figure 3 This is a functional architecture diagram of the present invention. DETAILED DESCRIPTION

[0039] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0040] like Figures 1 to 3 As shown, the embodiment of the present invention provides a method for implementing a distributed ID, and the specific steps are as follows:

[0041] Step 1:

[0042] Before using the distribution ID, the client needs to apply for the corresponding business line ID and the token for calling the interface. After receiving the client's application, the server adds the corresponding record to the database table.

[0043] Step 2:

[0044] After the application is approved, the client uses the business line it represents to call the interface. The server determines whether the interface caller has the authority to call the interface. If it has the authority to call the interface, it will call to obtain the ID.

[0045] Step 3:

[0046] Use the client identifier bizType to get the corresponding id distributor from the ConcurrentHashMap in memory. If it exists and is not empty, return it. Otherwise, you need to construct the id distributor.

[0047] Step 4:

[0048] Use a mutex to construct a distributor id. In constructing the distributor, you need to set bizType, load the current fragment object, and then return.

[0049] Step 5:

[0050] During the process of loading the current fragment object, it is necessary to determine whether the current fragment object modified by the volatility keyword is empty. If it is empty or the current fragment object has used the maximum id, if the condition is met, determine whether the next fragment object is empty. If it is not empty, assign the next fragment object to the previous fragment object and assign the next fragment object to be empty. If it is empty, it needs to be queried and loaded from the database.

[0051] Step 6:

[0052] Loading from the database requires querying the database according to bizType to obtain the fragment object corresponding to the next bizType, in which the maxId in the table needs to be updated = maxId + step in the table, version = version + 1, and setting loadingId = maxId + step * 0.2 in the returned object to assemble and return the current fragment object;

[0053] Step 7:

[0054] After returning, execute step 6 in a loop until the current fragment object is not null, then get the required id by using the attribute modified by AtomicLong;

[0055] Step 8:

[0056] Get the returned id and compare it with maxId. If it is greater than maxId, you need to reload the current fragment object and execute step 6.

[0057] Step 9:

[0058] If it is greater than loadingId, the next fragment object is asynchronously loaded, which is the same as step 6. Otherwise, the ID value of the current object is returned, which is the ID to be obtained.

[0059] Step 10:

[0060] Repeat steps 5 to 9 until the id is obtained.

[0061] This method uses the current fragment object and the next fragment object modified by volatility, uses the thread-safe ConcurrentHashMap to store data and synchronized locks to ensure thread safety, and uses the database table to configure the storage bizType to meet the needs of obtaining customized interval IDs. At the same time, there is no need to use third-party software, thereby improving information security and being applicable to a variety of scenarios. It will not cause the generated IDs to be repeated or discontinuous, and the efficiency of ID acquisition is improved.

[0062] The relationship table between id and token in step 1 contains the fields biz_type, begin_id, maxId, step, delta, remainder and version; the id setting table contains the fields biz_type and token (calling interface token value).

[0063] In the relationship table between id and token, biz_type indicates the business type identifier, begin_id indicates the start id, records the initial value, maxId indicates the current maximum id, step indicates the step length, delta indicates each id increment, remainder indicates the remainder, and version indicates the version number. In the id setting table, biz_type indicates the business type identifier, and token indicates the calling interface token value.

[0064] The corresponding record in step 1 contains the token required to call the interface and the ID starting value, step size, increment and remainder fields required by the client.

[0065] The addition of corresponding records in the database table provides a data basis for the subsequent processes.

[0066] Among them, the mutex lock in step 4 can prevent the same business line from being constructed at the same time.

[0067] The use of mutex locks can prevent the same business line from being constructed at the same time, thus preventing construction errors.

[0068] The query and loading from the database in step 5 realizes the preloading of the next fragment object.

[0069] By preloading the next section of objects, the speed of obtaining the ID can be effectively improved.

[0070] If the application in step 2 is not approved, the process ends directly.

[0071] If the application is not approved, it means that the corresponding record in the database table has failed to be added. In this case, you need to modify the token value of the calling interface and reapply.

[0072] Among them, ConcurrentHashMap in step 3 is a thread-safe hash table implementation in the Java collection framework.

[0073] ConcurrentHashMap provides efficient concurrent read and write operations, enabling high-performance concurrent access.

[0074] Among them, the loop from step five to step nine in step ten ensures the uniqueness of the ID obtained.

[0075] In a distributed system, data may be distributed across multiple servers, databases, and data tables, and the globally unique identification of data items must be guaranteed.

[0076] Among them, the client in step 2 uses the business line represented by itself to call the interface, eliminating the use of third-party software.

[0077] Eliminating the use of third-party software can effectively avoid the situation where the distributed ID cannot be obtained due to errors made by the third party.

[0078] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0079] Although embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes, modifications, substitutions and variations may be made to the embodiments without departing from the principles and spirit of the present invention, and that the scope of the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for implementing a distributed ID, characterized in that: The specific steps are as follows: Step 1: Before using the distribution ID, the client needs to apply for the corresponding business line ID and the token for calling the interface. After receiving the client's application, the server adds the corresponding record to the database table. Step 2: After the application is approved, the client uses the business line it represents to call the interface. The server determines whether the interface caller has the authority to call the interface. If it has the authority to call the interface, it will call to obtain the ID. Step 3: Use the client identifier bizType to get the corresponding id distributor from the ConcurrentHashMap in memory. If it exists and is not empty, return it. Otherwise, you need to construct the id distributor. Step 4: Use a mutex to construct a distributor id. In constructing the distributor, you need to set bizType, load the current fragment object, and then return. Step 5: During the process of loading the current fragment object, it is necessary to determine whether the current fragment object modified by the volatile keyword is empty. If it is empty or the current fragment object has used the maximum id, if the condition is met, determine whether the next fragment object is empty. If it is not empty, assign the next fragment object to the previous fragment object and assign the next fragment object to be empty. If it is empty, it needs to be loaded from the database query; Step 6: Loading from the database requires querying the database according to bizType to obtain the fragment object corresponding to the next bizType, in which the maxId in the table needs to be updated to be maxId+step in the table, version=version+1, and setting loadingId=maxId+step*0.2 in the returned object to assemble and return the current fragment object; Step 7: After returning, execute step 6 in a loop until the current fragment object is not null, then get the required id by using the attribute modified by AtomicLong; Step 8: Get the returned id and compare it with maxId. If it is greater than maxId, you need to reload the current fragment object and execute step 6. Step 9: If it is greater than loadingId, the next fragment object is asynchronously loaded, which is the same as step 6. Otherwise, the ID value of the current object is returned, which is the ID to be obtained. Step 10: Repeat steps 5 to 9 until the id is obtained.

2. A method for implementing a distributed ID according to claim 1, characterized in that: The relationship table between id and token described in step 1 includes the fields biz_type, begin_id, maxId, step, delta, remainder and version; the id setting table includes the fields biz_type and token (calling interface token value).

3. A method for implementing a distributed ID according to claim 1, characterized in that: The corresponding record described in step 1 contains the token required to call the interface and the id starting value, step, increment and remainder fields required by the client.

4. A method for implementing a distributed ID according to claim 1, characterized in that: The mutex lock described in step 4 prevents the same business line from being constructed at the same time.

5. A method for implementing a distributed ID according to claim 1, characterized in that: The loading from the database query described in step 5 is to realize the preloading of the next fragment object.

6. A method for implementing a distributed ID according to claim 1, characterized in that: If the application described in step 2 is not approved, the process ends directly.

7. A method for implementing a distributed ID according to claim 1, characterized in that: The ConcurrentHashMap described in step 3 is a thread-safe hash table implementation in the Java collection framework.

8. A method for implementing a distributed ID according to claim 1, characterized in that: The loop from step 5 to step 9 described in step 10 ensures the uniqueness of the ID obtained.

9. A method for implementing a distributed ID according to claim 1, characterized in that: The client described in step 2 uses the business line represented by itself to call the interface, eliminating the use of third-party software.

Images