CONSUL VS. ZOOKEEPER, DOOZERD, ETC
来源:互联网 发布:linux less 退出 编辑:程序博客网 时间:2024/06/08 22:49
CONSUL VS. ZOOKEEPER, DOOZERD, ETC
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.
Consul also uses server nodes within a single datacenter. In each datacenter, Consul servers require a quorum to operate and provide strong consistency. However, Consul has native support for multiple datacenters as well as a more feature-rich gossip system that links server nodes and clients.
All of these systems have roughly the same semantics when providing key/value storage: reads are strongly consistent and availability is sacrificed for consistency in the face of a network partition. However, the differences become more apparent when these systems are used for advanced cases.
The semantics provided by these systems are attractive for building service discovery systems, but it's important to stress that these features must be built. ZooKeeper et al. provide only a primitive K/V store and require that application developers build their own system to provide service discovery. Consul, by contrast, provides an opinionated framework for service discovery and eliminates the guess-work and development effort. Clients simply register services and then perform discovery using a DNS or HTTP interface. Other systems require a home-rolled solution.
A compelling service discovery framework must incorporate health checking and the possibility of failures as well. It is not useful to know that Node A provides the Foo service if that node has failed or the service crashed. Naive systems make use of heartbeating, using periodic updates and TTLs. These schemes require work linear to the number of nodes and place the demand on a fixed number of servers. Additionally, the failure detection window is at least as long as the TTL.
ZooKeeper provides ephemeral nodes which are K/V entries that are removed when a client disconnects. These are more sophisticated than a heartbeat system but still have inherent scalability issues and add client-side complexity. All clients must maintain active connections to the ZooKeeper servers and perform keep-alives. Additionally, this requires "thick clients" which are difficult to write and often result in debugging challenges.
Consul uses a very different architecture for health checking. Instead of only having server nodes, Consul clients run on every node in the cluster. These clients are part of a gossip pool which serves several functions, including distributed health checking. The gossip protocol implements an efficient failure detector that can scale to clusters of any size without concentrating the work on any select group of servers. The clients also enable a much richer set of health checks to be run locally, whereas ZooKeeper ephemeral nodes are a very primitive check of liveness. With Consul, clients can check that a web server is returning 200 status codes, that memory utilization is not critical, that there is sufficient disk space, etc. The Consul clients expose a simple HTTP interface and avoid exposing the complexity of the system to clients in the same way as ZooKeeper.
Consul provides first-class support for service discovery, health checking, K/V storage, and multiple datacenters. To support anything more than simple K/V storage, all these other systems require additional tools and libraries to be built on top. By using client nodes, Consul provides a simple API that only requires thin clients. Additionally, the API can be avoided entirely by using configuration files and the DNS interface to have a complete service discovery solution with no development at all.
- CONSUL VS. ZOOKEEPER, DOOZERD, ETC
- consul VS zookeeper、etcd、doozerd
- 服务发现:Zookeeper vs etcd vs Consul
- 服务发现:Zookeeper vs etcd vs Consul
- 服务发现:Zookeeper vs etcd vs Consul
- 服务发现:Zookeeper vs etcd vs Consul
- 服务发现:Zookeeper vs etcd vs Consul
- 服务发现:Zookeeper vs etcd vs Consul
- 服务发现:Zookeeper vs etcd vs Consul
- 服务发现比较:Consul vs Zookeeper vs Etcd vs Eureka
- 服务发现比较:Consul vs Zookeeper vs Etcd vs Eureka
- 服务发现比较:Consul vs Zookeeper vs Etcd vs Eureka
- 服务发现之zookeeper VS consul VS etcd
- SpringCloud服务注册中心比较:Consul vs Zookeeper vs Etcd vs Eureka
- SpringCloud服务注册中心比较:Consul vs Zookeeper vs Etcd vs Eureka
- SpringCloud服务注册中心比较:Consul vs Zookeeper vs Etcd vs Eureka
- 微服务发现比较:Consul vs Zookeeper vs Etcd vs Eureka
- SpringCloud服务注册中心比较:Consul vs Zookeeper vs Etcd vs Eureka
- Struts2+Spring4+myBatis3整合
- First try play Git!Windows(debug)萌新的摸爬滚打之路2
- php qconf qconf manage配置
- Xcode8 注释快捷键不能使用解决办法
- Swift-解读Alamofire
- CONSUL VS. ZOOKEEPER, DOOZERD, ETC
- Web前端面试指导(一):写好简历是面试成功的第一步
- ArrayList、LinkedList、Concurrent集合源码比较
- hdu4004 The Frog's Games 二分查找+贪心 TWT Tokyo Olympic 1COMBO-2
- Xcode插件管理工具Alcatraz,常用插件介绍 -iOS
- 使用Exchange服务实现跨平台(PC+Web + 移动端)日历的日程管理
- 硬链接与软链接
- 追着嘟嘟学c#系列基础第六篇-----c#方法【蓝鸥出品】
- 那些你不知道的APK 瘦身,让你的APK更小