Business processing method, device and equipment for auto-increment column in distributed database

Abstract

The embodiments of this specification disclose a business processing method, device and equipment for auto-increment columns in a distributed database, which are applied to nodes of a distributed database and belong to the field of database technology. The scheme includes: obtaining multiple unused identifiers of the auto-increment column to form an auto-increment column identifier set, and caching the auto-increment column identifier set locally; when it is necessary to add a new record row in the data table corresponding to the auto-increment column, obtain an unused identifier in the auto-increment column identifier set cached locally, and use it as the key value belonging to the auto-increment column in the newly added record row; detect whether the used identifier part in the auto-increment column identifier set cached locally has reached a predetermined level, and under the predetermined level, a part of unused identifiers still remain in the auto-increment column identifier set; if so, incrementally obtain multiple unused identifiers of the auto-increment column and add them to the auto-increment column identifier set cached locally.

Description

Technical Field

[0001] The present invention relates to the field of database technology, and in particular to a method, device and equipment for business processing of auto-increment columns in a distributed database. Background Art

[0002] If the key value of a column in the database needs to be a sequence of ordered identifiers (usually positive integers), an auto-increment column is used. An auto-increment column is a special column in a data table. The key value of this column can be automatically generated by the database server. For example, if a positive integer is used as the identifier of an auto-increment column, the auto-increment column is a sequence of positive integers that grows in ascending order. An auto-increment column can be used to generate a unique identifier for a new row in a data table.

[0003] In a distributed database, there are many working nodes, and many working nodes need to use the same auto-increment column to insert new data records (i.e., record rows) into the corresponding data table. Specifically, when these working nodes want to insert the new record row, they will request the system to obtain an unused identifier of the auto-increment column, and use the identifier as one of the key values ​​of the record row. Since the identifier is unique in the auto-increment column, the identifier can also be used as the primary key value of the record row.

[0004] However, in a distributed database scenario, too many work nodes' requests for auto-increment column identifiers (i.e., the identifiers of auto-increment columns) cause normal query requests to be delayed. Especially in the case of network jitter, the delay in requests for auto-increment column identifiers becomes higher, causing normal query requests to be delayed more seriously. Not only that, these requests for auto-increment column identifiers themselves may also cause network jitter.

[0005] Based on this, in a distributed database scenario, an auto-increment column identification processing solution that is more friendly to system efficiency is needed. Summary of the invention

[0006] One or more embodiments of the present specification provide a business processing method, apparatus, device and storage medium for auto-increment columns in a distributed database to solve the following technical problems: In a distributed database scenario, a more system-efficient auto-increment column identification processing solution is required.

[0007] To solve the above technical problems, one or more embodiments of this specification are implemented as follows:

[0008] One or more embodiments of this specification provide a business processing method for an auto-increment column in a distributed database, which is applied to a node of the distributed database. The method includes:

[0009] Acquire multiple unused identifiers of the auto-increment column to form an auto-increment column identifier set, and cache the auto-increment column identifier set locally;

[0010] When a new record row needs to be added to the data table corresponding to the auto-increment column, an unused identifier is obtained from the auto-increment column identifier set cached locally, and used as a key value belonging to the auto-increment column in the newly added record row;

[0011] Detecting whether the portion of used identifiers in the locally cached auto-increment column identifier set has reached a predetermined level, where a portion of unused identifiers still remain in the auto-increment column identifier set;

[0012] If so, multiple unused identifiers of the auto-increment column are incrementally obtained and added to the auto-increment column identifier set cached locally.

[0013] One or more embodiments of this specification provide a business processing device for auto-increment columns in a distributed database, which is applied to a node of the distributed database, and the device includes:

[0014] An initial cache module obtains a plurality of unused identifiers of an auto-increment column to form an auto-increment column identifier set, and caches the auto-increment column identifier set locally;

[0015] An auto-increment column identifier using module, when it is necessary to add a new record row in the data table corresponding to the auto-increment column, obtains an unused identifier from the auto-increment column identifier set cached locally, and uses it as a key value belonging to the auto-increment column in the newly added record row;

[0016] A self-increment column identifier detection module detects whether the portion of used identifiers in the self-increment column identifier set cached locally has reached a predetermined level, and under the predetermined level, a portion of unused identifiers still remains in the self-increment column identifier set;

[0017] The incremental pre-fetch cache module, if so, incrementally obtains multiple unused identifiers of the auto-increment column and adds them to the auto-increment column identifier set cached locally.

[0018] One or more embodiments of this specification provide a business processing device for auto-increment columns in a distributed database, which is applied to a node of the distributed database. The device includes:

[0019] at least one processor; and,

[0020] a memory communicatively connected to the at least one processor; wherein,

[0021] The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0022] Acquire multiple unused identifiers of the auto-increment column to form an auto-increment column identifier set, and cache the auto-increment column identifier set locally;

[0023] When a new record row needs to be added to the data table corresponding to the auto-increment column, an unused identifier is obtained from the auto-increment column identifier set cached locally, and used as a key value belonging to the auto-increment column in the newly added record row;

[0024] Detecting whether the portion of used identifiers in the locally cached auto-increment column identifier set has reached a predetermined level, where a portion of unused identifiers still remain in the auto-increment column identifier set;

[0025] If so, multiple unused identifiers of the auto-increment column are incrementally obtained and added to the auto-increment column identifier set cached locally.

