Raft实现报告（20）

客户端的交互

上节讲到了给每个执行的命令赋予序列号，那么接收到相同序列号的命令代表已经执行过了，不会重复执行。

无需将任何内容写入日志即可处理制度操作。

但是，如果没有额外的措施，这将冒着返回陈旧数据的风险，因为响应请求的leader可能已经被他不知道的新leader取代了。线性化读取不能返回陈旧数据，Raft需要两个额外的预防措施来保证这一点，而不是用日志。

首先，leader必须拥有提交的条目的最新信息，leader完整性的特性保证leader拥有所有一提交的条目，但是从其的起始term开始，它可能不知道那些是哪些。要找到他们，他需要从其任期内提交一个条目，Raft通过让每个leader在其任期开始向日志中提交一个空白的条目，来处理这个问题。

然后，leader必须在处理制度请求之前检查它是否已经被废除（如果选举了更新的leader，其信息可能是陈旧的）。Raft通过让leader在响应时只读请求之前与大多数集群交换心跳信息来处理这个问题。或者leader可以依靠心跳机制来提供一种合约形式，但这将依赖于安全时间。

实现与评估

Raft的实现大约2000行C++代码，不包括测试，注释，或空白行。源代码http://github.com/ logcabin/logcabin。而根据他们论文相关的独立实现也有25个第三方开源的，都处于不同的开发阶段。
http://raftconsensus.github.io.