1、單個etcd節點（測試開發用）
之前我一直開發測試一直是用的一個Etcd節點，然后啟動命令一直都是直接打一個etcd（我已經將etcd安裝文件夾的bin文件夾增加到PATH環境變量中），然后啟動信息顯示etcd server監聽在默認的4001port。peer server監聽在默認的7001port。
或者指定路徑和名稱：etcd -data-dir /usr/local/etcdData/machine0 -name machine0
2、三個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/leaderWe 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節點沒有沒有關系，由於不是使用同樣的數據路徑。
3、三個Etcd節點組成Clustering的數據持久性
剛才已經把三個etcd集群的節點關掉了，如今又一次啟動這三個節點。
發現之前寫入的節點以及值都還在。說明持久性沒有問題。
然后我在/home文件夾以下找到了machines這個文件夾，將以下的三個machines,machine2,machine3所有刪掉，再次用上面的三個命令啟動集群。再次查看之前加的節點。發現已經不存在了。說明集群的數據都是存儲在其指定的數據路徑以下。
備注：所以說，如要要全然又一次使用你的etcdserver，即要清掉之前的全部數據，將文件夾刪除掉就可以。
4、三個Etcd節點組成Clustering應該訪問那個(進行操作請求)
（1）針對讀取操作三個隨意一個都能夠，即使它不是leader
（2）針對寫入操作。好像僅僅能通過連接leader來進行寫入。
我有一個由三個節點組成的集群（127.0.0.1:4001、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版本號都還沒有出來，讓我們拭目以待@！
5、必需要三個節點組成Clustering？
要構建ETCD集群，至少須要三個節點。
多於三個節點都能夠。可是一旦超過9個。ETCD集群僅僅會將當中的一個子集作為集群來執行Raft算法。其它多出來的節點將會以單獨啟動的方式執行，作為備胎。
所以3-9個最合適。
可是從以下的表能夠看出，由於涉及到寫入延遲和可靠性兩個問題，3-9之間的奇數個節點組成的集群總是最有效、最優的。
6、集群中的節點分布在多個不同機器上。效果是否一樣？
一樣。
=========== 以下內容是我從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.