Etcd 介绍

发布时间: 更新时间: 总字数:1173 阅读时间:3m 作者: 分享 复制网址

etcdCoreOS 团队发起的一个管理配置信息服务发现(Service Discovery)的项目,本文介绍该项目的目标,安装和使用,以及实现的技术。

简介

etcdCoreOS 团队于 2013 年 6 月发起的开源项目,它的目标是构建一个高可用的分布式键值(key-value)数据库,基于 Go 语言实现。 我们知道,在分布式系统中,各种服务的配置信息的管理分享,服务的发现是一个很基本同时也是很重要的问题。 CoreOS 项目就希望基于 etcd 来解决这一问题。

etcd 目前在 https://github.com/coreos/etcd 进行维护。

特点

受到 Apache ZooKeeper 项目和 doozer 项目的启发,etcd 在设计的时候重点考虑了下面四个要素:

  • 简单:具有定义良好、面向用户的 API (gRPC)
  • 安全:支持 HTTPS 方式的访问
  • 快速:支持并发 10 k/s 的写操作
  • 可靠:支持分布式结构,基于 Raft 的一致性算法

说明:

  • Apache ZooKeeper 是一套知名的分布式系统中进行同步和一致性管理的工具。
  • doozer 是一个一致性分布式数据库。

Raft 是一套通过选举主节点来实现分布式系统一致性的算法,相比于大名鼎鼎的 Paxos 算法,它的过程更容易被人理解,由 Stanford 大学的 Diego Ongaro 和 John Ousterhout 提出。更多细节可以参考 raftconsensus.github.io。

一般情况下,用户使用 etcd 可以在多个节点上启动多个实例,并添加它们为一个集群。同一个集群中的 etcd 实例将会保持彼此信息的一致性。

使用场景

和ZK类似,ETCD有很多使用场景,包括:

  • 配置管理
  • 服务注册于发现
  • 选主
  • 应用调度
  • 分布式队列
  • 分布式锁

ETCD读写性能

  • 按照官网给出的Benchmark, 在2CPU,8G内存,SSD磁盘这样的配置下,单节点的写性能可以达到16K QPS, 而先写后读也能达到12K QPS。性能相当可观。更多参考
  • 磁盘 IO 速度是影响 Etcd 性能和稳定性的关键因素,请求写入磁盘提案才算完成

Etcd、Zookeeper、Consul 比较

这三个产品是经常被人拿来做选型比较的。

  • Etcd 和 Zookeeper 提供的能力非常相似,都是通用的一致性元信息存储,都提供watch机制用于变更通知和分发,也都被分布式系统用来作为共享信息存储,在软件生态中所处的位置也几乎是一样的,可以互相替代的。
  • Etcd 和 Zookeeper 除了实现细节,语言,一致性协议上的区别,最大的区别在周边生态圈:
    • Zookeeper 是apache下的,用java写的,提供rpc接口,最早从hadoop项目中孵化出来,在分布式系统中得到广泛使用(hadoop, solr, kafka, mesos 等)。
    • Etcd 是coreos公司旗下的开源产品,比较新,以其简单好用的rest接口以及活跃的社区俘获了一批用户,在新的一些集群中得到使用(比如kubernetes)。虽然v3为了性能也改成二进制rpc接口了,但其易用性上比 Zookeeper 还是好一些。
  • Consul 的目标则更为具体一些,Etcd 和 Zookeeper 提供的是分布式一致性存储能力,具体的业务场景需要用户自己实现,比如服务发现,比如配置变更。而Consul 则以服务发现和配置变更为主要目标,同时附带了kv存储。
  • 在软件生态中,越抽象的组件适用范围越广,但同时对具体业务场景需求的满足上肯定有不足之处。
Home Archives Categories Tags Statistics
本文总阅读量 次 本站总访问量 次 本站总访客数