IFlakeIdGenerator Interface
Namespace: Hazelcast.DistributedObjects
Assembly: Hazelcast.Net.dll
Represents a cluster-wide unique identifier generator. The identifiers are long primitive values
in the range from 0 to MaxValue, and are k-ordered (roughly ordered).
public interface IFlakeIdGenerator : IDistributedObject, IAsyncDisposableInherited Members
Remarks
The identifiers contain a timestamp component, and a member identifier component which is assigned when the member joins the cluster. This allows identifiers to be ordered and unique without any coordination between members, thus making the generator safe even in split-brain scenario.
The timestamp component is composed of 41 bits representing milliseconds since Jan. 1st, 2018 00:00UTC. This caps the useful lifespan of the generator to little less that 70 years, i.e. until ~2088.
The sequence component is composed of 6 bits. If more than 64 identifiers are requested in a single milliseconds, identifiers will gracefully overflow to the next milliseconds while still guaranteeing uniqueness.
The member-side implementation does not allow overflowing by more than 15 seconds, and if identifiers are requested at a higher rate, calls will block. Note that however clients are able to generate identifiers faster, because each call goes to a different (random) member and the 64 identifiers/ms limit is for one single member.
It is possible to generate identifiers on any member or client as lon as there is at least one member with join version smaller than 2^16 in the cluster. The remedy is to restart the cluster, and then node identifiers will be assigned from zero again. Uniqueness after a restart is guaranteed by the timestamp component.
Timestamp component is in milliseconds since 1.1.2018, 0:00 UTC and has 41 bits. This caps the useful lifespan of the generator to little less than 70 years (until ~2088). The sequence component is 6 bits. If more than 64 IDs are requested in single millisecond, IDs will gracefully overflow to the next millisecond and uniqueness is guaranteed in this case. The implementation does not allow overflowing by more than 15 seconds, if IDs are requested at higher rate, the call will block. Note, however, that clients are able to generate even faster because each call goes to a different (random) member, and the 64 IDs/ms limit is for single member.
It is possible to generate IDs on any member or client as long as there is at least one member with join version smaller than 2^16 in the cluster. The remedy is to restart the cluster: nodeId will be assigned from zero again. Uniqueness after the restart will be preserved thanks to the timestamp component.
Methods
| Name | Description |
|---|---|
| GetNewIdAsync() | Gets a new cluster-wide unique identifier. |