美文网首页
浅入深出ETCD之【简介与命令行使用】

浅入深出ETCD之【简介与命令行使用】

作者: LinkinStar | 来源:发表于2019-06-10 17:01 被阅读0次

    前言

    你知道etcd吗?随着k8s的使用广泛之后,etcd被非常多的人所知道,同时又因为它可靠的分布式特性被很多人喜欢。所以,我准备有几篇博文来记录一下,从基本使用到线上部署再到原理分析,做一个系列。那么,今天先来说说它的简介与命令行的使用。

    简介

    ETCD是什么

    我个人总结为下面用几个要点:

    • 高可用K-V存储,就类似于redis一样的键值对存储。
    • 允许应用实时监听存储中的K-V变化。
    • 能够容忍单点故障,能够应对网络分区。
    • etcd利用raft在集群中同步K-V信息,raft是强一致的集群日志同步算法。

    总结:etcd是一个分布式高可用k-v存储,通过复制达到每个节点存储的信息一致,从而保证高可用。

    数据复制

    这里简单说一下复制的具体流程:



    (client为我们的客户端,用来发出存储请求,leader和follower都是etcd的节点)
    就如图上所看到的,我叫它两段式提交:

    1. 客户端请求leader发送存储的数据,然后leader节点要将信息通过日志复制给大多数的follower节点,如上图所示,只需要复制给两个(加上它自己是三个)那么就是大多数节点。
    2. leader当复制完成之后才会本地提交,然后返回给客户端成功,(如果没有或者不能复制给大多数节点,那么则存储失败)此时再同时其他follower去他们自己本地提交。
      是不是有一种分布式事务的感觉?分布式的解决通常都是这种感觉。

    我们也可以看到,etcd通过先将数据存放在大多数节点上面从而保证数据不会出错并且效率较高,最终所有节点数据还是会同步一致的。

    • 官方给出写入的性能:1000/s

    PS:这里因为是简介,所以就简单提一下,有关如何选举出leader还有raft协议的一些具体细节,以及当出现网络分区或者节点异常问题的恢复会在之后的博客中给出。

    存储结构

    底层存储key是有序排列的
    'key' -> 'value'

    aaa/bbb -> 111
    aaa/bbc -> 3333
    bbb/aaa -> 1321
    ccc -> 24
    就是按照key的顺序依次排列,相同前缀的key会被放在一起,这样到存储结构,当查询时可以通过key的前缀将一系列的value都取出来

    watch机制和lease租约

    etcd有一个很棒的机制要单独提一句,就是watch,它允许你去监控一个key的变化。当你监控了之后,这个key的添加修改删除都会被监控到。
    lease租约,这个机制和redis中的key过期机制一样,可以申请一个租约,这个租约有一个时间限制,比如60秒,你可以将这个租约设置到一个key上,那么这个key过60秒就会被自动删除。当然也可以进行续租。

    具体使用情况,可以从后面的命令行操作中看到。

    还有一些小点

    • etcd使用grpc,所以网络性能会高
    • 部署节点数量要求是2N+1个
    • 选举leader需要半数以上的节点参与
    • etcd是支持事务操作的,可以if第一次a提交正常,then提交b,else不提交b

    本地单节点部署

    我们一开始学习和测试的时候只需要在本地部署一个单节点就可以了,单节点的部署比较方便这边简单说明一下。
    首先下载对应的版本:https://github.com/etcd-io/etcd/releases
    我这边使用的mac对应的darwin-amd64的版本,其他版本应该类似。
    下载解压之后有两个文件比较重要:

    • etcd 这个是节点
    • etcdctl 这个是客户端
      进入所在目录使用命令进行启动和使用

    使用节点命令

    ➜  ./etcd
    

    使用客户端命令

    ➜ ./etcdctl
    NAME:
       etcdctl - A simple command line client for etcd.
    
    WARNING:
       Environment variable ETCDCTL_API is not set; defaults to etcdctl v2.
       Set environment variable ETCDCTL_API=3 to use v3 API or ETCDCTL_API=2 to use v2 API.
    

    之后会出现上述类似警告,告诉你,默认使用的是v2版本的API,你需要设置环境变量ETCDCTL_API=3就能使用v3版本的API了,这里我们使用命令export ETCDCTL_API=3

    或者你可以手动修改环境变量添加export ETCDCTL_API=3就可以了,当不出现警告的时候证明环境变量设置正确。

    简单命令行操作

    下面介绍几个最基本的etcd的操作,其实非常简单。主要与redis不同的是拥有独特的watch机制,这个机制非常棒。

    put

    ➜ ./etcdctl put /aaa/a 1
    OK
    ➜ ./etcdctl put /aaa/b 2
    OK
    

    get

    ➜ ./etcdctl get /aaa/a
    /aaa/a
    1
    ➜ ./etcdctl get --prefix /aaa
    /aaa/a
    1
    /aaa/b
    2
    

    --prefix意思是取出所有前缀为/aaa的key

    watch

    新开一个窗口使用命令watch进行监听

    ➜ ./etcdctl watch /aaa/a
    

    然后对/aaa/a这个key的操作全部都会被监听到

    ➜ ./etcdctl put /aaa/a 123
    OK
    ➜ ./etcdctl del /aaa/a
    1
    
    ➜ ./etcdctl watch /aaa/a
    PUT
    /aaa/a
    123
    DELETE
    /aaa/a
    

    lease

    创建一个60s的租约

    ➜ ./etcdctl lease grant 60
    lease 694d6b2b7d7e6a0c granted with TTL(60s)
    
    ➜ ./etcdctl put /aaa/a 123 --lease=694d6b2b7d7e6a0c
    OK
    

    put的时候使用租约注意,这里需要输入上面租约的16进制标识符
    然后监听的地方会发现,60秒后,/aaa/a这个key被自动删除了

    当然你可以使用keep-alive进行续租,如:

    ➜ ./etcdctl lease keep-alive 694d6b2ac4a35625
    

    总结

    以上简单说明了etcd的一些基本信息,单节点部署,以及一些基本用法,从上述信息我们总结可知:

    1. etcd是分布式的,能保证在单点故障下也能正常使用
    2. 分布式也会导致问题,etcd写入性能相较redis肯定有所不及
    3. etcd独特的watch机制可以用于很多场景,如配置更新分发等

    那这里就说这么多,看完你就应该大致知道etcd是个啥玩意了,从现在看来你可能还没有感觉它有什么厉害的地方,后面我们结合实际的场景使用就能更加明白了。

    相关文章

      网友评论

          本文标题:浅入深出ETCD之【简介与命令行使用】

          本文链接:https://www.haomeiwen.com/subject/gkvzxctx.html