写在开头也算是很久没有写blog了上次写还是OB复赛打完了之后写的一篇凄凄惨惨的总结文一晃半年过去了。没想到距离自己上次写随笔都是半年前的事情了。先简单交代一下自己的背景吧自从比赛打完了之后就开始准备找实习了找实习其实并没有我想象中很困难我大概面了有五六家字节的基架OB的数据库内核开发还有一些小厂的杂七杂八游戏引擎自动驾驶等等刷刷面试经验。本来是打算投字节给面试OB涨点经验的结果没想到字节的效率太快了没几天就发了offer。最后自己纠结了下害怕自己选择数据库内核后路走窄了就想着去基础架构试试吧。后来是差不多实习了有1个月吧发现自己实习基本上没有学到什么实际的代码开发都没有多少每天就是在排查问题简单的改点代码测试性能之类的我就在想如果我保持现在这样到秋招自己恐怕到时候成废物了而组内的项目代码又不可能会让我来参与实际代码开发我总得另寻出路。恰巧组内的项目是做分布式KV的那不如了解清楚组内的项目然后我去写一个自己的分布式KV。好歹以后面试的时候发现我的实习内容很水我可以狡辩一下说自己私下学习组内项目自己搓了个分布式KV出来有点小丑的是由于自己设定的场景和组内的不同以及V1版本的功能方面没办法实现的很全面导致自己魔改了之后可以说除了模块名字几乎和组内的项目都不沾边了。至此以上就是我打算写这个分布式KVAdvisKV的想法了。其实也有点想抱着做出来自己的一个代表作的想法毕竟之前写的那些rmdbminiobseekdb的代码都不算是我自己的项目。开始写这个文档的时候项目基本上完成的差不多了吧benchmark起码可以完整跑通bushi。 想着架构啥的肯定不会大改了并不是这样的后来又重构了很多顶多就是后期可能再会尝试优化下性能以及删除我项目里面加的乱七八糟的注释所以差不多就可以开笔了。AdvisKV 是什么简单来说AdvisKV 是我用 C17 写的一个分布式 KV 存储系统原型。实现它的原因说的功利一点就是希望可以秋招体面一点。顺带其实也希望可以完成自己的第一个从头开始搞的项目。希望各位不要期望太高定位并没有多高就是一个学习向系统的原型罢了。大概概括这个项目的主线的话就是 Meta/SDM 作为控制面维护表、副本和路由的期望状态Storage 作为数据面负责 KV 读写和 Raft 复制控制面和数据面通过心跳和 reconciler 不断把系统状态收敛到预期。这个项目里面大概分成四个模块Meta 负责DBTable这些元数据和DDL。SDM 负责 Storage 节点注册、心跳、ReplicaGroup 编排、期望副本下发和 Route 维护。Storage 负责 KV 数据读写、Raft 和本地持久化。SDK 对外提供基于 db table key 的put/get/delete 接口。目前这个项目可以跑通建库建表路由查询KV的读操作写操作副本数调整自动替换坏了的副本raftWALsnapshotrecover等这些功能然后目前有两百多个gtest单测一批E2E测试例如最基础的端到端 KV 链路leader崩溃后切主follower追日志和追snapshotMeta/SDM重启恢复啊等等等等还有benchmark和metrics。关于详细的内容和数据这里就不详说了我更想的其实是写关于这个项目的自我感受一直以来就是这个样子所以就不写的那么官方味了。这里贴上github地址: https://github.com/advisedy/adviskv 想了解的可以去README里面查看。Show这个分布式KV的数据模型就像和正常的数据库差不多会有dbtable的概念。用户可以创建自己的DB然后在DB里面创建table。每一个 table 在创建的时候可以指定 shard 数和 replica 数。一个 table 会被拆成多个 shard每一个 shard 又会有多个 replica。这里需要说明一下V1 版本里 shard 数是在创建 table 的时候确定的后续暂时不能动态修改replica 数现在可以通过 alter_table 去调整也支持缩到 0 再扩回来。也就是说目前不是完全没有扩缩容只是支持的是副本数这条链路自动 rebalance 和 shard 数变更还没有做以后应该也不会做了吧这个项目应该已经要到此为止了。routeros项目里提供了一个交互式 CLI adviskvctl 方便进行演示(AI大哥跑的我只是简单看了看)建库建表adviskv create_db demo_db dc1OK db_id1create_table resource_pooladviskv create_table demo_db demo_table 4 3 defaultOK table_id1wait_table [timeout_ms]adviskv wait_table demo_db demo_tableOK table_stateNORMALputadviskv put demo_db demo_table hello worldOKgetadviskv get demo_db demo_table helloOK value“world”adviskv delete demo_db demo_table helloOKrouteadviskv route demo_db demo_table helloRoutetable: demo_db.demo_tablekey: helloshard: table_id1 shard_id2replicas:- replica_id1:2:0 endpoint127.0.0.1:50051 roleLEADER- replica_id1:2:1 endpoint127.0.0.1:50052 roleFOLLOWER- replica_id1:2:2 endpoint127.0.0.1:50053 roleFOLLOWERkey hello 会先定位到 table 某个 shard然后 SDK 再通过 SDM 查询该 shard 对应的 route通过 route 上的 endpoint最终把请求发送到对应的 leader 的 Storage 节点这里是副本的扩容缩容alter_tableadviskv alter_table demo_db demo_table 2OK table_id1 replica_count2然后关于这个KV我们目前支持的操作就是最基本的同步的putgetdelete。关于这些操作是交给我们的sdk模块使用的。我们可以创建一个KVClient进行putget等操作。这里顺手说一下CLI 里面命令可以写 deleteSDK 里面对应的方法名叫 del。这个是我们简单的SDK的使用方式arduino#include#include “sdk/client.h”int main() {adviskv::sdk::KVClientConf conf;conf.db_name “demo_db”;conf.table_name “demo_table”;conf.sdm_host “127.0.0.1”;conf.sdm_port 50049;conf.sdm_timeout_ms 3000;conf.storage_timeout_ms 3000;adviskv::sdk::KVClient client(conf); adviskv::Status put_status client.put(hello, world); if (put_status.fail()) { std::cerr put_status.to_string() std::endl; return 1; } adviskv::Value value; adviskv::Status get_status client.get(hello, value); if (get_status.ok()) { std::cout value std::endl; // value:world } return 0;}Minimal Overview整体架构的粗略介绍这个项目主要是分为了四个模块: metasdm storage sdk。SDK先来说一下最外层的sdksdk其实本身并不算是隶属在分布式KV里面的服务端模块它就是一个客户端库给使用者执行putget这种操作。拿 put 操作来说在当前版本里sdk 会先向 sdm 查询 route也就是路由表。这个 route 里面包含当前 db/table 对应的 shard 信息以及每个 shard 下面的 replica 节点信息。sdk 根据 key 算出它应该落在哪一个 shard 上然后从这个 shard 的 replica 列表里面找到 leader 节点然后直接给这个节点发送put操作。删除操作也是这个样子。值得一提的是在我们的V1版本里面get操作也是只有leader才可以执行。后续版本会考虑优化这里MetaMinimal architecture diagram:这个模块主要负责 DDL 和 DB/Table 这些元信息。创建 table 的时候请求会先打到 Meta。Meta 收到 CreateTable 之后会先在自己的 catalog 里面记录这个 table并把 table 状态标记成创建中的状态。然后 Meta 会向 SDM 发送 PlaceTable 请求让 SDM 去负责后续的 replica 放置和 route 生成。这里需要注意的是CreateTable 返回成功并不一定代表这个 table 立刻就已经可以读写了。这个接口本身是一个异步操作返回的OK只是代表meta这边接受了这个DDL并不保证DDL最后一定会成功。后续 table 是否真正 ready主要是取决 Meta 和 SDM 里的后台 reconciler 能否把状态推进到最终状态。后面做副本数调整之后这里也多了 AlterTableReplicaCount。用户发起 alter_table 的时候Meta 会先把 catalog 里面的 replica_count 和状态改掉然后通知 SDM 去把每个 shard 的目标副本数调到新值。这个过程也不是同步等所有 replica 都调整完最后还是靠后台 reconciler 推回来。而创建db这种操作的话就不会发送给sdm因为像DB这边的概念是只有meta才会知晓的概念sdm那边不会在乎db也不会持久化db。sdm侧应当只会关心table以及对应的shard_count和replica_count来进行编排。虽然sdk通过传递db_name和table_name和hash(key)找到路由表但是db_name这个其实是附在table上的所以对于db而言不需要往sdm知道sdm只需要了解到table的内容其实就可以了。SDMMinimal architecture diagram: