csdnYF的博客

本文想讨论一些ETCD的使用注意事项，ETCD作为一个分布式KV数据库，作用有很多，下面以用ETCD作为配置中心来举例，用到了ETCD关键的两个功能：Watch和Revision。Watch可以实时推送配置变更，而Revision可以回溯配置的历史变更列表。关于Revision的概念，请参考在ETCD中，老实说对Revision的概念支持的不是很好，虽然标榜自己是可以回溯历史版本的，但我找了半天，除了一个--rev参数，没有找到更多的API来利用这些历史版本。可以通过。

适合阅读本文的人群对Raft协议感兴趣的人看过一些Raft相关介绍的博文，但是看不懂的（比如我）很多Raft相关的分析文章，或者是著名的《In Search of an Understandable Consensus Algorithm》 论文，都会把下面的一张图放出来：再介绍选主、日志复制、状态机等一系列概念，恕我直言，真是看的人昏昏欲睡。也许有的表述确实看懂了，可正如古人所说，纸上得来终觉浅，要知此事需躬行。Raft协议跟我们日常写代码有什么关系，我们到底能不能用上它呢？我个人觉得.

书接上文，继续分析Client端Watch流程的关闭流程的处理。首先我们再回顾下Watch中的关键角色和设计理念：角色说明watcher对外接口Watcher的实现，重点是Watch()方法watchGrpcStream桥梁，管理内部GRPC连接、管理内部的虚拟Stream、消息接收和分发watchClient对应底层的GRPC连接客户端watcherStream虚拟的Stream，处理服务端和客户端的通信要分析关闭流程，我们首先来找找有哪些情况会导致关

书接上文，我们在《ETCD源码分析Client端启动流程分析》中，深入源码查看ETCDClient端如何启动，如何向Server建立GRPC连接的。在本文中，我们继续探究ETCD的Client端是如何实现Watch逻辑的。由于Watch逻辑整体还是比较复杂的，建议观看本文的小伙伴，把ETCD的V3.5版本源码打开，对比着文章查看。ETCD源码Watch启动流程首先对Watch流程进行分解，先介绍下ETCD客户端是如何启动Watch的。Watch模块通过Watcher接口对外提供三个功能：Wat

ETCD源码基于v3.5，在分析之前，需要搭建好源码分析的环境。首先，从GitHub的仓库中克隆下ETCD的源码，再利用docker搭建我们的ETCD测试集群，命令如下：REGISTRY=quay.io/coreos/etcdNAME_1=etcd-node-0NAME_2=etcd-node-1NAME_3=etcd-node-2# IP在不同机器上不同，请查看docker的子网网段HOST_1=172.20.0.2 HOST_2=172.20.0.3HOST_3=172.20.0.4