⑴ etcd简要使用
etcd is a strongly consistent, distributed key-value store that provides a reliable way to store data that needs to be accessed by a distributed system or cluster of machines.
从定义可以看到，etcd是一个key-value型存储，具有强一致性
etcd的客户端有etcdctl、etcd-go、etcd-java，其中etcdctl是etcd自带的命令行工具，其主要命令有
etcd的数据是按照B+树的方式组织，并按照MVCC的思想存储数据，也就是数据按照多个版本存储，每个版本都有一个版本号，当数据更新时，并非更新原有数据，而是再存储一条新版本号数据。
在内存中，实际上有两个B+树，一个存储key到revison的映射，一个存储revison和value的映射。当进行get的时候，先到key-revison映射中查找revison，如果未制定版本号，就取最新的revison，然后用revison到revison-value的B+树查找value。
为什么要用B+树，因为要支持范围查找。
本文总结etcd的简要使用，下篇再对底层原理进行解析。
⑵ RPC 框架使用 Etcd 作为注册中心
对 etcd 来说,键值对( key-value pair )是最小可操作单元，每个键值对都有许多字段,以 protobuf 格式定义。
除了键和值之外， etcd 还将附加的修订元数据作为键消息的一部分 。该修订信息按创建和修改的时间对键进行排序，这对于管理分布式同步的并发性非常有用。etcd客户端的分布式共享锁使用创建修改来等待锁定所有权。类似地，修改修订用于检测软件事务内存读集冲突并等待领导人选举更新。
申请租约
授权租约
撤销
租约续约
⑶ go-micro的etcd服务注册管理界面使用方法
我们在使用consul时，consul提供了管理界面，可很直观的看到我们注册到consul的服务及健康状况。
etcd并未提供此功能，但是我们可以使用go-micro提供的一个简易界面查看我们注册到etcd中的服务
本文是基于【docker+etcd+go-micro api网关的搭建及使用】： https://www.jianshu.com/p/13d1df6e6731 ，这篇文章的环境基础来实现的，没有搭建docker+etcd+go-micro api网关的，可以按照上面的链接搭建一遍。
启动这个管理界面也是使用go-micor的镜像来操作，只是指令上有些变化，在启动api网关时，我们使用的是api指令，如下：
docker run -d -p 8080:8080 --name=micro_api_gw ba526346c047 --registry=etcd --registry_address=192.168.109.131:12379 --api_namespace=api.tutor.com --api_handler=http api
这里我们使用web指令,如下：
docker run -d -p 8082:8082 --name=micro_etcd_monitor ba526346c047 --registry=etcd --registry_address=192.168.109.131:12379 --api_namespace=api.tutor.com web
启动完成后，在浏览器输入 http://192.168.109.131:8082/registry ，就可以看到如下界面（192.168.109.131是我的虚拟机ip，可以根据自己的机器调整）：
今天就介绍到这里
⑷ ETCD中K8S的元数据
假设你已经通过kubeadm 安装好了K8S 和对应的etcd集群
Kubenretes1.6中使用etcd V3版本的API，使用etcdctl直接ls的话只能看到/kube-centos一个路径。需要在命令前加上ETCDCTL_API=3这个环境变量才能看到kuberentes在etcd中保存的数据。
如果是使用 kubeadm 创建的集群，在 Kubenretes 1.11 中，etcd 默认使用 tls ，这时你可以在 master 节点上使用以下命令来访问 etcd ：
-w指定输出格式
将得到这样的json的结果：
使用--prefix可以看到所有的子目录，如查看集群中的namespace：
输出结果中可以看到所有的namespace。
key的值是经过base64编码，需要解码后才能看到实际值，如：
etcd中kubernetes的元数据
我们使用kubectl命令获取的kubernetes的对象状态实际上是保存在etcd中的，使用下面的脚本可以获取etcd中的所有kubernetes对象的key：
注意，我们使用了ETCD v3版本的客户端命令来访问etcd。
通过输出的结果我们可以看到kubernetes的原数据是按何种结构包括在kuberentes中的，输出结果如下所示：
我们可以看到所有的Kuberentes的所有元数据都保存在/registry目录下，下一层就是API对象类型（复数形式），再下一层是namespace，最后一层是对象的名字。
以下是etcd中存储的kubernetes所有的元数据类型：
转自
⑸ kong网关怎么获取etcd端口
etcd简介与应用场景 etcd 是一个分布式一致性k-v存储系统,可用于服务注册发现与...
2.
单机模式运行 默认在centos7的yum源里已集成了etcd包,可以通过yum进行安装...
3.
集群模式说明 这里的集群模式是指完全集群模式,当然也可以在单机上通过不同的端口,部署伪...
4.
静态模式 如果只是测试,这里建议使用二进制包进行测试。因为源码包编译的,使用etcd命令...
5.
动态配置 静态配置前提是在搭建集群之前已经提前知道各节点的信息,而实际应用中可能
⑹ kubernetes控制平面组件：etcd
--listen-peer-urls
--listen-client-urls
--initial-advertise-peer-urls
--initial-cluster
--initial-cluster-state
--advertise-client-urls
1.code
headless svc, 像DNS RR ClusterIP:None
kubectl -n stg1 get endpoints
client 怎么访问：
2.配置文件
3.apply
官方的code有两个问题
本地访问
扩容
利用反亲和性 分布etcd pod到不同节点
~ ❯❯❯ etcdctl get / --prefix
从 etcd 的架构图中我们可以看到，etcd 主要分为四个部分。
etcd 目前支持 V2 和 V3 两个大版本，这两个版本在实现上有比较大的不同，一方面是对外提供接口的方式，另一方面就是底层的存储引擎，V2 版本的实例是一个纯内存的实现，所有的数据都没有存储在磁盘上，而 V3 版本的实例就支持了数据的持久化。
v3默认boltdb
consortium etcd2+mysql
数据默认会存放在 /var/lib/etcd/default/ 目录。我们会发现数据所在的目录，会被分为两个文件夹中，分别是 snap 和 wal目录。
解决三个问题：节点选举、日志复制以及安全性 。
每一个 Raft 集群中都包含多个服务器，在任意时刻，每一台服务器只可能处于 Leader 、 Follower 以及 Candidate 三种状态；在处于正常的状态时，集群中只会存在一个 Leader 状态，其余的服务器都是 Follower 状态。
所有的 Follower 节点都是被动的，它们不会主动发出任何的请求 ，只会响应 Leader 和 Candidate 发出的请求。对于每一个用户的可变操作，都会被路由给 Leader 节点进行处理，除了 Leader 和 Follower 节点之外，Candidate 节点其实只是集群运行过程中的一个临时状态。
每一个服务器都会存储当前集群的最新任期，它就像是一个单调递增的逻辑时钟，能够同步各个节点之间的状态，当前节点持有的任期会随着每一个请求被传递到其他的节点上。Raft 协议在每一个任期的开始时都会从一个集群中选出一个节点作为集群的 Leader 节点，这个节点会负责集群中的日志的复制以及管理工作。
客户端通过 监听指定的key可以迅速感知key的变化并作出相应处理 ，watch机制的实现依赖于 资源版本号revision的设计 ，每一次key的更新都会使得revision原子递增，因此根据不同的版本号revision的对比就可以感知新事件的发生。etcd watch机制有着广泛的应用，比如利用etcd实现分布式锁； k8s中监听各种资源的变化 ，从而实现各种controller逻辑等。
watch机制的实现主要可分为三个部分
client使用 watchClient 的watch接口发起watch请求，与server端建立一个 gRPCStream 连接。
server端会为每个client生成唯一一个watch id，并记录每个client也就是watcher监听的key或者key range，通过recvLoop接收client请求，通过sendLoop发送请求，server端只负责收发请求和响应。
主要的实现都放在了watchalbStore层，watchalbStore会监听key的变化，然后通过syncWatchersLoop和syncVictimsLoop两个处理流程将key的更新变化包装成event，通过channel发送给gRPC server。
MVCC（Multiversion Concurrency Control）多版本并发控制机制
场景1:
这就是悲观锁
悲观锁：悲观得认为并发事务会冲突，所以要先拿锁，拿到锁的作修改操作
场景2
数据库：写回磁盘，A写好了。哎，B和C都是version 13，我咋写？算了，报错吧。。
就是乐观锁，默认不加锁，你尽管写，冲突我认怂！乐观锁其实不是锁，只是相对悲观锁来定义，适合读多写少。
乐观锁：乐观得认为数据不会冲突，但发生冲突时要能检测到。
场景3
这就是MVCC，在 MVCC 数据库中，你更新一个 key-value 数据的时候，它并不会直接覆盖原数据，而是 新增一个版本来存储新的数据，每个数据都有一个版本号 ，版本号是一个逻辑时钟，不会因为服务器时间的差异而受影响。
MVCC不等于乐观锁！
--rev 查的是main
在底层boltdb里，实际分布是这样的：
底层的key是revision，/奥特曼是用户key，“他很帅”就是用户value
删除
之前有delete动作，但是依然有版本记录。为什么？
删除这个动作，其实etcd是在blotdb里写了一条，“删除用户/奥特曼”
此时有个问题：用户说我的确删除了啊，真的不要了！请把空间还给我啊！
回收 compact（压缩）
etcdctl compact {version}
compact 需要一个版本号。这个版本号就是写事务递增的那个版本号，compact 12345，就是说把版本12345以前的 标记删除了的数据 释放掉，用户没删除的数据肯定不能回收。
如何压缩：
注意修改go.mod
Watch
服务发现要解决的也是分布式系统中最常见的问题之一，即在同一个分布式集群中的进程或服务，要如何才能找到对方并建立连接。本质上来说，服务发现就是想要了解集群中是否有进程在监听 udp 或 tcp 端口，并且通过名字就可以查找和连接。
需要实现的功能；
discover.go
eBay payment
ebay kubernetes 控制面架构
问题
⑺ 使用etcd分布式锁做主备切换
利用etcd事务机制可以实现分布式锁，利用分布式锁可以做主备切换功能。
Etcd分布式锁实现方式如下：利用etcd事务机制向etcd创建key，若key不存在则创建key，获取锁成功，若key存在则获取锁失败.
主备切换功能实现思路如下：各程序向etcd抢锁，抢到锁即为主，没抢到为从，从程序会监视锁是否释放，若锁释放重新抢锁。考虑到在网络不稳定的情况下，可能出现已经成为主的程序失去了锁的拥有，某一个从程序抢到了锁，但是已经成为主的程序并不知道自己失去了锁，因此成为主的程序需要抢到锁后不断查询目前锁是否为自己拥有，若已经失去则标记自己为从并且重新抢锁。
具体实现如下：
参考
https://studygolang.com/articles/16307?fr=sidebar
https://www.jianshu.com/p/d3068d0ac7c1
https://yq.aliyun.com/articles/70546
"go.etcd.io/etcd/clientv3/concurrency"包的example_mutex_test.go/session.go/mutex.go/key.go