Current state: Under Discussion
Discussion thread: here
JIRA: here
Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).
Kafka Brokers today rely on Apache Zookeeper. Many folks in the community have expressed a desire to either change the zkclient and start using Apache Curator or allowing other systems like etcd, consul, Apache Cassandra and others to handle the role Zookeeper is currently playing. By allowing the brokers to have both a way to plug-in another server for storing the meta data and also for leader election then we can have the ability to-do this.
This KIP proposes approach for isolating coordination related functionality to separate modules. These modules should come with a public interface that can have pluggable implementations.
Zookeeper has advanced low-level primitives for coordinating distributed systems – ephemeral nodes, key-value storage, watchers. Such concepts may not be available in other consensus frameworks. At the same time such low-level primitives (especially ephemeral nodes) are error prone and usually a cause of subtle bugs in Kafka coordination code.
That's why instead of focusing on question “how Kafka does coordination with Zookeeper” it is proposed to concentrate on question “what general problems of distributed systems are solved in Kafka by means of Zookeeper”. Having defined interface boundaries this way, we'll be able to hide implementation details under concrete realizations developed with corresponding built-in facilities available in particular tools (e.g. ephemeral nodes vs TTLs).
It is proposed to separate such high-level concerns:
- Group membership protocol (Kafka brokers form a cluster; consumer connectors form a consumer group)
- Leader election (electing controller among brokers)
- Distributed key-value storage (topic config storage etc etc etc)
- Data-change listeners (triggering events - partition reassignment, catching up isr-s etc)
Below each module is presented by its interface.
(NOTE: Initial version of the interfaces is in Scala to make it cleaner and shorter. The final version (actual Kafka interfaces) is planned to be written in Java).
/**
* A connector for group membership protocol. Supports two modes:
* 1) "joining" (becoming the member, leaving the group, subscribing to change notifications)
* 2) "observing" (fetching group state, subscribing to change notifications)
*
*/
trait GroupMembershipClient {
/**
* Each instance of this class is tightly coupled with exactly one group,
* once set (during initialization) cannot be changed
* @return unique group identifier among all application groups
*/
def group: String
/**
* Become a member of this group. Throw an exception in case of ID conflict
* @param id unique member identifier among members of this group
* @param data supplemental data to be stored along with member ID
*/
def join(id: String, data: String): Unit
/**
* Stop membership in this group
* @param id unique member identifier among members of this group
*/
def leave(id: String): Unit
/**
* Fetch membership of this group
* @return IDs of the members of this group
*/
def membershipList(): Set[String]
/**
* Fetch detailed membership of this group
* @return IDs and corresponding supplemental data of the members of this group
*/
def membership(): Map[String, String]
/**
* Register permanent on group change listener.
* There is no guarantee listener will be fired on ALL events (due to session reconnects etc)
* @param listener see [[GroupChangeListener]]
*/
def addListener(listener: GroupChangeListener)
/**
* Deregister on group change listener
* @param listener see [[GroupChangeListener]]
*/
def removeListener(listener: GroupChangeListener)
/**
* Setup everything needed for concrete implementation
* @param context TBD. Should be abstract enough to be used by different implementations and
* at the same time specific because will be uniformly called from the Kafka code -
* regardless of the implementation
*/
def init(context: Any): Unit
/**
* Release all acquired resources
*/
def close(): Unit
}
/**
* A callback fired on group change event
*/
trait GroupChangeListener {
/**
* Event fired when the group membership has changed (member(s) joined and/or left)
* @param membership new membership of the group
*/
def onGroupChange(membership: Set[String])
}
/**
* A connector for leadership election protocol. Supports two modes:
* 1) "running for election" (joining the candidates for leadership, resigning as a leader, subscribing to change notifications)
* 2) "observing" (getting current leader, subscribing to change notifications)
*
*/
trait LeaderElectionClient{
/**
* Each instance of this class is tightly coupled with leadership over exactly one service (resource),
* once set (during initialization) cannot be changed
*
* @return unique group identifier among all application services (resources)
*/
def service: String
/**
* Get current leader of the resource (if any)
* @return the leader id if it exists
*/
def getLeader: Option[String]
/**
* Make this candidate eligible for leader election and try to obtain leadership for this service if it's vacant
*
* @param candidate ID of the candidate which is eligible for election
* @return true if given candidate is now a leader
*/
def nominate(candidate: String): Boolean
/**
* Voluntarily resign as a leader and initiate new leader election.
* It's a client responsibility to stop all leader duties before calling this method to avoid more-than-one-leader cases
*
* @param leader current leader ID (will be ignored if not a leader)
*/
def resign(leader: String): Unit
/**
* Register permanent on leader change listener
* There is no guarantee listener will be fired on ALL events (due to session reconnects etc)
* @param listener see [[LeaderChangeListener]]
*/
def addListener(listener: LeaderChangeListener)
/**
* Deregister on leader change listener
* @param listener see [[LeaderChangeListener]]
*/
def removeListener(listener: LeaderChangeListener)
/**
* Setup everything needed for concrete implementation
* @param context TBD. Should be abstract enough to be used by different implementations and
* at the same time specific because will be uniformly called from the Kafka code -
* regardless of the implementation
*/
def init(context: Any): Unit
/**
* Release all acquired resources
*/
def close(): Unit
}
/**
* A callback fired on leader change event
*/
trait LeaderChangeListener {
/**
* Event fired when the leader has changed (resigned or acquired a leadership)
* @param leader new leader for the given service if one has been elected, otherwise None
*/
def onLeaderChange(leader: Option[String])
}
/**
* Interface to a (persistent) key value storage
*/
trait Storage {
/**
* Get data by its key
* @param key data ID in this storage
* @return future result of the value (if exists) associated with the key
*/
def fetch(key: String): Future[Option[String]]
/**
* Persist value with its associated key. The contract is to throw an exception
* if such key already exists
*
* @param key data ID in this storage
* @param data value associated with the key
*/
def put(key: String, data: String)
/**
* Update value by its associated key. The contract is to throw an exception
* if such key doesn't exist
*
* @param key data ID in this storage
* @param data value associated with the key
*/
def update(key: String, data: String)
/**
* Setup everything needed for concrete implementation
* @param context TBD. Should be abstract enough to be used by different implementations and
* at the same time specific because will be uniformly called from the Kafka code -
* regardless of the implementation
*/
def init(context: Any): Unit
/**
* Release all acquired resources
*/
def close(): Unit
}
/**
* A registry for async data change notifications
*/
trait ListenerRegistry {
/**
* Register permanent callback for data change event
* @param key the listenable data identifier
* @param eventListener see [[ValueChangeListener]]
*/
def addValueChangeListener(key: String, eventListener: ValueChangeListener): Unit
/**
* Deregister permanent callback for data change event
* @param key the listenable data identifier
* @param eventListener see [[EventListener]]
*/
def removeValueChangeListener(key: String, eventListener: ValueChangeListener): Unit
/**
* Register permanent callback for key-set change event
* @param namespace the listenable key-set identifier (e.g. parent path in Zookeeper, table name in Database etc)
* @param eventListener see [[ValueChangeListener]]
*/
def addKeySetChangeListener(namespace: String, eventListener: KeySetChangeListener): Unit
/**
* Deregister permanent callback for key-set change event
* @param namespace the listenable key-set identifier (e.g. parent path in Zookeeper, table name in Database etc)
* @param eventListener see [[ValueChangeListener]]
*/
def removeKeySetChangeListener(namespace: String, eventListener: KeySetChangeListener): Unit
/**
* Setup everything needed for concrete implementation
* @param context TBD. Should be abstract enough to be used by different implementations and
* at the same time specific because will be uniformly called from the Kafka code,
* regardless of the implementation
*/
def init(context: Any): Unit
/**
* Release all acquired resources
*/
def close(): Unit
}
/**
* Callback on value change event
*/
trait ValueChangeListener {
def valueChanged(newValue: Option[String])
}
/**
* Callback on key-set change event
*/
trait KeySetChangeListener {
def keySetChanged(newKeySet: Set[String])
}
Shared interface for plugable consensus and metadata storage systems should be compatible for Zookeeper-based implementation. Also this implementation will likely be the default one.
As part of this KIP it will be required to rework some system and replication tools. It will not be possible anymore to rely on Zookeeper as a default metadata storage system, also it will not be possible to use it to trigger particular administrative commands. Most of the tools are related to topic management (create topics, reassign partitions etc) and consumer group management (offset checker etc).
The approach to topic tools is covered in KIP-4 - we will move all administrative logic to brokers. KIP-4 is currently under development and has agreed Wire Protocol changes.
The consumer group tools should be covered separately. Having New Java Consumer in 0.9 release with server-side coordinator may let us deprecate old consumer and thus all tools related to it. Consumer group tools should work as usual if brokers are run with Zookeeper based implementation of the shared interface.
If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.