Etcd学习（二）集群搭建Clustering
1、单个etcd节点（测试开发用）
之前我一直开发测试一直是用的一个Etcd节点，然后启动命令一直都是直接打一个etcd（我已经将etcd安装目录的bin目录加入到PATH环境变量中），然后启动信息显示etcd server监听在默认的4001端口，peer server监听在默认的7001端口。
或者指定路径和名称：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全部删掉，再次用上面的三个命令启动集群，再次查看之前加的节点，发现已经不存在了，说明集群的数据都是存储在其指定的数据路径下面。
备注：所以说，如要要完全重新使用你的etcd服务器，即要清掉之前的所有数据，将目录删除掉即可。
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.