etcd事件监听

    etcd是CoreOS开发的一个高可用的键值存储系统，主要用于共享配置和服务发现。它使用Go语言编写，并通过Raft一致性算法处理日志复制以保证强一致性。etcd目前的最新版本是2.2.0。

    和zookeeper的二进制接口不同，它提供了HTTP/JSON的rest api接口，所以对使用它的客户端来说是很友好的，几乎每种编程语言都有较成熟的http client开发包，基于这些开发包很容易编写etcd客户端。在java中已经有个比较好的客户端etcd4j(https://github.com/jurmous/etcd4j)，类似zookeeper有好用的curator库。

   

   etcd事件

    etcd中和数据变化（包括目录&值key、value变化）相关的事件类型有：set, delete, update, create, compareAndSwap、compareAndDelete。在etcd http response (json格式）action属性就是事件类型。

     etcd的事件watch监听接口也是使用http访问，它提供两种监听模式，一种是一次性监听，类似zookeeper的事件watch，监听到一次事件后，需要客户端重新发起监听，比较繁琐。另一种是持久监听（stream），当有事件时，会连续触发，不需要客户端重新发起监听。

     和zookeeper一样也存在客户端丢失监听事件的可能，它不保证每个事件客户端都能监听到，不过我们在实际使用过程中，通常是在应用启动时，在开始监听之后或之前先查询etcd，将需要的数据全量加载到内存中，后续才是根据监听事件来增量更新内存中的数据或全量刷新数据。另外目前版本的etcd最多只保存1千条事件历史，满1千条后，如果有新的事件产生，事件历史库中最老的事件将被丟弃，这个可以理解为etcd服务端事件丢失。由于有1千条的限制，在有事件浪涌时（在单位时间内例如1秒内产生2千条事件），事件监听处理较慢的时候或未监听时也会发生客户端事件丢失。   

 

 

    一次性watch监听

   可用curl发送http请求来进行演示，假设在本机安装有etcd，客户端访问端口为2379(旧版本监听端口为4001)，监听key为/application。一次性监听命令如下：

    curl "http://127.0.0.1:2379/v2/keys/application?wait=true"

    查询字符串中的wait=true表示监听，还可加查询参数recursive=true表示附加监听/application的子目录和后辈目录，例如curl "http://127.0.0.1:2379/v2/keys/application?wait=true&recursive=true" 。

    启动监听后etcd如有变化事件发生，则返回json格式的事件，结果类似如下：

    HTTP/1.1 200 OK

    Content-Type: application/json

    X-Etcd-Cluster-Id: e88d54f6225f06ad

    X-Etcd-Index: 271

    X-Raft-Index: 872202

    X-Raft-Term: 5

    Date: Sat, 26 Sep 2015 08:43:17 GMT

    Transfer-Encoding: chunked

 

    {"action":"set","node":{"key":"/application/store","value":"        {...}","modifiedIndex":271,"createdIndex":271},"prevNode":{...}}

   上面的curl返回结果中显示了http头，是加了curl的-i选项。

   从结果可看出action属性为set事件，modifiedIndex是该事件的index，为271。X-Etcd-Index头表示启动监听时etcd的当前index。etcd的index是单调递增的正整数，该整数