如题，etcd终于解决了一个老大难的问题，就是依赖问题，它简直不要让人再多痛苦了。

在新发布的etcd 3.5中，已经解决了对Go Module 的支持，并将之前大的 etcd 模块按功能进行了拆分，实现了 etcd 的模块化等，解决了各种 “go get fail”、依赖复杂、循环依赖、以及强制依赖过低的 gRPC 版本等问题，使用起来更简单了。

引言

对于后端来说，可能都会从入门的HTTP，到后面的Server RPC阶段，在实践中GRPC确实好用，调用其他服务和调用一个似的，没什么区别，而且相对于HTTP来说，功能更强劲，扩展性更强。

当我们使用gateway作为HTTP—GRPC的转换器后，前端既可以直接通过HTTP访问后端服务的GRPC接口，不需要多开发一个HTTP Server，而且引入GRPC后好处还不止这些。

之前对ETCD中实现的MVCC了解了一点，现阶段了解MySQL也看到了这一部分，还是比较有收获的，以前写代码虽然有注意，但是没有这么深入理解过，所以有些代码现在看来，依然是有瑕疵的。

下面会讲到一致性，我这里查过了，MySQL中的一致性，和ETCD、ZK中的一致性不是同一个东西，这个知乎回答比较好，但没有说明两者的区别。当然这里是一个事务中的，一个各副本间进行线性读操作的，从实际上来看，貌似就有不同。

MySQL中的索引，一般来说，我们使用的比较多的是b+tree，hash索引。

且因为在MySQL中，存在不同的存储引擎，这两种索引存在的形式也有些不大一样。这里我们也只引入MyISAM和Innodb存储引擎。

前几天我看了Raft关于一致性读的操作，让我对于Raft - 扩展阅读这篇论文以及ETCD中读操作有了一些理解。

在实际的使用的这类服务中，写操作可能是比读操作少的，当我们需要优化读写性能时，就需要做一些功夫了。

和ETCD中很像的zookeeper，两者定位可以说都是非常相似的，在zk中，当zk节点越多，读性能相对越强，而在ETCD中，明显和这种情况不同，因为读写请求都需要leader进行响应，且还需要做一个Raft Log同步的操作，这也就会造成，节点多了，反而会导致性能下降。zk使用的zap协议，类似Raft一般，也是去维护日志，但却不影响zk的读取性能。为什么会造成这一现象呢？

始末

在看到曹大的一篇微信文章，是读书的一篇总结，其中就有写到关于Change log文档的问题，文章中有提到说国外很多开源项目，都是根据commit自动维护的，而国内还没有普及这种。

我感觉这个倒是触及了我的知识盲区的，之前确实没了解过，借此我去研究了一下，亲身尝试下来，还是挺方便的。

etcd中有着和Mysql类似的多版本并发控制（MVCC），同样都是为了解决对高并发环境下数据冲突的问题。

本来准备研究一下MVCC的，不过这里有一篇博客讲比较好，我就不献丑了。

MVCC 在 etcd 中的实现

假设在网络被划分的同时选出了一个新的领导者，但是旧的领导者在不同的划分中。老领导怎么知道停止提交新条目？

旧领导要么无法获得大多数成功响应（如果它在少数分区中），要么如果它可以与多数节点通信的话，则多数节点必然会与新领导的多数重叠，重叠中的服务器将告诉旧领导有一个更高的term任期。这将导致旧的领导者转变为追随者。

做了一个关于Loki的简单分享，也是因为在项目中有使用到它，现在使用大多还是单体，还没有说需要上到分布式的场景，此处既是对Loki基础理论的一次分享。