[0026] One or more embodiments of this specification provide a non-volatile computer storage medium, which is applied to a node of the distributed database, wherein the medium stores computer executable instructions, and the computer executable instructions are configured as follows:

[0027] Acquire multiple unused identifiers of the auto-increment column to form an auto-increment column identifier set, and cache the auto-increment column identifier set locally;

[0028] When a new record row needs to be added to the data table corresponding to the auto-increment column, an unused identifier is obtained from the auto-increment column identifier set cached locally, and used as a key value belonging to the auto-increment column in the newly added record row;

[0029] Detecting whether the portion of used identifiers in the locally cached auto-increment column identifier set has reached a predetermined level, where a portion of unused identifiers still remain in the auto-increment column identifier set;

[0030] If so, multiple unused identifiers of the auto-increment column are incrementally obtained and added to the auto-increment column identifier set cached locally.

[0031] At least one of the above-mentioned technical solutions adopted in one or more embodiments of the present specification can achieve the following beneficial effects: the nodes of the distributed database no longer need to request the self-increment column identifier in real time, but pre-acquire a sufficient amount of self-increment column identifiers in stages and cache them locally. When they are needed, they can be directly retrieved from the local cache. Not only that, the consumption of the self-increment column identifiers in the local cache will be detected. When there is still a surplus, some more self-increment column identifiers will be incrementally acquired and added to the local cache. Through this smooth pre-fetching method, the self-increment column identifiers in the local cache are above the surplus safety line, so there is no need to request the self-increment column identifier in real time, which greatly reduces the request frequency and urgency of the self-increment column identifiers in the entire system, helps to better cope with scenarios that are not friendly to system efficiency, such as high concurrency and network jitter, and can minimize the impact on normal query requests. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0033] Figure 1 A flowchart of a business processing method for auto-increment columns in a distributed database provided by one or more embodiments of this specification;

[0034] Figure 2 In an application scenario provided by one or more embodiments of this specification, Figure 1 Schematic diagram of the smooth prefetching concept in the method;

[0035] Figure 3 A schematic diagram of a process flow of cooperation between nodes in a distributed database for auto-increment column identification in an application scenario provided by one or more embodiments of this specification;

[0036] Figure 4 A schematic diagram of the structure of a business processing device for self-incrementing columns in a distributed database provided by one or more embodiments of this specification;

[0037] Figure 5 A schematic diagram of the structure of a business processing device for auto-increment columns in a distributed database provided by one or more embodiments of this specification. DETAILED DESCRIPTION

[0038] The embodiments of the present specification provide a business processing method, apparatus, device and storage medium for auto-increment columns in a distributed database.

[0039] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this application, not all of them. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this application.

[0040] This solution is applied to distributed databases. Through pre-fetch operations, a local cache of auto-increment column identifiers is constructed. The local cache can be further refreshed and supplemented smoothly, effectively reducing the impact of the use of auto-increment column identifiers on normal query requests. Not only that, it also collaborates and helps each other between nodes with the same needs, converges individual impacts, and reduces the overall management cost of the system, thereby helping to eliminate delays and network jitter, especially in systems with strict requirements for high concurrency and low latency.

[0041] Based on this concept, it is further described in detail below.

[0042] Figure 1 A flow chart of a business processing method for self-incrementing columns in a distributed database provided for one or more embodiments of this specification, the distributed database has multiple nodes, and the method can be specifically applied to the nodes therein. The method can be applied to different business fields, such as e-commerce business field, financial business field, electronic payment business field, instant messaging business field, robot business field, video service business field, game business field, official business field, etc. The process can be executed by a computing device in the corresponding field (for example, a node device of a distributed database corresponding to an e-commerce business, etc.), and some input parameters or intermediate results in the process allow manual intervention and adjustment to help improve accuracy.

[0043] Figure 1 The process in may include the following steps:

[0044] S102: Acquire multiple unused identifiers of the auto-increment column to form an auto-increment column identifier set, and cache the auto-increment column identifier set locally.

[0045] Generally, the identifier of an auto-increment column is a positive integer serial number, starting from 1 and increasing in number, including 1, 2, 3, ..., N, etc. Each serial number is an identifier of the auto-increment column, and can continue to increase if necessary. In a database, different identifiers of auto-increment columns are often used to distinguish different record rows. For example, in a certain data table, the identifier of the auto-increment column is used as the primary key value of the record row in the data table. Then, for each new record row in the data table, an unused identifier of the auto-increment column needs to be used. In the data table, each identifier of the auto-increment column is unique.

[0046] In one or more embodiments of this specification, if multiple nodes of a distributed database all have the need to use an auto-increment column identifier, they can each execute Figure 1 In the process, for the convenience of description, some of the following embodiments are explained from the perspective of one of the nodes, and the node is referred to as this node. At the beginning, when there is no self-increment column identifier on this node, this node can execute step S102 once, obtain a batch of available self-increment column identifiers, cache them locally, and then no longer execute step S102. Instead, it can be incrementally supplemented in a timely manner based on the existing identifiers through subsequent steps. Based on this, this node can execute step S102 in advance at a reasonable time. Reasonable times include, for example, when the system query burden is relatively low and there are relatively many idle resources, so as to avoid affecting the normal service of the database.

[0047] S104: When a new record row needs to be added in the data table corresponding to the auto-increment column, an unused identifier is obtained from the auto-increment column identifier set cached locally, and used as a key value belonging to the auto-increment column in the newly added record row.

