分布式系统基石etcd

简介

—-Distributed reliable key-value store for the most critical data of a distributed system，etcd是一个高可用的键值存储系统，主要用于共享配置和服务发现。etcd是由CoreOS开发并维护的，灵感来自于 ZooKeeper 和 Doozer，它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强一致性。

分布式系统

一个系统的演变，包含数据与服务，从集中到集群再到分布。在系统初始时，功能简单结构单一，服务与数据在一台机器上。随着系统使用的增加和功能的扩展，系统会遇到瓶颈，难以支撑，为了解决这个瓶颈，可以对数据或者服务水平扩展，采用集群部署增加其节点，用以负载均衡，使得系统性能提升，随着业务与用户的增长，这种靠集群方式提升性能往往不是直线提升（机器与性能不成正比），当达到这个瓶颈的时候，仅仅靠单一的增加节点是不现实的，为了解决这个问题，这个时候，分布式出现了，把数据和服务二维拆分（水平和垂直），分散在多台机器上。分布式系统的出现，使得系统变得复杂，数据和服务难以管理，这个时候需要由专门的分布式工具去管理，市面上有专门这样的产品（zookeeper、etcd、consul）

为何选择go实现

系统用户指数的增长，引发高并发，很多后端高级语言（java、.net、php）处理高并发采用的方案往往是增加线程，一个连接创建一个线程，或者采用线程池，以此来提高性能。学过操作系统的同学应该都清楚，进程和线程是操作系统最重要的概念，一个进程包括多个线程，标准线程是操作系统调度的基本单位，线程需要占用内存资源，普通的线程需要消耗1M的堆栈，切换线程执行需要消耗cpu资源，这就意味这线程数不是越多越好，线程越多操作系统切换消耗的资源越高。所以千万级并发实现的秘密：内核不是解决方案，而是问题所在。为了解决这个问题，go语言引入了Coroutine-协程模型，coroutine本质上是一种轻量级的thread，它的开销会比使用thread少很多，多个coroutine可以按照次序在一个thread里面执行，简单来说：协程十分轻量，可以在一个进程中执行有数以十万计的协程，依旧保持高性能。开发分布式系统管理产品，当然选择一个处理并发架构良好的语言为佳。etcd和consul不约而同的采用go实现，还有当下火热的docker。

有兴趣的同学可以查看这篇文章：http://blog.csdn.net/ghj1976/article/details/27996095

优势

一致性协议： etcd[Raft]协议， ZK使用ZAB（类PAXOS协议），前者容易理解，方便工程实现；
运维方面：etcd方便运维，ZK难以运维；
项目活跃度：etcd社区与开发活跃，ZK已经快死了；
API：etcd提供HTTP+JSON, gRPC接口，跨平台跨语言，ZK需要使用其客户端；
访问安全方面：etcd支持HTTPS访问，ZK在这方面缺失；
etcd性能支持上万次读写

核心—-Raft协议

     etcd使用Raft协议来维护集群内各个节点状态的一致性。简单说，etcd集群是一个分布式系统，由多个节点相互通信构成整体对外服务，每个节点都存储了完整的数据，并且通过Raft协议保证每个节点维护的数据是一致的。

     如图所示，每个etcd节点都维护了一个状态机，并且，任意时刻至多存在一个有效的主节点。主节点处理所有来自客户端写操作，通过Raft协议保证写操作对状态机的改动会可靠的同步到其他节点。
     etcd工作原理核心部分在于Raft协议。主要分为三个部分：选主，日志复制，安全性。

1. 选主,Raft协议是用于维护一组服务节点数据一致性的协议。这一组服务节点构成一个集群，并且有一个主节点来对外提供服务。当集群初始化，或者主节点挂掉后，面临一个选主问题。集群中每个节点，任意时刻处于Leader, Follower, Candidate这三个角色之一

2.日志复制,所谓日志复制，是指主节点将每次操作形成日志条目，并持久化到本地磁盘，然后通过网络IO发送给其他节点。其他节点根据日志的逻辑时钟(TERM)和日志编号(INDEX)来判断是否将该日志记录持久化到本地。当主节点收到包括自己在内超过半数节点成功返回，那么认为该日志是可提交的(committed），并将日志输入到状态机，将结果返回给客户端。

3.安全性，针对与特殊情况的一些处理，保证Leader挂机和选举冲突情况处理数据一致性。

etcd3特性

1.远程调用，etcd3客户端使用grpc协议进行通信，协议消息使用protobuf进行定义，它简化了PRC客户端存根代码的生成并且使协议易于管理，并且，gRPC在处理链接方面优势明显，因为gRPC使用单一链接的HTTP2多路复用流式RPC调用，而JSON客户端必须为每个请求建立一个链接

2.租约，etcd3中的租约替代了早期TTL的实现。租约减少了保持活动的请求并限制了平稳状态一致性更新。与一个键一个TTL不同，一个租约包含一个TTL，租约被分配给一个键。当租约生命到期了，它所关联的所有键全被删除。这个模型在很多键有相同的租约时减少了保持活性的通信量。保持活性的链接也不会像在etcd2中那样被回收，而是使用多路复用的gPRC流的方式来保持活性

3.观察者，etcd3的多路复用观察者使用一个链接。与每次都打开一个新连接不同，客户端会在一个双向gRPC流中注册一个观察者。流会发送一个带有观察者注册ID的事件。多个观察流甚至可以共享相同的TCP链接。多路复用和流式链接共享减少了至少一个数量级的etcd3的内存占用。

安装使用

到gitgub官网下载etcd并且安装https://github.com/coreos/etcd/releases
etcd客户端通信采用的grpc，下载https://github.com/coreos/jetcd/tree/master/src/main/proto auth.proto、kv.proto、rpc.proto文件，本地编译打包生成客户端
grpc不清楚的同学可以查看博主的github使用demo：https://github.com/yeyincai/grpc-demo
简单使用的话可以参考这里的demo: https://github.com/yeyincai/etcd-demo