算是很久没有写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:sdm 维护了一个很重要的东西就是 route。route是以shard为单位的每一个shard都会有个对应的route。sdk 每次要 put/get/delete 的时候会先拿 db_name 和 table_name 去 sdm 查询路由表然后根据 key 算出对应的 shard再从 shard 的 replica 列表里面找到 leader 节点最后把真正的 KV 请求发给 storage。另外sdm还会负责 storage 节点的注册和心跳。storage 启动之后会向 sdm 注册自己然后周期性发送 heartbeat。 heartbeat 不只是告诉 sdm 目前节点还没有掉点还会把本机 replica 的状态、raft role、成员信息leader会传这些发过去sdm 也会在 heartbeat response 里面下发期望的 Replica让 storage 的 NodeAgent 在本机创建、删除 replica或者做成员变更。sdm 和 storage 这边用的就是经典的观测-期望sdm 维护期望状态再让 NodeAgent 去收敛。自动 rebalance 的话就没考虑再做了再做也赶不上秋招了还有由于 sdm 需要提供 route这边sdk的链路是通过提供db_name table_name key向sdm查询一下路由表所以sdm这边需要有table的概念也需要知道每个table下面有多少个shard。table里面还有 ReplicaGroup 这一层每个shard都会对应了一个group用来维护这个shard希望有几个副本、哪些replica是当前还想保留的成员。而shard作为我们的逻辑数据所以并没有在sdm里面专门出现通过ReplicaGroup Route的方式在代码层面实现的。由于我们用的经典的观测期望所以关于后台任务的话现在主要靠几类后台reconcile去推动状态TableReconciler 负责判断 table 是否 ready/deletingReplicaGroupReconciler 负责根据 target_replica_count 去补副本、删副本、替换坏副本Route 负责在 replica ready 之后发布可用路由。说起来还是稍微有点绕的但是核心想法其实就是把“应该是什么样子”和“现在实际是什么样子”不断对齐。之后等到要讲 sdm 的时候再细讲吧。StorageMinimal architecture diagram:storage 负责数据的读写前面的 meta 和 sdm 更偏控制面一些一个负责元信息一个负责路由和节点状态storage 这边是真正处理 put/get/delete 请求以及维护数据副本的地方。拿 put/delete 操作来说sdk 直接把请求打到对应 shard 的 leader 所在的 storage 节点上。打向storage写请求之后这个写请求就会进入 replica 内部交给 raft 做复制。首先本地会写一条 raft log然后发送给其他的 follower等待这个 log 被多数派确认并且提交之后会 apply 到 KV engine。当前版本里的 KV engine 还是一个比较简单的 map engine主要是为了先把分布式链路跑通。后续有考虑接入rocksdbmaybemaybe考虑get操作来说的话其实目前也只是leader-only的状态最终的读请求也只会打到leader上。不过搞了个读一致性在读之前会确认自己仍然是合法 leader并确保本地状态机至少 apply 到对应的 read index避免读到旧 leader 或者还没 apply 完的状态。除此之外storage 还做了 WAL 和 snapshot 相关的持久化逻辑当前实现里WAL 主要承载的是 Raft log用来记录每个 replica 的写入日志snapshot 则保存已经 apply 之后的 KV 状态。服务重启时可以通过 snapshot 加上后续 WAL 恢复 replica 状态。V1的局限其实目前还有很多没有完成的内容例如Meta 和 SDM 在V1版本里只打算做单进程没有高可用Storage侧目前的 kv engine 直接用了map还没有接入rocksdb关于 shard 目前不支持 split也没有实现自动 rebalance目前只支持 leader put 和 read不支持follower read写在最后最开始写完这个blog是6月12号但是后来又进行了大规模的重构并且加上了支持扩缩容这个功能为了这个功能真的是重构了好多好多拖到现在都有一个月了。为啥要支持扩缩容是我当时想结束这个项目的时候了解到了tinykv这个项目然后发现它的完全体几乎是全方面吊打我的项目了所以悲痛欲绝想着怎么也得多实现个功能吧不然太小丑了。再给我一次机会我可能就不会写这个项目了直接去实现tinykv不香吗…)以上大体上讲了下这个项目其实这个项目算是完成的不太好应该会有很多设计不太合理的地方。毕竟我也没有系统的学习过分布式很多东西也是边看、边查、边问、边写出来的。很多设计甚至并没有一开始就想清楚的经常写到一半然后发现不对再慢慢修修补补出来的。