ETCD_简介+使用

ETCD_简介+使用

etcd是一个包含服务注册，监控，发现的分布式键值存储系统
分布式：Raft算法实现数据强一致性，进行负载均衡，分布式部署。
键值: store接受到http client 的API进行事务处理
存储：memory(store) + 硬盘持久化（WAL（预写入日志）+snapshot（快照））

1.etcd实现原理

从etcd的架构图中我们可以看到，etcd主要分为四个部分。

HTTP Server： 用于处理用户发送的API请求以及其它etcd节点的同步与心跳信息请求。
Store：用于处理etcd支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是etcd对用户提供的大多数API功能的具体实现。(key-value存储)
Raft：Raft强一致性算法的具体实现，是etcd的核心。（leader,foller,condidete）
WAL：Write Ahead Log（预写式日志），是etcd的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd就通过WAL进行持久化存储。WAL中，所有的数据提交前都会事先记录日志。Snapshot是为了防止数据过多而进行的状态快照；Entry表示存储的具体日志内容。
通常，一个用户的请求发送过来，会经由HTTP Server转发给Store进行具体的事务处理，如果涉及到节点的修改，则交给Raft模块进行状态的变更、日志的记录，然后再同步给别的etcd节点以确认数据提交，最后进行数据的提交，再次同步。

2.经典应用场景

1.服务发现（Service Discovery）

要解决服务发现的问题，需要有下面三大支柱：
1.一个强一致性、高可用的服务存储目录。
2.一种注册服务和监控服务健康状态的机制。用户可以在etcd中注册服务，并且对注册的服务设置key TTL，定时保持服务的心跳以达到监控健康状态的效果。
3.一种查找和连接服务的机制。通过在etcd指定的主题下注册的服务也能在对应的主题下查找到。为了确保连接，我们可以在每个服务机器上都部署一个Proxy模式的etcd（etcd反代理），这样就可以确保能访问etcd集群的服务都能互相连接。

2.消息发布与订阅

3.负载均衡

4.分布式通知与协调

5.分布式锁

6.分布式队列

7.集群监控与Leader竞选

8.为什么用etcd而不用ZooKeeper？

3.集群化应用实践（etcd集群）

4.数据存储

etcd的存储分为内存存储和持久化（硬盘）存储两部分，内存中的存储除了顺序化的记录下所有用户对节点数据变更的记录外，还会对用户数据进行索引、建堆等方便查询的操作。而持久化则使用预写式日志（WAL：Write Ahead Log）进行记录存储。 内存存储：store 持久化（硬盘）储存：WAL+ snapshot（快照）

5.Raft 算法

Leader，Follower，Candidate（候选人），分布式，负载均衡，各服务器信息同步（:2380），心跳信息（:2380） 单实例节点支持每秒1000次数据写入。

6. Store

store 处理 client 端（:2379）的http请求。(GET POST PUT DELETE WAIT(监控).....) Store这个模块顾名思义，就像一个商店把etcd已经准备好的各项底层支持加工起来，为用户提供五花八门的API支持，处理用户的各项请求。
要理解Store，只需要从etcd的API入手即可。打开etcd的API列表，我们可以看到有如下API是对etcd存储的键值进行的操作，亦即Store提供的内容。API中提到的目录（Directory）和键（Key），上文中也可能称为etcd节点（Node）。

为etcd存储的键赋值
curl http://127.0.0.1:2379/v2/keys/message -XPUT -d value="Hello world"
{
    "action": "set",
    "node": {
        "createdIndex": 2,
        "key": "/message",
        "modifiedIndex": 2,
        "value": "Hello world"
    }
}

store 进行具体的事务处理，如果涉及到节点的修改，则交给Raft模块进行状态的变更、日志的记录，然后再同步给别的etcd节点以确认数据提交，最后进行数据的提交，再次同步。 store对etcd下存储的数据进行加工，创建出如文件系统般的树状结构供用户快速查询。它有一个Watcher用于节点变更的实时反馈，还需要维护一个WatcherHub对所有Watcher订阅者进行通知的推送。同时，它还维护了一个由定时键构成的小顶堆，快速返回下一个要超时的键。最后，所有这些API的请求都以事件的形式存储在事件队列中等待处理。

7.ERCD 端口

2379用于客户端通信，2380用于节点（集群内）通信，与原先的（4001 peers / 7001 clients）共用。 配置etcd过程中通常要用到两种url地址容易混淆，一种用于etcd集群同步信息并保持连接，通常称为peer-urls；另外一种用于接收用户端发来的HTTP请求，通常称为client-urls。 peer-urls：通常监听的端口为2380（老版本使用的端口为7001），包括所有已经在集群中正常工作的所有节点的地址。 client-urls：通常监听的端口为2379（老版本使用的端口为4001），为适应复杂的网络环境，新版etcd监听客户端请求的url从原来的1个变为现在可配置的多个。这样etcd可以配合多块网卡同时监听不同网络下的请求。

8.总结

ectd 它解决了分布式场景中最为常见的一致性问题，为服务发现提供了一个稳定高可用的消息注册仓库，为以微服务协同工作的架构提供了无限的可能。

转载：https://blog.csdn.net/bbwangj/article/details/82584988