[0048] After an unused auto-increment column identifier is used, it is generally not reused in the same data table. However, there are special cases. For example, if the record row to which an auto-increment column identifier belongs is deleted, you can consider reusing the auto-increment column identifier as an unused identifier for reuse.

[0049] Since nodes can directly use the auto-increment column identifier in the local cache, there is no need to request the auto-increment column identifier from the outside in real time (for example, a service node specified by the distributed database, etc.). Furthermore, it can also prevent many nodes from frequently requesting the auto-increment column identifier from the outside at the same time, which will squeeze resources and increase the delay of the entire system.

[0050] S106: Detect whether the portion of used identifiers in the locally cached auto-increment column identifier set has reached a predetermined level, and if the predetermined level is reached, a portion of unused identifiers still remains in the auto-increment column identifier set.

[0051] In actual applications, when a node obtains the self-incrementing column identifier, there is a certain amount of communication overhead. After the local cache identifier is used up, it can block and fetch the next cache segment, that is, fetch new identifiers from the outside of the node. Obviously, such fetching of the next cache segment is also urgent. In the high-concurrency scenario of the node, it may cause multiple normal query requests to be blocked, and the corresponding overhead aggravates the delay. In this case, the user side will feel a large-scale request delay and observe severe network jitter.

[0052] In order to avoid the situation in the previous paragraph, on the basis of pre-fetching the self-increment column identifier cache, we further replenish the existing cached identifiers in advance, rather than waiting for the cached identifiers to be exhausted before obtaining new ones, thereby reducing the urgency and being able to automatically refresh the existing cache more smoothly to continuously meet the demand for the use of self-increment column identifiers, and helping to avoid overly concentrated bursts of requests and re-requests from multiple nodes.

[0053] In one or more embodiments of the present specification, the used identification portion, that is, the portion composed of used self-increment column identifications, can be measured in the form of specific quantity, proportion, etc. When detecting whether the used identification portion has reached a predetermined level, it can be specifically detected whether the used identification portion has reached a predetermined used level, or it can be detected whether the unused identification portion in the self-increment column identification set has been reduced to a predetermined unused level, and so on, as long as the required conclusion can be obtained directly or indirectly. The idea is to pay attention to the usage of the locally cached self-increment column identification in a timely manner. If it has been used to a certain extent and has not been used up, prepare in advance to supplement new self-increment column identifications to be prepared and avoid being passive.

[0054] Furthermore, the number or proportion of unused identifiers in the auto-increment identifier set should not be too low, otherwise, there may be a risk that the remaining part will be exhausted before new identifiers are added. For example, for the initially acquired auto-increment identifier set, when it is detected that three-quarters of the identifiers have been used (which can be set according to actual conditions), the subsequent step of adding new identifiers can be triggered.

[0055] In one or more embodiments of the present specification, the degree of need for each node to use the self-incrementing column identifier is different, and the specific usage is also different. Therefore, it is considered to set the above predetermined degree in a personalized manner. Even for the same node, the situation of using the self-incrementing column identifier may vary. Based on this, the predetermined degree is set not only in a personalized but also dynamically.

[0056] According to the previous description, the predetermined degree determines how many unused identifiers are left in the local cache when preparing to incrementally obtain new identifiers in advance. In order to make these identifiers play an effective buffering role, and not to have too many remaining and cause premature replenishment of identifiers, for example, the predetermined degree can be dynamically set according to the consumption speed of the unused identifiers in the local cache, and the actual consumption speed can be recorded. If the consumption speed is relatively high, it means that it is necessary to replenish in advance when there are relatively more remaining. On the contrary, if the consumption speed is relatively low, it means that it may be in time to replenish in advance when there are relatively few remaining. Based on this, according to test results or experience, the consumption speed and the predetermined degree (the predetermined degree and the remaining degree are negatively correlated) can be set to a suitable negative correlation. Then, according to the negative correlation, the predetermined degree is dynamically set. For example, if the consumption speed increases, the predetermined degree is correspondingly lowered, so that replenishment is triggered when there are more remaining, which is more relaxed and reliable.

[0057] S108: If yes, then incrementally obtain multiple unused identifiers of the auto-increment column and add them to the auto-increment column identifier set cached locally.

[0058] In one or more embodiments of the present specification, the node may incrementally obtain unused auto-increment column identifiers in advance at a reasonable time to replenish the local cache in a timely manner.

[0059] More intuitively, one or more embodiments of this specification provide an application scenario in which: Figure 1 A schematic diagram of the smooth prefetching concept in the method, such as Figure 2 shown.

[0060] exist Figure 2 In the example, assuming that there are already 1 million to 2 million unused identifiers (black plus white parts) on this node, its identifier usage can be monitored. When the usage reaches the predetermined level, assuming that the right boundary of the black part indicates that the predetermined level has been reached (assuming it is three quarters), only the white part remains unused, totaling 500,000. At this time, the pre-fetch action is triggered. Through pre-fetching, the 2 million to 3 million unused identifiers, totaling 1 million, are incrementally obtained and added to the local cache. There are currently 1.5 million unused identifiers in the local cache. It should be noted that since other nodes also need to obtain identifiers, in actual applications, the 1 million identifiers incrementally obtained by this node may not be connected to the identifier serial number obtained previously.

