Etcd學習（二）集羣搭建Clustering

一、單個etcd節點（測試開發用）

以前我一直開發測試一直是用的一個Etcd節點，而後啓動命令一直都是直接打一個etcd（我已經將etcd安裝文件夾的bin文件夾增長到PATH環境變量中），而後啓動信息顯示etcd server監聽在默認的4001port。peer server監聽在默認的7001port。

或者指定路徑和名稱：etcd -data-dir /usr/local/etcdData/machine0 -name machine0

二、三個Etcd節點組成Clustering

而後今天想測試一下集羣功能，就依照gutHub上面的教程：

參考：https://github.com/coreos/etcd/blob/master/Documentation/clustering.md

Let start by creating 3 new etcd instances.

We use -peer-addr to specify server port and -addr to specify client port and -data-dir to specify the directory to store the log and info of the machine in the cluster:

./etcd -peer-addr 127.0.0.1:7001 -addr 127.0.0.1:4001 -data-dir machines/machine1 -name machine1

Note: If you want to run etcd on an external IP address and still have access locally, you'll need to add -bind-addr 0.0.0.0so that it will listen on both external and localhost addresses. A similar argument -peer-bind-addr is used to setup the listening address for the server port.

Let's join two more machines to this cluster using the -peers argument. A single connection to any peer will allow a new machine to join, but multiple can be specified for greater resiliency.

./etcd -peer-addr 127.0.0.1:7002 -addr 127.0.0.1:4002 -peers 127.0.0.1:7001,127.0.0.1:7003 -data-dir machines/machine2 -name machine2
./etcd -peer-addr 127.0.0.1:7003 -addr 127.0.0.1:4003 -peers 127.0.0.1:7001,127.0.0.1:7002 -data-dir machines/machine3 -name machine3

備註：

We can also get the current leader in the cluster:

curl -L http://127.0.0.1:4001/v2/leader

We can retrieve a list of machines in the cluster using the HTTP API:

curl -L http://127.0.0.1:4001/v2/machines

打開三個終端將上面三個命令都原本來本運行了一下。

而後運行Get操做查看我以前單個節點時加進去的節點的內容：

curl -L http://127.0.0.1:4002/v2/keys/configA

結果發現key not found的提示。難道在原來一個節點的基礎上加了兩個節點組成一個集羣。會致使以前的數據丟失？

後來研究了一下這個命令。發現指定了數據存儲路徑，我猜測：

（1）僅僅要同一時候執行的etcd命令<IP。 Port>不衝突，可以同一時候啓動多個etcd節點。

（2）即時啓動在不一樣一時候間啓動在一樣<IP。Port>上，僅僅要數據路徑指定的不同。也不是同一個etcd節點。

因此我果斷關掉剛纔打開的這三個終端。仍是用執行我曾經的那個etcd命令（默認啓動在哪一個數據路徑我還不知道），而後執行Get操做查看我以前單個節點時加進去的節點的內容：

curl -L http://127.0.0.1:4002/v2/keys/configA

發現內容都在。看來我後來啓動的這三個組成clustering的etcd節點和我以前啓動的那個etcd節點沒有沒有關係，因爲不是使用一樣的數據路徑。

三、三個Etcd節點組成Clustering的數據持久性

剛纔已經把三個etcd集羣的節點關掉了，現在又一次啓動這三個節點。

發現以前寫入的節點以及值都還在。說明持久性沒有問題。

而後我在/home文件夾如下找到了machines這個文件夾，將如下的三個machines,machine2,machine3全部刪掉，再次用上面的三個命令啓動集羣。再次查看以前加的節點。發現已經不存在了。說明集羣的數據都是存儲在其指定的數據路徑如下。

備註：因此說，如要要全然又一次使用你的etcdserver，即要清掉以前的所有數據，將文件夾刪除掉就能夠。

四、三個Etcd節點組成Clustering應該訪問那個(進行操做請求)

（1）針對讀取操做三個隨意一個都可以，即便它不是leader

（2）針對寫入操做。好像僅僅能經過鏈接leader來進行寫入。

我有一個由三個節點組成的集羣（127.0.0.1:400一、127.0.0.1:4002以及127.0.0.1:4003），有一個鏈接到集羣開啓定時器定時註冊服務（其實是定時建立帶TTL的Node）的程序。例如如下所看到的：

