github.com/outbrain/consul@v1.4.5/website/source/intro/vs/zookeeper.html.md (about)

     1  ---
     2  layout: "intro"
     3  page_title: "Consul vs. ZooKeeper, doozerd, etcd"
     4  sidebar_current: "vs-other-zk"
     5  description: |-
     6    ZooKeeper, doozerd, and etcd are all similar in their architecture. All three have server nodes that require a quorum of nodes to operate (usually a simple majority). They are strongly-consistent and expose various primitives that can be used through client libraries within applications to build complex distributed systems.
     7  ---
     8  
     9  # Consul vs. ZooKeeper, doozerd, etcd
    10  
    11  ZooKeeper, doozerd, and etcd are all similar in their architecture. All three have
    12  server nodes that require a quorum of nodes to operate (usually a simple majority).
    13  They are strongly-consistent and expose various primitives that can be used through
    14  client libraries within applications to build complex distributed systems.
    15  
    16  Consul also uses server nodes within a single datacenter. In each datacenter, Consul
    17  servers require a quorum to operate and provide strong consistency. However, Consul
    18  has native support for multiple datacenters as well as a more feature-rich gossip
    19  system that links server nodes and clients.
    20  
    21  All of these systems have roughly the same semantics when providing key/value storage:
    22  reads are strongly consistent and availability is sacrificed for consistency in the
    23  face of a network partition. However, the differences become more apparent when these
    24  systems are used for advanced cases.
    25  
    26  The semantics provided by these systems are attractive for building service discovery
    27  systems, but it's important to stress that these features must be built. ZooKeeper et
    28  al. provide only a primitive K/V store and require that application developers build
    29  their own system to provide service discovery. Consul, by contrast, provides an
    30  opinionated framework for service discovery and eliminates the guess-work and
    31  development effort. Clients simply register services and then perform discovery using
    32  a DNS or HTTP interface. Other systems require a home-rolled solution.
    33  
    34  A compelling service discovery framework must incorporate health checking and the
    35  possibility of failures as well. It is not useful to know that Node A provides the Foo
    36  service if that node has failed or the service crashed. Naive systems make use of
    37  heartbeating, using periodic updates and TTLs. These schemes require work linear
    38  to the number of nodes and place the demand on a fixed number of servers. Additionally,
    39  the failure detection window is at least as long as the TTL.
    40  
    41  ZooKeeper provides ephemeral nodes which are K/V entries that are removed when a client
    42  disconnects. These are more sophisticated than a heartbeat system but still have
    43  inherent scalability issues and add client-side complexity. All clients must maintain
    44  active connections to the ZooKeeper servers and perform keep-alives. Additionally, this
    45  requires "thick clients" which are difficult to write and often result in debugging
    46  challenges.
    47  
    48  Consul uses a very different architecture for health checking. Instead of only having
    49  server nodes, Consul clients run on every node in the cluster. These clients are part
    50  of a [gossip pool](/docs/internals/gossip.html) which serves several functions,
    51  including distributed health checking. The gossip protocol implements an efficient
    52  failure detector that can scale to clusters of any size without concentrating the work
    53  on any select group of servers. The clients also enable a much richer set of health
    54  checks to be run locally, whereas ZooKeeper ephemeral nodes are a very primitive check
    55  of liveness. With Consul, clients can check that a web server is returning 200 status
    56  codes, that memory utilization is not critical, that there is sufficient disk space,
    57  etc. The Consul clients expose a simple HTTP interface and avoid exposing the complexity
    58  of the system to clients in the same way as ZooKeeper.
    59  
    60  Consul provides first-class support for service discovery, health checking,
    61  K/V storage, and multiple datacenters. To support anything more than simple K/V storage,
    62  all these other systems require additional tools and libraries to be built on
    63  top. By using client nodes, Consul provides a simple API that only requires thin clients.
    64  Additionally, the API can be avoided entirely by using configuration files and the
    65  DNS interface to have a complete service discovery solution with no development at all.