etcd -> Highly-avaliable key value store for shared configuration and service discovery

The name "etcd" originated from two ideas, the unix "/etc" folder and "d"istributed systems. The "/etc" folder is a place to store configuration data for a single system whereas etcd stores configuration information for large scale distributed systems. Hence, a "d"istributed "/etc" is "etcd".

 

Overview

　　etcd is a distributed key value store that provides a reliable way to store data across a cluster of machines. It's open-source and avaliable on GitHub.etcd gracefully handles leader elections during network partitions and will tolerate machine failure, including the leader.

　　your applications can read and write data into etcd. A simple use-case is to store database connection details or feature flags in etcd as key value pairs. these values can be watched, allowing your app to reconfigure itself when they change. advanced uses take advantage of the consistency guarantees to implement database leader elections or do distributed locking across a cluster of workers.

 

Use cases

　　Kubernets stores configuration data into etcd for service discovery and cluster management; etcd's consistency is crucial for correctly scheduling and operating services. The Kubernetes API server persists cluster state into etcd. It uses etcd's watch API to monitor the cluster and roll out critical configuration changes.　　

 

Features

• 简单：基于Http+Json的API让你用curl命名便可轻松使用，使用Go语言编写部署简单。
• 安全：可选SSL客户认证机制。
• 快速：每一个实例每秒支持1000次写操做。
• 可信：使用Raft算法充分实现了分布式。

架构

　　

从etcd的架构图中咱们能够看到，etcd主要分为四个部分：

• HTTP Server： 用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求。
• Store：用于处理etcd支持的各种功能的事务，包括数据索引、节点状态变动、监控与反馈、事件处理与执行等等，是etcd对用户提供的大多数API功能的具体实现。
• Raft：Raft强一致性算法的具体实现，是etcd的核心。Raft算法介绍：http://www.jdon.com/artichect/raft.html
• WAL：Write Ahead Log（预写式日志），是etcd的数据存储方式。除了在内存中存有全部数据的状态以及节点的索引之外，etcd就经过WAL进行持久化存储。WAL中，全部的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容。

一般，一个用户的请求发送过来，会经由HTTP Server转发给Store进行具体的事务处理，若是涉及到节点的修改，则交给Raft模块进行状态的变动、日志的记录，而后再同步给别的etcd节点以确认数据提交，最后进行数据的提交，再次同步。

 

场景1. Service Discovery

　　Service Discovery 要解决的是分布式系统中最建立的问题之一，即在同一个分布式集群中的进程或服务如何才能找到对方并创建链接。从本质上说，服务发现就是想要了解集群中是否有进程在监听TCP或UDP端口，而且经过名字就能够进行查找和链接，要解决Service Discovery的问题须要有下面三大支柱，缺一不可：

• 一个强一致性，高可用的服务存储目录。基于Raft算法的etcd天生就是强一致性高可用服务存储目录。
• 一种注册服务和监控服务监控状态的机制。用户能够在etcd中注册服务，并对注册的服务设置Key TTL, 定时保持服务的心跳以达到监控监控状态的效果。
• 一种查找和链接服务的机制。经过在etcd指定的主题下注册的服务也能在对应的主题下查找到，为了确保链接，咱们能够在每一个服务机器上都部署一个Proxy模式的etcd，这样就能够确保可以访问etcd集群的服务都能互相链接。
  

 

　　微服务协同工做架构中，服务动态添加。随着Docker容器的流行，多种微服务共同协做，构成一个相对功能强大的架构的案例愈来愈多。透明化的动态添加这些服务的需求也日益强烈。经过服务发现机制，在etcd中注册某个服务名字的目录，在该目录下存储可用的服务节点的IP。在使用服务的过程当中，只要从服务目录下查找可用的服务节点去使用便可。

 

场景二：消息发布与订阅

在分布式系统中，最适用的一种组件间通讯方式就是消息发布与订阅。即构建一个配置共享中心，数据提供者在这个配置中心发布消息，而消息使用者则订阅他们关心的主题，一旦主题有消息发布，就会实时通知订阅者。经过这种方式能够作到分布式系统配置的集中式管理与动态更新。

 

场景三：分布式通知与协调

这里说到的分布式通知与协调，与消息发布和订阅有些类似。都用到了etcd中的Watcher机制，经过注册与异步通知机制，实现分布式环境下不一样系统之间的通知与协调，从而对数据变动作到实时处理。实现方式一般是这样：不一样系统都在etcd上对同一个目录进行注册，同时设置Watcher观测该目录的变化（若是对子目录的变化也有须要，能够设置递归模式），当某个系统更新了etcd的目录，那么设置了Watcher的系统就会收到通知，并做出相应处理。

场景四：分布式锁

由于etcd使用Raft算法保持了数据的强一致性，某次操做存储到集群中的值必然是全局一致的，因此很容易实现分布式锁。锁服务有两种使用方式，一是保持独占，二是控制时序。

• 保持独占即全部获取锁的用户最终只有一个能够获得。etcd为此提供了一套实现分布式锁原子操做CAS（CompareAndSwap）的API。经过设置prevExist值，能够保证在多个节点同时去建立某个目录时，只有一个成功。而建立成功的用户就能够认为是得到了锁。
• 控制时序，即全部想要得到锁的用户都会被安排执行，可是得到锁的顺序也是全局惟一的，同时决定了执行顺序。etcd为此也提供了一套API（自动建立有序键），对一个目录建值时指定为POST动做，这样etcd会自动在目录下生成一个当前最大的值为键，存储这个新的值（客户端编号）。同时还可使用API按顺序列出全部当前目录下的键值。此时这些键的值就是客户端的时序，而这些键中存储的值能够是表明客户端的编号。

 

　　

参考资料：

http://www.infoq.com/cn/articles/etcd-interpretation-application-scenario-implement-principle