前几天我看了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基础理论的一次分享。

Raft Structure Advice

A Raft instance has to deal with the arrival of external events
(Start() calls, AppendEntries and RequestVote RPCs, and RPC replies),

Raft Locking Advice

If you are wondering how to use locks in the 6.824 Raft labs, here are
some rules and ways of thinking that might be helpful.

在现有的需求中，因业务需求还在扩充，使得前期搜集需求的过程中，很难完整的穷尽所有的处理逻辑。此时，需要一种技术，能够做到后期补充操作逻辑。在完成整体开发后，由其他开发人员进行扩展，由此，其他开发人员将无需更改应用程序的代码，更不至于重新编译整个应用程序。

在Go语言中，已知的插件系统中，可有三种选项：Hashicorp go-plugin，内置plugins软件包，以及Go Javascript解释器。