TiKV探索101
之前使用tiup工具部署了下，使用dashboard的时候发现cluster info里的主机信息有的错的，有的是缺的，后来还发现诊断报告里也有类似的问题，于是着手准备追踪看看然后提交PR。后来发现正好有个捉虫比赛的活动，于是全都报告到那边了。追踪过程中把那些信息的获取路径跟了下，知道了采集每个服务的主机信息（硬件信息）的时候是怎么实现的。算是第一次深入到TiKV的代码里。
之前使用tiup工具部署了下，使用dashboard的时候发现cluster info里的主机信息有的错的，有的是缺的，后来还发现诊断报告里也有类似的问题，于是着手准备追踪看看然后提交PR。后来发现正好有个捉虫比赛的活动，于是全都报告到那边了。追踪过程中把那些信息的获取路径跟了下，知道了采集每个服务的主机信息（硬件信息）的时候是怎么实现的。算是第一次深入到TiKV的代码里。
这个小结晚了8天，Lab3在20号已经完成了。
11号可以稳定过3A，3B一直持续到15号，只剩一个测试经常跑不过，但更细致的检查是会有大量goroutine泄露。还发现rpc的响应时间还会影响我的测试结果，我的rpc测试延迟明显过高（花了好多时间来分析，最后发现是因为用了-race检查，我说开始考虑先忽略次要问题，但是10x的延迟是在觉得是个大问题，得先解决，等最后发现是-race的问题，深刻理解了-race会10x降速程序），为此特别加了对所有的rpc延迟统计、所有临界区、labgob、persister延迟统计，加了这些改造后，还遇到了lab2在nightly测试中失败的情况。为了验证程序正确性，用了6台云服务器不间断跑untilfail测试，发现lab2仍有问题后，返工继续lab2改造，经过这段时间，已经感觉越来越可控了。
本来以为2C很快就结束了，因为在2月29日晚上只是加了读写持久化存储就可以跑过多数测试了，只有2个测试挂掉。为了修复这个问题，开始不断做修改，以至于甚至连最初的选举都影响了，前面的测试各种被break掉，一直只用到atomic包，规避用锁，自己也知道风险，3月开始的前4天非常挫败。3月4号下午开始准备加锁，之后一直修改到3月7号，已经越来越可控，越来越有感觉了。7号晚上可以跑untilfail的测试了，测试40多分钟都没有问题，然后就交到作业提交网站了。
下午3点多终于把2B的测试全过了。
这几天一个一个地过，调试log全部混杂在一起，很不容易看。
2B部分的代码质量写得比较差，后面又有尾大不掉的问题，不敢擅动，怕影响之前的结果。
先前花了点时间把TestFailNoAgree2B不过的问题解决掉，具体问题限制也想不起来了。只写下今天完成的这俩。
一个leader被选出来之后立即开始接受客户端请求
每一个客户端请求包含一个等待被执行的命令
leader将命令作为一个新entry追加到自己的日志中，然后并行分发AppendEntries RPC给其他机器
如果entry被安全的复制了，leader就这个entry应用到自己的状态机上，然后将执行结果返回给客户端
弄到凌晨1点钟，才算可以稳稳地跑Lab2A的测试。一共花了好几天来实现，Raft的论文并没有完全指明所有细节，还得自己考虑，另外因为只是做选举部分，因为先看了后面的选举限制部分，还有log部分，选举等到2B实验做完应该还要调整一些地方。
Lab2A实验比我预想花的时间要长，论文那一小段也反反复复扣了N遍。
昨天终于把Lab1写完，用测试脚本跑了一遍，第一把就全通过了。
今天记一下这个过程中值得记录的一些点。
有这样一个场景，对于每个任务，我在初始化时给它们的状态都是0，然后如果有worker来要任务，我分配出去后，会把状态设置为1，代表处理中或者running的意思，如果worker处理完会上报处理完这个消息，master接到之后会给状态设置为2，代表已处理完成。为了防止worker不上报处理结果（可能worker宕机，可能网络问题），需要在master这边对每一个下发的任务设置一个定时器，约定10s内如果没有收到状态报告，就认为worker处理这个任务失败，那么就把状态由1改回0，也就是恢复到未分配模式，等到下一轮任务分发时，可以重新下发这个任务。