ZooKeeper - Centralized service for maintaining configuration information

  •        4596

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications.

The name space provided by ZooKeeper is much like that of a standard file system. A name is a sequence of path elements separated by a slash (/). Every node in ZooKeeper's name space is identified by a path. ZooKeeper supports the concept of watches. Clients can set a watch on a znodes. A watch will be triggered and removed when the znode changes. It supports replication.

In case of distributed system, there may be multiple servers interacting with each other. Few may need to share some common resources. Consider a scenario, where a application server wants to know the list of database servers, then it could communicate the Zookeeper server and fetch the required information.

http://zookeeper.apache.org/
https://github.com/apache/zookeeper

Tags
Implementation
License
Platform

   




Related Projects

Noah - Lightweight node/service registry inspired by Apache Zookeeper


Noah is a lightweight node/service registry inspired by Apache Zookeeper. It provides support for Service registry, Node registry, Configuration Registry, Group Services, Watches.

Apache Curator - Simplifies using ZooKeeper


The Curator Framework is a high-level API that greatly simplifies using ZooKeeper. It adds many features that build on ZooKeeper and handles the complexity of managing connections to the ZooKeeper cluster and retrying operations. Its features include Automatic connection management, Cleaner API, Leader election, Shared lock, Path cache and watcher, Distributed Queue and lot more.

Consul - Tool for Service Discovery, Monitoring and Configuration


Consul is a tool for service discovery and configuration. Consul is distributed, highly available, and extremely scalable. Consul makes it simple for services to register themselves and to discover other services via a DNS or HTTP interface. Register external services such as SaaS providers as well. It prevents routing requests to unhealthy hosts and enables services to easily provide circuit breakers.

etcd - Distributed reliable key-value store for the most critical data of a distributed system


etcd is a distributed, consistent key-value store for shared configuration and service discovery. It is simple, secure, fast and reliable. it uses the Raft consensus algorithm to manage a highly-available replicated log.

Doozer - A consistent distributed data store


Doozer is a highly-available, completely consistent store for small amounts of extremely important data. When the data changes, it can notify connected clients immediately (no polling), making it ideal for infrequently-updated data for which clients want real-time updates. Doozer is good for name service, database master elections, and configuration data shared between several machines.



constructr-zookeeper - This library enables to use ZooKeeper as cluster coordinator in a ConstructR based cluster


This library enables to use ZooKeeper as cluster coordinator in a ConstructR based node.ConstructR aims at cluster bootstrapping (construction) by using a coordination service and provides etcd as the default one. By means of this library, you will be able to use ZooKeeper as coordination service instead.

ishare - nodejs client for service coordination using zookeeper


nodejs client for service coordination using zookeeper

serf - Service orchestration and management tool


Serf is a decentralized solution for service discovery and orchestration that is lightweight, highly available, and fault tolerant.Serf runs on Linux, Mac OS X, and Windows. An efficient and lightweight gossip protocol is used to communicate with other nodes. Serf can detect node failures and notify the rest of the cluster. An event system is built on top of Serf, letting you use Serf's gossip protocol to propagate events such as deploys, configuration changes, etc. Serf is completely masterless with no single point of failure.

pilot - Istio Pilot implementation


Istio Pilot provides platform-independant service discovery, and exposes an interface to configure rich L7 routing features such as label based routing across multiple service versions, fault injection, timeouts, retries, circuit breakers. It translates these configurations into sidecar-specific configuration and dynamically reconfigures the sidecars in the service mesh data plane. Platform-specific eccentricities are abstracted and a simplified service discovery interface is presented to the sidecars based on the Envoy data plane API.Please see Istio's traffic management concepts to learn more about the design of Pilot and the capabilities it provides.

sidecar - Gossip-based service discovery. Docker native, but supports static discovery, too.


Sidecar is a dynamic service discovery platform requiring no external coordination service. It's a peer-to-peer system that uses a gossip protocol for all communication between hosts. Sidecar health checks local services and announces them to peer systems. It's Docker-native so your containerized applications work out of the box. It's designed to be Available, Partition tolerant, and eventually consistent—where "eventually" is a very short time window on the matter of a few seconds.haproxy-api - A separation layer that allows Sidecar and HAproxy to run in seperate containers. It also allows a local HAproxy to be configured against a remote Sidecar instance.

linkerd - Resilient service mesh for cloud native apps


linkerd is a transparent service mesh, designed to make modern applications safe and sane by transparently adding service discovery, load balancing, failure handling, instrumentation, and routing to all inter-service communication.linkerd (pronouned "linker-DEE") acts as a transparent HTTP/gRPC/thrift/etc proxy, and can usually be dropped into existing applications with a minimum of configuration, regardless of what language they're written in. It works with many common protocols and service discovery backends, including scheduled environments like Mesos and Kubernetes.

beacon - Service discovery for Docker and etcd.


This section defines service configuration including timeouts and servicelocation. Available parameters are:- `var` - The name of an environment variable on a container to read service configuration from. This defaults to `SERVICES`. The value of this variable is a comma separated list of service definitions. The structure of a service definition is `name:port/protocol` where `name` is the name of the service, `port` is the port the service listens on, and protocol is either `tcp` or `udp`.

kubernetes-envoy-sds - Kubernetes Envoy Service Discovery Service.


The kubernetes-envoy-sds service implements the Envoy Service Discovery REST API on top of the Kubernetes Services API.See the envoy.json configuration file for a complete example.

skydock - Service discovery via DNS for docker


Docker supports DNS based service discovery now. You should use the Docker implementation instead of this project. Skydock was built at a time when Docker did not support DNS discovery or auto registration. I'll keep the repo up for past years and as reference for others but don't use it if you have a recent version of Docker.Skydock monitors docker events when containers start, stop, die, kill, etc and inserts records into a dynamic DNS server skydns. This allows standard DNS queries for services running inside docker containers. Because lets face it, if you have to modify your application code to work with other service discovery solutions you might as well just give up. DNS just works and it works well. Also you cannot be expected to modify application code that you don't own. Passing service urls via the cli or in static config files (nginx) will not be possible if your service discovery solution requires a client library just to fetch an IP.

Redisson - Redis based In-Memory Data Grid for Java


Redisson - distributed Java objects and services (Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, Map Reduce, Publish / Subscribe, Bloom filter, Spring Cache, Executor service, Tomcat Session Manager, Scheduler service, JCache API) on top of Redis server. Rich Redis client.

galaxya - embeddable peer 2 peer service discovery and configuration


embeddable peer 2 peer service discovery and configuration

locojs - Web service management and discovery for localhost


Web service management and discovery for localhost

nerve - A service registration daemon that performs health checks; companion to airbnb/synapse


Nerve is a utility for tracking the status of machines and services.It runs locally on the boxes which make up a distributed system, and reports state information to a distributed key-value store.At Airbnb, we use Zookeeper as our key-value store.The combination of Nerve and [Synapse](https://github.com/airbnb/synapse) make service discovery in the cloud easy!

discovery-srv - Service discovery for microservices


The discovery service is a micro service which layers on the go-micro.Registry to provide service discovery. It includes heartbeating, in memory caching and maintains a registry based on liveness.Discovery can be run as a single instance. It just needs a server address and the same as the registry address.