[0061] pass Figure 1By using the method, the nodes of the distributed database no longer need to request the auto-increment column identifier in real time, but pre-acquire a sufficient amount of auto-increment column identifiers in stages and cache them locally. When they are needed, they can be directly retrieved from the local cache. In addition, the consumption of the auto-increment column identifiers in the local cache is detected. When there is still a surplus, some more auto-increment column identifiers are incrementally acquired and added to the local cache. Through this smooth pre-fetching method, the auto-increment column identifiers in the local cache are above the surplus safety line, so there is no need to request the auto-increment column identifier in real time, which greatly reduces the request frequency and urgency of the auto-increment column identifiers in the entire system, helps to better cope with scenarios that are not friendly to system efficiency, such as high concurrency and network jitter, and can minimize the impact on normal query requests.

[0062] based on Figure 1 This specification also provides some specific implementation plans and extension plans of the method, which will be described below.

[0063] In one or more embodiments of the present specification, in order to reduce the burden on the system, normal query requests are used to detect the local cache. In this way, timeliness is good and the query request capability can be effectively utilized. The reason is that, on the one hand, there are relatively many query requests, and if there is a cache with a self-incrementing column identifier locally, the relevant data in the cache can be seen during the execution of the query request, such as the current identifier to be retrieved, etc., and these relevant data can be effectively and efficiently implemented in the detection, thereby killing two birds with one stone and reducing the implementation cost of the solution. Furthermore, in terms of the above-mentioned detection, the use of query requests can be selective. For example, only a portion of query requests with relatively low priority are used to trigger the detection process.

[0064] In actual detection, when a query request is received, the current identifier to be used corresponding to the locally cached auto-increment column identifier set can be obtained according to the query request, and according to the current identifier to be used, it is determined whether the used identifier portion in the locally cached auto-increment column identifier set has reached a predetermined level. The current identifier to be used is, for example, one or more identifiers that will be currently used preferentially among the unused identifiers remaining in the cache.

[0065] In a specific detection implementation method, the current identifier to be used (assuming that the identifiers are all in the form of positive integer serial numbers) is recorded as current, and the starting serial number of the identifier in the self-increment column identifier set cached at the time of initialization is pre-obtained, recorded as start, and the ending serial number is recorded as end. Assuming that it is necessary to determine whether the used identifier portion in the locally cached self-increment column identifier set has reached three quarters, the following formula can be used for calculation: end-current<=(end-start) / 4. If the calculation result is yes, it means that the remaining usable identifier portion does not exceed one quarter, then it is determined that the used identifier portion has reached three quarters.

[0066] In one or more embodiments of the present specification, a synchronous cache prefetch request is used to incrementally obtain identification. This method has low implementation cost and high reliability. However, if, as in some of the previous embodiments, a query request is used for detection and incremental acquisition, the query request needs to wait for the execution result of the cache prefetch request. Taking this into account, in order to minimize interference with the query request, a sufficiently short (for example, 10ms, etc., which can be set according to actual tolerance) timeout time can be set for the cache prefetch request as a safety timeout time. The type of cache prefetch request is, for example, an RPC request or an SQL request.

[0067] In this way, based on the idea of ​​the previous paragraph, after detecting whether the used identifier part in the self-increment column identifier set in the local cache has reached a predetermined level, if so, generate the above-mentioned synchronized cache prefetch request, and set a sufficiently short safety timeout time for the synchronized cache prefetch request. According to the synchronized cache prefetch request, try to incrementally obtain multiple unused identifiers of the self-increment column, and block the execution of the query operation corresponding to the query request. If the actual timeout time of the cache prefetch request is greater than the safety timeout time, continue to execute the query operation, thereby delaying the query operation by at most the safety timeout time. If the actual timeout time is not greater than the safety timeout time, then continue to wait for the requested party to respond.

[0068] It can be seen that the above synchronous request will still have a certain adverse effect on the query request, so it is also possible to consider switching to an asynchronous cache pre-fetch request. Based on this, after detecting whether the used identifier portion of the auto-increment column identifier set in the local cache has reached a predetermined level, if so, an asynchronous cache pre-fetch request is generated, and according to the asynchronous cache pre-fetch request, an attempt is made to incrementally obtain multiple unused identifiers of the auto-increment column. In this case, even if network jitter occurs, it will not have an adverse effect on the delay of the query request.

[0069] Regardless of whether synchronous or asynchronous requests are used, the entire system should consider reducing the number of concurrent cache prefetch requests as much as possible and preventing unnecessary conflicts. For any query request participating in this solution, before it generates a cache prefetch request, it can be determined whether it is currently trying to incrementally obtain multiple unused identifiers of the self-increment column based on another query request (the judgment can be made for a local range, such as on the current node). If the result of the judgment is no, cache prefetching will continue. If the result of the judgment is yes, cache prefetching request may not be generated, but query operation may be directly executed, that is, continue to do what it should do and give up prefetching. Therefore, for the current node, it helps to avoid multiple query requests trying to prefetch for the current node, avoiding conflicts and waste of resources.

