背景

2021 年 11 月 ~ 2022 年 1 月 ，PingCAP 举办了第一届 Talent Plan KV 学习营，相关介绍可参考 推送。

在本次比赛中，由于我们小组的两位成员之前都刷过 MIT 6.824，已经对教学级别的 raft 有一定的了解，所以参加此次比赛的目的就是去感受一下生产级别分布式 KV 的代码实现，学习实践一下 lsm, etcd, raftstore 和 percolator 的理论知识和 codebase。

u1s1，刷 lab 的过程十分曲折，我们俩所在的实验室到年底的时候都非常忙，前几周基本每周都只能抽出顶多一两天的时间来写代码，而理解 lab2b/lab3b raftstore 的难度是非常大的，我们用了一周多的时间才勉强看懂 raftstore 的代码。这使得到还剩两周时间的时候，我们才刷到 lab2c。最后两周我们利用中午午休时间和晚上睡觉时间疯狂加班，在 lab 上花了更多的时间，最后才堪堪刷完。

在刷 lab 的过程中，由于时间有限，我们始终秉持着学习优先，成绩第二的原则。即以 了解 codebase，学习知识，做最容易做且最有用的优化 为主，并没有去卷很多功能点。在处理 bug 的态度上，对于 safety 的问题比如错误读写的 bug 等，我们对这类问题进行了重点关注和解决；对于 liveness 的问题比如 request timeout 等，我们则是在有限的时间内尽力做了优化，但并没有投入太多精力，因为这种工作没有上限，tikv 的 raftstore 也一定在持续做这些工作，时间不够的情况下去卷这些就没有太大意义了。

出人意料的是，我们得了第二名的好成绩，具体可参考 官宣。事后反省一下，在 safety 上我们遇到的问题都解决了；在 liveness 上我们没投入太多精力；在文档上，我们简单介绍了代码实现，但将重点放在了我们对相关知识的理解和思考上；在性能上，我们重点做了最容易做的 batching 优化，其本质上是使用 raft 的优化而不是 raft 自身的优化，但对性能的提升却异常关键，比如 tidb 对于一个事务打包的一堆写请求，到 tikv 的 region 之后，这些写请求同步成一条还是多条 raftlog 对于性能的影响是巨大的。

从结果来看，我们的策略是正确的，我们在很有限的时间内拿到了很高的收益。

最后，出于对课程的保护，也出于跟大家分享一些刷 lab 的经验，让大家少踩坑，在此处我仅将文档公开，希望能为大家提供一些思路，欢迎一起交流。

文档

lab1

解题思路

Part 1 : Implement a standalone storage engine

本部分是对底层 badger api 的包装，主要涉及修改的代码文件是 standalone_storage.go, 需要实现 Storage 接口的 Write 和 Reader 方法，来实现对底层 badger 数据库的读写。

1.Write 部分实现思路

Write 部分涉及到 Put 和 Delete 两种操作。

因为 write_batch.go 中已经实现了对 badger 中 entry 的 put 和 delete 操作，我们只需要判断 batch 中的每一个 Modify 的操作类型，然后直接调用 write_batch.go 中相对应的方法即可。

2.Reader 部分实现思路

Reader 部分会涉及到 point read 和 scan read 两种不同读方式。

因为提示到应该使用 badger.Txn 来实现 Reader 函数，所以我们声明了一个 badgerReader 结构体来实现 StorageReader 接口，badgerReader 结构体内部包含对 badger.Txn 的引用。

针对 point read，
我们直接调用 util.go 中的 GetCF 等函数，对 cf 中指定 key 进行读取。

针对 scan read，
直接调用 cf_iterator.go 中的 NewCFIterator 函数，返回一个迭代器，供 part2 中调用。

Part 2 : Implement raw key/value service handlers

本部分需要实现 RawGet/ RawScan/ RawPut/ RawDelete 四个...