A user of ZooKeeper doesn’t care about ZooKeeper clusters having a leader. Its an implementation detail. ZooKeeper servers elect a leader among themselves as a way to enforce some of the consistency guarantees ZooKeeper as a service offers.
You as a user of ZooKeeper (or user of Curator as a nicer API) don’t really care about that. In fact, ZK doesn’t expose this implementation detail - you don’t know if you are talking to a leader or a follower.
This ZK internal leader election has nothing to do with a use case ZooKeeper as a service offers - leader election for the users of ZooKeeper.
If you are using ZK, you are probably building a distributed service yourself, your service being distributed across several machines. As any other distributed system, you might face a problem at some point (e.g. task coordination) which is commonly solved by the leader election pattern:
In this case, you could go ahead and implement one of the listed algorithms yourself. Even better - you might use a coordination service like ZooKeeper. In ZK api you can implement leader election with sequential and ephemeral nodes. Take a look at this recipe:
As you see, the recipe is not trivial to implement using the bare ZK api, so Curator offers a nicer wrapper to make it easier for you.
In summary, when talking about Leader Election in ZooKeeper, there are two different things:
- Leader election done internally by ZK servers among themselves, as a mechanism to implement strong consistency
- Leader election as a feature provided to users of ZooKeeper, which needs to be either implemented manually using the ZK primitives, or used as an available recipe in the Curator library