[0070] In actual applications, for auto-increment columns, if only one node performs data insertion operations, the node can obtain auto-increment column identifiers with continuous serial numbers and can use the corresponding identifiers in sequence according to the serial number order. This usage method provides a very consistent experience for both data owners and data users. In the data table, each record row is naturally added and arranged in sequence according to the serial number order. There is no need to spend additional resources to organize the data, and the data exists continuously as a whole block. For example, if the 100th auto-increment column identifier has been used recently, it can be almost certain that the data rows corresponding to the numbers before 100 exist and are in place, and can be read as needed. However, for distributed databases, according to the previous description, many nodes need to use auto-increment column identifiers, and they will pre-fetch unused identifiers and cache them locally for their own use. In this case, although the identifiers are used in sequence on each node, from a global perspective of multiple nodes, the disordered use of identifiers may be very frequent. For example, a node is assigned identifiers 1 to 100 and another node is assigned identifiers 101 to 200. Assuming that the current node is using identifier No. 50, the other node may be using identifier No. 130. In this case, at least identifiers No. 51 to 100 will be used after identifier No. 130 or even larger identifiers, resulting in disorder, which may cause trouble for data management and use.

[0071] In view of the situation in the previous paragraph, this solution considers that in a distributed database, when initially pre-fetching the self-incrementing column identifier and the subsequent incremental expected identifier, different nodes should cooperate with each other to coordinate the identifiers, so that the global identifiers can be used as much as possible in the original sequence or close to the original sequence, so that the self-incrementing column can work in the distributed database in the ideal way of "sequential self-increment and sequential use". Here is an exemplary implementation idea. For example, before a node incrementally obtains an identifier, it can first try to obtain an identifier with a sequence number closer to the sequence number it used before from another node. From a global perspective, it helps to use up the identifiers with relatively early sequence numbers more timely and fully. For another example, different nodes can cooperate, and some of their representatives can replace everyone's later identifiers, and then reasonably distribute them, which not only helps the order, but also helps to reduce the overall request volume of the system.

[0072] According to the idea in the previous paragraph, one or more embodiments of this specification provide a schematic flow chart of the coordination between nodes in a distributed database for auto-increment column identifiers in an application scenario, such as Figure 3 shown.

[0073] exist Figure 3 In the scenario, a predetermined node in the distributed database holds all the auto-increment column identifiers. For the sake of distinction, this node is called a service node, and other nodes that need to obtain and use the auto-increment column identifiers are called working nodes. Figure 3 The optional steps of the incremental acquisition phase are listed as examples.

[0074] Figure 3 The process in may include the following steps:

[0075] S302: Query the service node for another working node that has been assigned an identifier that is close to the sequence number of the self-incrementing identifier set.

[0076] In one or more embodiments of the present specification, when the self-incremental column identifier is initially pre-fetched, each node is assigned a continuous identifier, for example, and the identifier segments of some nodes are far apart from each other, while others are close or even adjacent. Another working node that has obtained an adjacent identifier segment can be preferentially queried. If the other working node still has a sufficient number of nodes (for example, it is far from reaching the level where incremental supplementary identifiers are required), the following steps can be executed, otherwise, another more suitable node can be tried to be found for executing the following steps.

[0077] S304: Send an identifier distribution request to the other working node, so that the other working node distributes its own cached unused identifiers that are close to the auto-increment identifier set sequence number to the current working node if it agrees to the identifier sharing request.

[0078] If another working node can share the identifier, there is a high probability that the identifier consumption rate of the other working node is lower than that of this node. Then, through such sharing, on the one hand, this node does not need to request new identifiers from the service node temporarily, reducing the pressure on the service node. On the other hand, this node can help consume relatively early but unused identifiers (that is, identifiers that the other working node has not used up). If this node requests the service node, it will obtain relatively later identifiers, which may lead to aggravated disorder of use.

[0079] S306: Cache the identifier distributed by the other working node locally in the self-incrementing identifier set so as to use it in sequence.

[0080] It should be noted that many of the above embodiments mention serial number order, which actually refers to the default order of the auto-increment column identifier (usually in the form of a serial number) in the corresponding auto-increment column. Assuming that the auto-increment column identifier is not in the form of a serial number, then based on the description here, the idea of ​​​​this solution should also be correctly understood.

[0081] S308: Negotiate with the other working node to select one of the current working node and the other working node as a collaborative node for obtaining multiple unused identifiers of the self-increment column from the service node next time.

[0082] In one or more embodiments of the present specification, when the other working node agrees to the identifier sharing request, it means that the rhythm of identifier acquisition and use of the two can be relatively staggered, thus helping to avoid conflicts and facilitate complementary cooperation. In this case, it is particularly possible to consider executing step S308 and related subsequent steps.

[0083] Through node collaboration, multiple nodes are integrated into one node to a certain extent, reducing the number of cache prefetch requests in the entire system. The collaborative node should obtain enough identifiers from the service node to share with itself next time.

[0084] S310: If the current working node is determined to be the collaborative node, after acquiring the multiple unused identifiers of the self-incrementing column from the service node next time, distribute a part of them to the other working node.

[0085] S312: If the current working node is not determined as the collaborative node, continue to receive the identifier distributed by the other working node next time without obtaining the identifier from the service node.

[0086] pass Figure 3In the method, the working nodes do not need to completely rely on the service nodes to obtain the identification, but can largely reduce the interaction requirements with the service nodes through internal collaboration and mutual assistance, which not only improves the efficiency but also alleviates the problem of disordered identification usage.

[0087] Based on the same idea, one or more embodiments of this specification also provide devices and apparatuses corresponding to the above methods, such as Figure 4 , Figure 5 shown.

