搜集赏
1 | 总会有光明的东西的，在未来。 |
——《像少年啦飞驰》韩寒
之前对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任期。这将导致旧的领导者转变为追随者。