string sysFlag = "CBIP";
            IRegistryCenterClient rCenter = RegistryCenterClientFactory.GetRegistryCenterClient();

            ServiceInfo sInfo1 = new ServiceInfo();
            sInfo1.serviceName = "HelloService";
            sInfo1.serviceIP = "127.0.0.111";
            sInfo1.servicePort = 1888;
            rCenter.RegisterService(sInfo1);

            while (true)
            {
                Console.WriteLine(rCenter.GetConfigItem(sysFlag, "configA"));
                Console.WriteLine(rCenter.GetConfigItem(sysFlag, "configB"));
                Thread.Sleep(200);
            }

我鏈接到的是集羣中的127.0.0.1:4001節點，開始的時候集羣的leader是127.0.0.1:4001，但是隨着時間推移leader會產生變化。可能會變成127.0.0.1:4002或者127.0.0.1:4003。我發現一個結論： 僅僅要leader是127.0.0.1:4001，服務就行成功註冊(成功寫入集羣)。僅僅要leader不是127.0.0.1:4001，就會註冊失敗！而循環中讀取配置項會一直有效，不會隨着leader的變化失效。

問題： 爲何我依照這個教程啓動的三個節點的集羣，隨時時間推移，leader會變來變去？？？

etcd還比較新，現在還在不斷開發中。1.0版本號都尚未出來，讓咱們拭目以待@！

五、必須要三個節點組成Clustering？

要構建ETCD集羣，至少需要三個節點。

多於三個節點都可以。但是一旦超過9個。ETCD集羣僅僅會將當中的一個子集做爲集羣來執行Raft算法。其它多出來的節點將會以單獨啓動的方式執行，做爲備胎。

因此3-9個最合適。

但是從如下的表可以看出，因爲涉及到寫入延遲和可靠性兩個問題，3-9之間的奇數個節點組成的集羣老是最有效、最優的。

六、集羣中的節點分佈在多個不一樣機器上。效果是否同樣？

同樣。

===========  如下內容是我從ETCD的GutHub上面翻譯而來 ==============

Optimal etcd Cluster Size

etcd的Raft一致性算法在比較小的集羣（3-9個節點）上面最有效，對於超過9個節點的集羣，etcd將會選擇所有節點的一個子集來運行Raft算法。以便保證有效性。

Cluster Management

你可以經過 cluster config API.來管理活躍的集羣的大小， activeSize 描寫敘述了etcd集羣活躍節點（etcd peers）的數目。

假如etcd實例的總數超過了這個數目。那麼多出來的節點（peers）將會以獨立（standbys）的方式啓動，假如集羣中一個活躍的節點掛掉或者被移除掉，那麼這些多出來的單獨啓動的節點將會增長到活躍集羣中。

Internals of etcd

Writing to etcd

寫一個etcd節點老是會被重定向到這個集羣的leader。以及被分發到集羣中所有的節點，僅僅有當大多數節點（Majority --- 參見如下的表）確認這個寫入操做成功了，那麼這個寫入纔算是成功的。

好比。一個有個節點的集羣。那麼一個寫入操做最快也要等成功寫了三個節點纔算寫入成功。這就是爲何節點數目最好小於9的緣由。咱們需要考慮寫入的高性能（低延遲）。

Leader Election

領導者選舉過程相似於寫一個key。集羣中大多數的節點需要認可這個新的領導者，才幹繼續集羣相關的操做。

Odd Active Cluster Size

一個重要的集羣優化策略是要保障集羣中活躍節點的數目(i.e. activeSize)始終爲奇數個。

比方你看3個節點與4個節點對照，5個節點與6個節點對照，7個節點和8個節點對照： Majority數目添加了，致使寫入操做延時更高了，但是Failure Tolerance數目並無不論什麼添加。就能夠靠性（贊成掛掉的節點數）沒有添加。

Active Peers	Majority	Failure Tolerance
1 peers	1 peers	None
3 peers	2 peers	1 peer
4 peers	3 peers	1 peer
5 peers	3 peers	2 peers
6 peers	4 peers	2 peers
7 peers	4 peers	3 peers
8 peers	5 peers	3 peers
9 peers	5 peers	4 peers

如你所見，添加新的節點獎集羣中節點數目變成奇數個老是值得的。

During a network partition, an odd number of active peers also guarantees that there will almost always be a majority of the cluster that can continue to operate and be the source of truth when the partition ends.