[0088] Figure 4 A schematic diagram of a business processing device for self-incrementing columns in a distributed database provided in one or more embodiments of this specification, wherein the device is applied to a node of the distributed database, and the device includes:

[0089] The initial cache module 402 obtains a plurality of unused identifiers of the auto-increment column to form an auto-increment column identifier set, and caches the auto-increment column identifier set locally;

[0090] The auto-increment column identifier using module 404, when it is necessary to add a new record row in the data table corresponding to the auto-increment column, obtains an unused identifier in the auto-increment column identifier set cached locally, and uses it as a key value belonging to the auto-increment column in the newly added record row;

[0091] The self-increment column identifier detection module 406 detects whether the portion of used identifiers in the self-increment column identifier set cached locally has reached a predetermined level, and under the predetermined level, a portion of unused identifiers still remain in the self-increment column identifier set;

[0092] The incremental pre-fetch cache module 408, if yes, incrementally obtains multiple unused identifiers of the auto-increment column and adds them to the auto-increment column identifier set cached locally.

[0093] Optionally, when receiving a query request, the self-increment column identifier detection module 406 obtains a current identifier to be used corresponding to the self-increment column identifier set cached locally according to the query request;

[0094] According to the current identifier to be used, it is determined whether the portion of used identifiers in the locally cached auto-increment identifier set has reached a predetermined level.

[0095] Optionally, the self-increment column identifier detection module 406 records the consumption speed of the unused identifiers cached locally;

[0096] The predetermined degree is dynamically set according to the negative correlation relationship set between the consumption speed and the predetermined degree.

[0097] Optionally, the incremental pre-fetch cache module 408, after the self-increment column identifier detection module 406 detects whether the used identifier portion in the self-increment column identifier set cached locally has reached a predetermined level, further executes:

[0098] If yes, generating a synchronous cache pre-fetch request, and setting a sufficiently short safety timeout for the synchronous cache pre-fetch request;

[0099] According to the synchronized cache prefetch request, attempt to incrementally obtain multiple unused identifiers of the auto-increment column, and block execution of a query operation corresponding to the query request;

[0100] If the actual timeout period of the cache pre-fetch request is greater than the safety timeout period, the query operation continues to be performed.

[0101] Optionally, the incremental pre-fetch cache module 408, after the self-increment column identifier detection module 406 detects whether the used identifier portion in the self-increment column identifier set cached locally has reached a predetermined level, further executes:

[0102] If so, an asynchronous cache pre-fetch request is generated, and according to the asynchronous cache pre-fetch request, an attempt is made to incrementally obtain a plurality of unused identifiers of the auto-increment column.

[0103] Optionally, the cache pre-fetch request is an RPC request or an SQL request.

[0104] Optionally, the incremental pre-fetch cache module 408, before generating the cache pre-fetch request, further executes:

[0105] Determine whether an attempt is currently being made to incrementally obtain multiple unused identifiers of the auto-increment column according to another query request;

[0106] Determining that a result of the judgment is no;

[0107] The incremental pre-fetch cache module further executes:

[0108] If the result of the judgment is yes, the cache prefetch request is not generated, but the query operation is directly executed.

[0109] Optionally, the plurality of unused identifiers of the self-increment column are initially acquired from a predetermined service node in the distributed database, and the device is applied to a working node other than the service node;

[0110] The incremental pre-fetch cache module 408 queries the service node for another working node that has been assigned an identifier that is close to the sequence number of the self-incrementing column identifier set;

[0111] Sending an identifier distribution request to the other working node, so that the other working node distributes the unused identifiers cached by the other working node and having a sequence number close to the self-incrementing identifier set to the current working node if the other working node agrees to the identifier sharing request;

[0112] The identifier distributed by the other working node is locally cached in the self-incrementing identifier set so as to be used in sequence.

[0113] Optionally, when the other working node agrees to the identifier sharing request, the incremental pre-fetch cache module 408 further executes:

[0114] Negotiate with the other working node to select one of the current working node and the other working node as a collaborative node for acquiring multiple unused identifiers of the self-increment column at the service node next time;

[0115] If the current working node is determined to be the collaborative node, the service node obtains a plurality of unused identifiers of the self-incrementing column next time and distributes a part of them to the other working node;

[0116] If the current working node is not determined as the collaborative node, the identifier distributed by the other working node is continuously received next time without obtaining the identifier from the service node.

[0117] Figure 5 A schematic diagram of a business processing device for auto-increment columns in a distributed database provided in one or more embodiments of this specification, wherein the device is applied to a node of the distributed database, and the device includes:

[0118] at least one processor; and,

[0119] a memory communicatively connected to the at least one processor; wherein,

[0120] The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

[0121] Acquire multiple unused identifiers of the auto-increment column to form an auto-increment column identifier set, and cache the auto-increment column identifier set locally;

[0122] When a new record row needs to be added to the data table corresponding to the auto-increment column, an unused identifier is obtained from the auto-increment column identifier set cached locally, and used as a key value belonging to the auto-increment column in the newly added record row;

[0123] Detecting whether the portion of used identifiers in the locally cached auto-increment column identifier set has reached a predetermined level, where a portion of unused identifiers still remain in the auto-increment column identifier set;

[0124] If so, multiple unused identifiers of the auto-increment column are incrementally obtained and added to the auto-increment column identifier set cached locally.

