ETCD如何处理读写请求

主要就是etcd的leader和follower间的关系

写请求处理：

客户端发起写操作时，例如将x=1，随机从etcd集群中挑一个地址，如果挑的是follwer，那么他会把请求转发给leader，如果客户端挑的是leader那就不需要转发该请求了；

leader首先在本地写个日志，然后发起一个议案，议案的内容就是分发日志给follower，看看是否能达成共识， 如果议案所有follower都达成共识，那么leader就进行数据提交，开始写数据，数据写完后，leader会把结果返回给客户端，告诉客户端数据已经写成功了；同时leader会要求各follower进行写操作，follower什么时候能修改不一定。

读请求处理：

如果此时客户端马上发起了一个读请求，请求对应的正好是leader，那么leader返回的是x=1；

如果此时客户端读请求对应的是follower，follower收到请求后，会首先要求leader给回一个commit-index，follower根据leader返回的commit-index，与自己的commit-index对比判断自己的数据是否是最新，如果是最新那么返回x=1给客户端，如果发现commit-index与leader的不一致，那么他就需要等待，等自己的状态变更后再返回给客户端，如果在一定的时间内没有更新成最新版本的数据，那么他就遵从线性一致性原则，会给客户端回一个follower中记录的最新的值，这个最新的值未必就是真正的与leader一致的最新的值。

主要是因为在follower提交修改数据请求，和最终数据修改成功之间会有一个时间差，如果客户端在这个时间内来follower读取数据，那么返回的不一定是最新的数据。