Raven's Blog

0. 要求·

本次lab为raft的第一分部(PartA), 原文要求在这里

简述lab2A的要求为：

实现Raft中leader election和心跳，保证一个term内只有一个leader，并且leader可通过心跳保证其 leader 角色。 如果发生leader crash或者leader网络丢失，需要达到新leader自动take over旧leader。

所有修改均在 raft.go 文件内。

这里简述下raft目录下的其他文件的作用：

1
2
3
4
5
6

.
├── config.go		-- 测试时会使用到该文件，用于模拟各种场景
├── persister.go	-- 持久化raft state
├── raft.go			-- raft算法
├── test_test.go	-- 单元测试
└── util.go			-- 工具类，目前只包含了一个 DPrintf, 辅助调试

0. 前言·

从这篇文章开始开一个新坑 – MIT-6824， 分布式系统。早就将这门课纳入了必学的课程规划中，因为从学习编程到现在，我所学过的东西都是单机的，对分布式颇感兴趣，而这门课也是和 CMU15445, MIT6828等知名课程的同级别课程，于是选中了本门课。

本次课程选用的是，MIT6824 Spring 2020。

杂谈golang: 由于本门课程的所有lab均采用golang实现，所以花了几天的时间学习了golang，还好之前对C、C++语言比较熟悉，golang学习起来比较轻松，在整个lab实现过程中，我发现我非常喜欢这门语言，在语言语法，语言工具链，调试工具等方面都做得非常好。唯一让我迷惑了一段时间的是go语言的包管理，虽然现在统一采用了module来管理，但是包括部分tutorial和mit6824的lab都没有基于最新的module来做，所以这需要花费时间来了解下go语言的包管理历史。

ok，废话不多说。本文主要是对lab1的一个实现记录与总结。

0. 要求·

文本为 CMU15445 - Proj4 的题解 。Proj4 为Concurrency Control，本次proj分为三个任务：

1. Lock Manager
2. Deadlock Detection
3. Concurrent Query Execution

总体来说，难度低于proj2， 高于proj3和proj1。不过还是有不少坑。下面简单来说说。

原文要求：https://15445.courses.cs.cmu.edu/fall2020/project4/

0. 前言 & 要求·

断更了3个月，终于忙完了毕设，现在开始补课。文本为 CMU15445 - Proj3 的题解 。Proj3 为QueryExecutor，要求实现多个 executors，从而达到以下操作：

• Access Methods: Sequential Scans, Index Scans (with your B+Tree from Project #2)
• Modifications: Inserts, Updates, Deletes
• Miscellaneous: Nested Loop Joins, Index Nested Loop Joins, Aggregation, Limit/Offset

所有的执行器，采用 iterator query processing model, 即所有的 executor 向外暴露一个 Next 接口，ExecutorEngine 通过调用 Next接口得到一条tuple， 这种 processing model 为 pipeline style processing。

详细要求如下：

• Task 1: 实现一个 System Catalog: Catalog为数据库的核心数据结构之一，描述着数据库内部表和索引的元数据，存储着数据库中 有哪些table， 每个table的schema是怎么样的，每个table有哪些index， index有哪些元数据等等。
• Task 2: 实现多个执行器，包括：Sequential Scan, Index Scan, Insert, Update,Delete， Nested Loop Join, Index nested loop join， Aggregation， Limit.

总体来说，本实验难度比proj1高，比proj2低。

1. 要求·

checkpoint2 是在 checkpoint1的基础上，实现B+树的删除、迭代器和并发访问操作（并发访问只用支持point search， insert和delete，不用支持range scan)。

具体要求参见：这里

总体来说，这部分相对第一部分会更难一些。

0. 前言·

从这个proj开始，难度上升了很多个档次，做起来明显吃力。

proj2要求实现一个线程安全的B+ tree。收货满满。

1. 要求·

原文要求参考：https://15445.courses.cs.cmu.edu/fall2020/project1/

这是cmu15445的第一个proj，目标是实现一个简单的buffer pool。具体来看，整个proj需要实现两个类：一个LRUReplacer和一个BufferPoolManager。

0. 前言 & 踩坑记录·

大半年没有更新过博文，忙着毕设，春招，实习，秋招一系列事情，一直在鸽。最近算是有点时间来充充电了。学生时代还剩下最后一年，跨专业后CS课还有相当多没补，立个flag，未来一年把cmu15445（数据库）, mit6824（分布式）, cs16c（计组）（cs16c待定，可能会换成18447）课程+lab/proj补完，6.828（操作系统）则看情况了，OS理论知识是有的，希望自己有时间能够实现一个小OS吧。

okk，闲话到此，今天简单聊聊CMU15445+proj环境搭建+proj0.

近期重学CMake，为后续的开发做点准备。遇到PUBLIC|PRIVATE和INTERFACE三个关键字不是很理解，搜索了一些资料，最后发现这篇文章说得比较浅显易懂。

CMake: Public VS Private VS Interface

本文在他的基础上，加上了一些实际验证的例子。

至此，我们已经基本分析完整个leveldb，本文给出leveldb中的各组件的默认大小。

• log 文件，由一系列的32kb物理块组成。

• manifest 文件，目前来看未限制其大小，但是在系统Open时，有一次机会重新**（文件大小超过2M）**开辟一个新的manifest，并移除旧文件。这部分在ReuseManifest函数中有体现：