[0125] The processor and the memory may communicate with each other via a bus, and the device may further include an input / output interface for communicating with other devices.

[0126] Based on the same idea, one or more embodiments of this specification also provide a non-volatile computer storage medium corresponding to the above method, which is applied to a node of the distributed database, and the medium stores computer executable instructions, and the computer executable instructions are set to:

[0127] Acquire multiple unused identifiers of the auto-increment column to form an auto-increment column identifier set, and cache the auto-increment column identifier set locally;

[0128] When a new record row needs to be added to the data table corresponding to the auto-increment column, an unused identifier is obtained from the auto-increment column identifier set cached locally, and used as a key value belonging to the auto-increment column in the newly added record row;

[0129] Detecting whether the portion of used identifiers in the locally cached auto-increment column identifier set has reached a predetermined level, where a portion of unused identifiers still remain in the auto-increment column identifier set;

[0130] If so, multiple unused identifiers of the auto-increment column are incrementally obtained and added to the auto-increment column identifier set cached locally.

[0131] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0132] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

[0133] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0134] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0135] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification may be in the form of complete hardware embodiments, complete software embodiments, or embodiments in combination with software and hardware. Moreover, the embodiments of this specification may be in the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0136] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0137] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0138] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0139] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0140] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0141] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0142] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity 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, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0143] This specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0144] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device, equipment, and non-volatile computer storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0145] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0146] The above description is only one or more embodiments of this specification and is not intended to limit this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of this specification shall be included in the scope of the claims of this specification.

Claims

1. A business processing method for auto-increment columns in a distributed database, applied to a node of the distributed database, the method comprising: Acquire multiple unused identifiers of the auto-increment column to form an auto-increment column identifier set, and cache the auto-increment column identifier set locally; When it is necessary to add a new record row in the data table corresponding to the auto-increment column, an unused identifier is obtained from the auto-increment column identifier set cached locally, and used as a key value belonging to the auto-increment column in the newly added record row; Detecting whether the portion of used identifiers in the locally cached auto-increment column identifier set has reached a predetermined level, where a portion of unused identifiers still remain in the auto-increment column identifier set; If so, incrementally obtain a plurality of unused identifiers of the auto-increment column and add them to the auto-increment column identifier set cached locally; The plurality of unused identifiers of the self-increment column are initially obtained from a predetermined service node in the distributed database, and the method is applied to working nodes other than the service node; The incremental acquisition of multiple unused identifiers of the auto-increment column specifically includes: Querying the service node for another working node that has been assigned an identifier that is close to the sequence number of the self-incrementing identifier set; Sending an identifier distribution request to the other working node, so that the other working node distributes the unused identifiers cached by the other working node and having a sequence number close to the self-incrementing identifier set to the current working node if the other working node agrees to the identifier sharing request; The identifier distributed by the other working node is locally cached in the self-incrementing identifier set so as to be used in sequence.

2. The method according to claim 1, wherein the detecting whether the portion of used identifiers in the set of auto-increment identifiers cached locally has reached a predetermined level specifically comprises: When a query request is received, obtaining, according to the query request, a current identifier to be retrieved corresponding to the set of auto-increment column identifiers cached locally; According to the current identifier to be used, it is determined whether the portion of used identifiers in the locally cached auto-increment identifier set has reached a predetermined level.

3. The method of claim 1, further comprising: Recording the consumption rate of the unused identifiers in the local cache; The predetermined degree is dynamically set according to the negative correlation relationship set between the consumption speed and the predetermined degree.

4. The method according to claim 2, after detecting whether the portion of used identifiers in the locally cached auto-increment column identifier set has reached a predetermined level, the method further comprises: If yes, generating a synchronous cache pre-fetch request, and setting a sufficiently short safety timeout for the synchronous cache pre-fetch request; According to the synchronized cache prefetch request, attempt to incrementally obtain multiple unused identifiers of the auto-increment column, and block execution of a query operation corresponding to the query request; If the actual timeout period of the cache pre-fetch request is greater than the safety timeout period, the query operation continues to be performed.

5. The method according to claim 1, after detecting whether the portion of used identifiers in the locally cached auto-increment column identifier set has reached a predetermined level, the method further comprises: If so, an asynchronous cache pre-fetch request is generated, and according to the asynchronous cache pre-fetch request, an attempt is made to incrementally obtain a plurality of unused identifiers of the auto-increment column.

6. The method according to claim 4 or 5, wherein the cache pre-fetch request is an RPC request or an SQL request.

7. The method according to claim 4, before generating the cache prefetch request, the method further comprises: Determine whether an attempt is currently being made to incrementally obtain multiple unused identifiers of the auto-increment column according to another query request; Determining that a result of the judgment is no; The method further comprises: If the result of the judgment is yes, the cache prefetch request is not generated, but the query operation is directly executed.

8. The method according to claim 1, wherein when the other working node agrees to the identification sharing request, the method further comprises: Negotiate with the other working node to select one of the current working node and the other working node as a collaborative node for acquiring multiple unused identifiers of the self-increment column from the service node next time; If the current working node is determined to be the collaborative node, after acquiring the multiple unused identifiers of the self-incrementing column from the service node next time, distribute a part of them to the other working node; If the current working node is not determined as the collaborative node, the identifier distributed by the other working node is continuously received next time without obtaining the identifier from the service node.

