Jump to Navigation

etcd vs consul vs zookeeper 简单对比

etcd vs consul vs zookeeper 简单对比

这是目前在分布式一致性方面非常优秀的项目。

zookeeper:

使用posix协议,功能全面,但开发与维护复杂。采用java编写。

  • k/v存储,
  • 服务协调API,
  • 锁,
  • ephemeral Node
  • API,私有协议,语言绑定包括java/c/python,常用语言有,但并不容易添加新的语言封装。
  • 效率 W: 200/秒,R: 2000/秒
  • 协调规模:

可在此基础上实现: 服务注册,监控

consul:

使用raft 协议,功能全面,自带服务注册机制,开发简单,维护中等复杂程序。采用golang编写。

  • k/v存储,
  • 锁,
  • 服务注册,监控,
  • API采用HTTP REST
  • 效率 W: ?/秒,R: ?/秒
  • 协调规模:

可在此基础上实现: 服务协调API

consul太倾向微服务架构,体系偏大了点(相比zookeeper不大)。

也可以说consul集成了进程管理,并且在应用上以运维工作为主了。

etcd:

使用raft协议,功能比较少,开发简单,维护简单。采用golang编写。

  • k/v存储,
  • 锁,
  • API: HTTP REST(v2及以下) / gRPC(v3)
  • 效率 W: 1000/秒,R: 7000/秒
  • 协调规模:协调10000节点级(kub)

可在此基础上实现: 服务协调API,服务注册,监控

总结

所以这些实现功能上类似,只是功能模块交集有多少的问题。

所效率上说,zookeeper由于算法与实现的问题,处理最最差水平。

后两者的效率,目前还没有consul数据,但应该两者差距不会太大。

另外还有一个指标是服务协调能力,这个指标的大概标准是能够协调多大规模的集群节点。

一般来说,除非特别需要,不再选用zookeeper,至少从后两者中选择。

后两者选用时根据不同偏向使用的情况决定哪一款更合适。

在应用复杂程序上,etcd需要更多开发,但内核相对最精简。

consol能够节省部分注册工作,但订制力有变弱了。

如有描述不当或者数据不准确,还请指正。

發表新回應

Plain text

  • 不允許使用 HTML 標籤。
  • 自動將網址與電子郵件地址轉變為連結。
  • 自動斷行和分段。
CAPTCHA
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
Image CAPTCHA
Enter the characters shown in the image.


Main menu 2

Story | by Dr. Radut