搜集赏
1 | 总会有光明的东西的，在未来。 |
——《像少年啦飞驰》韩寒
如题，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的，不过这里有一篇博客讲比较好，我就不献丑了。