I think you need to also look at the processes that are using the id in case of a split brain scenario. A unique identifier is always some centralistic approach either it is done by one central service or a central rule that is enforced in a distributed fashion.
For instance, in your case you can have x nodes and each of them generates a unique id starting with nodename_localuniqueid of the node. In this case you can be also sure in case of a splitbrain scenario that the ids are unique if and only if the node names are unique. > On 19. Sep 2018, at 21:36, abatra <ankit.batr...@gmail.com> wrote: > > Hi, > > I have a requirement to create a distributed cluster-unique ID generator > microservice. I have done a PoC on it using Apache Ignite ID Generator. > > I created a 2 node cluster with two instances of microservices running on > each node. Nodes are in the same datacenter (in fact in the same network and > will always be deployed in the same network) and I use TCP/IP discovery to > discover cluster nodes. > > So far, it looks pretty good except that it does not provide persistence out > of the box. But I can work around it by backing latest generated ID in a > persistent cache and initializing ID generator with the latest value on a > cluster restart. > > However, one thing I could not find an answer for is if the out of the box > ID generator is split brain compliant. I cannot afford to have a duplicate > ID and want to understand if duplicate ID(s) could occur in a split-brain > scenario. If yes, what is the recommended approach to handling that > scenario? > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/
