etcd终于解决冲突了
如题,etcd终于解决了一个老大难的问题,就是依赖问题,它简直不要让人再多痛苦了。
在新发布的etcd 3.5中,已经解决了对Go Module 的支持,并将之前大的 etcd 模块按功能进行了拆分,实现了 etcd 的模块化等,解决了各种 “go get fail”、依赖复杂、循环依赖、以及强制依赖过低的 gRPC
版本等问题,使用起来更简单了。
如题,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的,不过这里有一篇博客讲比较好,我就不献丑了。
假设在网络被划分的同时选出了一个新的领导者,但是旧的领导者在不同的划分中。老领导怎么知道停止提交新条目?
旧领导要么无法获得大多数成功响应(如果它在少数分区中),要么如果它可以与多数节点通信的话,则多数节点必然会与新领导的多数重叠,重叠中的服务器将告诉旧领导有一个更高的term任期。这将导致旧的领导者转变为追随者。