淺入深出ETCD之【簡介與命令行使用】

前言

你知道etcd嗎?隨着k8s的使用普遍以後,etcd被很是多的人所知道,同時又由於它可靠的分佈式特性被不少人喜歡。因此,我準備有幾篇博文來記錄一下,從基本使用到線上部署再到原理分析,作一個系列。那麼,今天先來講說它的簡介與命令行的使用。git

簡介

ETCD是什麼

我我的總結爲下面用幾個要點:github

  • 高可用K-V存儲,就相似於redis同樣的鍵值對存儲。
  • 容許應用實時監聽存儲中的K-V變化。
  • 可以容忍單點故障,可以應對網絡分區。
  • etcd利用raft在集羣中同步K-V信息,raft是強一致的集羣日誌同步算法。

總結:etcd是一個分佈式高可用k-v存儲,經過複製達到每一個節點存儲的信息一致,從而保證高可用。redis

數據複製

這裏簡單說一下複製的具體流程:

(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秒就會被自動刪除。固然也能夠進行續租。測試

具體使用狀況,能夠從後面的命令行操做中看到。spa

還有一些小點

  • 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是個啥玩意了,從如今看來你可能尚未感受它有什麼厲害的地方,後面咱們結合實際的場景使用就能更加明白了。

 

http://www.linkinstar.wiki/

相關文章
相關標籤/搜索