9. A business processing device for auto-increment columns in a distributed database, applied to a node of the distributed database, the device comprising: An initial cache module obtains a plurality of unused identifiers of an auto-increment column to form an auto-increment column identifier set, and caches the auto-increment column identifier set locally; An auto-increment column identifier using module, when it is necessary to add a new record row in the data table corresponding to the auto-increment column, obtains an unused identifier from the auto-increment column identifier set cached locally, and uses it as a key value belonging to the auto-increment column in the newly added record row; A self-increment column identifier detection module detects whether the portion of used identifiers in the self-increment column identifier set cached locally has reached a predetermined level, and under the predetermined level, a portion of unused identifiers still remains in the self-increment column identifier set; The incremental pre-fetch cache module, if yes, incrementally obtains a plurality of unused identifiers of the auto-increment column, and adds them to the auto-increment column identifier set cached locally; The plurality of unused identifiers of the self-increment column are initially obtained from a predetermined service node in the distributed database, and the device is applied to a working node other than the service node; The incremental pre-fetch cache module queries the service node for another working node that has been assigned an identifier that is close to the sequence number of the self-incrementing column identifier set; Sending an identifier distribution request to the other working node, so that the other working node distributes the unused identifiers cached by the other working node and having a sequence number close to the self-incrementing identifier set to the current working node if the other working node agrees to the identifier sharing request; The identifier distributed by the other working node is locally cached in the self-incrementing identifier set so as to be used in sequence.

10. The device according to claim 9, wherein the self-increment column identifier detection module, when receiving a query request, obtains the current identifier to be used corresponding to the self-increment column identifier set cached locally according to the query request; According to the current identifier to be used, it is determined whether the portion of used identifiers in the locally cached auto-increment identifier set has reached a predetermined level.

11. The device according to claim 9, wherein the self-incrementing column identifier detection module records the consumption speed of the unused identifiers in the local cache; The predetermined degree is dynamically set according to the negative correlation relationship set between the consumption speed and the predetermined degree.

12. The apparatus according to claim 10, wherein the incremental pre-fetch cache module, after the self-increment column identifier detection module detects whether the used identifier portion in the self-increment column identifier set cached locally has reached a predetermined level, further executes: If yes, generating a synchronous cache pre-fetch request, and setting a sufficiently short safety timeout for the synchronous cache pre-fetch request; According to the synchronized cache prefetch request, attempt to incrementally obtain multiple unused identifiers of the auto-increment column, and block execution of a query operation corresponding to the query request; If the actual timeout period of the cache pre-fetch request is greater than the safety timeout period, the query operation continues to be performed.

13. The apparatus according to claim 9, wherein the incremental pre-fetch cache module, after the self-increment column identifier detection module detects whether the used identifier portion in the self-increment column identifier set cached locally has reached a predetermined level, further executes: If so, an asynchronous cache pre-fetch request is generated, and according to the asynchronous cache pre-fetch request, an attempt is made to incrementally obtain a plurality of unused identifiers of the auto-increment column.

14. The device according to claim 12 or 13, wherein the cache pre-fetch request is an RPC request or an SQL request.

15. The apparatus according to claim 12, wherein the incremental pre-fetch cache module, before generating the cache pre-fetch request, further executes: Determine whether an attempt is currently being made to incrementally obtain multiple unused identifiers of the auto-increment column according to another query request; Determining that a result of the judgment is no; The incremental pre-fetch cache module further executes: If the result of the judgment is yes, the cache prefetch request is not generated, but the query operation is directly executed.

16. The apparatus according to claim 9, wherein when the other working node agrees with the identification sharing request, the incremental pre-fetch cache module further executes: Negotiate with the other working node to select one of the current working node and the other working node as a collaborative node for acquiring multiple unused identifiers of the self-increment column from the service node next time; If the current working node is determined to be the collaborative node, after acquiring the multiple unused identifiers of the self-incrementing column from the service node next time, distribute a part of them to the other working node; If the current working node is not determined as the collaborative node, the identifier distributed by the other working node is continuously received next time without obtaining the identifier from the service node.

17. A business processing device for auto-increment columns in a distributed database, applied to a node of the distributed database, the device comprising: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to: Acquire multiple unused identifiers of the auto-increment column to form an auto-increment column identifier set, and cache the auto-increment column identifier set locally; When a new record row needs to be added to the data table corresponding to the auto-increment column, an unused identifier is obtained from the auto-increment column identifier set cached locally, and used as a key value belonging to the auto-increment column in the newly added record row; Detecting whether the portion of used identifiers in the locally cached auto-increment column identifier set has reached a predetermined level, where a portion of unused identifiers still remain in the auto-increment column identifier set; If so, incrementally obtain a plurality of unused identifiers of the auto-increment column and add them to the auto-increment column identifier set cached locally; The plurality of unused identifiers of the self-increment column are initially obtained from a predetermined service node in the distributed database, and the device is applied to a working node other than the service node; The incremental acquisition of multiple unused identifiers of the auto-increment column specifically includes: Querying the service node for another working node that has been assigned an identifier that is close to the sequence number of the self-incrementing identifier set; Sending an identifier distribution request to the other working node, so that the other working node distributes the unused identifiers cached by the other working node and having a sequence number close to the self-incrementing identifier set to the current working node if the other working node agrees to the identifier sharing request; The identifier distributed by the other working node is locally cached in the self-incrementing identifier set so as to be used in sequence.

Images