TiKV 贡献指南从开发环境搭建到首个 Pull Request 的完整实践【免费下载链接】tikvDistributed transactional key-value database, originally created to complement TiDB项目地址: https://gitcode.com/GitHub_Trending/ti/tikvTiKV 是 Rust 实现的分布式事务型 Key-Value 数据库最初为补充 TiDB 而诞生。本文基于仓库根目录的 CONTRIBUTING.md 展开结合 Makefile、rust-toolchain.toml、doc/maintenance-guides/ 等仓库实文件系统讲解在本地构建、运行、测试 TiKV 的完整流程以及从提 Issue、写提交信息到提交 PR 的协作规范。读完本文你将掌握一套可复现的开发工作流配好工具链、跑通make dev全量检查、用 Docker 或 nextest 测试、按项目规范提交变更并用 LocalStack 在本地验证 AWS 集成代码。TiKV 社区为贡献者准备了入门路径导航图指出不同背景的开发者适合的贡献方向开发环境搭建前置依赖TiKV 主要由 Rust 编写同时包含 C 组件RocksDB、gRPC并使用 Rust nightly 工具链。开始前至少需要安装工具用途git版本控制rustupRust 安装器与工具链管理器make构建工具驱动常见工作流cmake构建工具gRPC 需要awk模式扫描/处理语言被构建脚本使用protocGoogle Protocol Buffer 编译器C 编译器gcc 5 或 clanggRPC 需要如果目标平台不是 x86_64/aarch64 的 Linux 或 macOS还需要额外安装llvm和clang用于生成不同平台的绑定并构建原生库grpcio、rocksdb 依赖。获取仓库git clone https://github.com/tikv/tikv.git cd tikv # 后续所有指令均假设已位于该目录配置 Rust 工具链rustup是 Rust 官方工具链管理器。TiKV 通过仓库根目录的 rust-toolchain.toml 将工具链固定到指定 nightly 版本rustup与cargo会自动读取该文件无需手动切换[toolchain] channel nightly-2026-01-30 components [rustfmt, clippy, rust-src, rust-analyzer] profile minimal从该文件可以看到除了固定 nightly 版本外还声明了rustfmt、clippy、rust-src、rust-analyzer组件并以minimalprofile 避免安装多余组件。若组件缺失可显式安装rustup component add rustfmt rustup component add clippy构建、格式化与测试标准构建与增量检查TiKV 的 Makefile 封装了常见工作流并统一了构建环境。也可以用cargo直接构建为了避免因环境差异导致重复编译建议让命令在 Makefile 同一环境中运行方法是在命令前加scripts/env前缀./scripts/env cargo build查看 scripts/env 的实现可知它本质上是把收到的命令转交给make run去执行从而复用 Makefile 注入的环境变量与 feature 组合。正式构建make build查看 Makefile 中buildtarget 的实现它设置TIKV_PROFILEdebug以--no-default-features --features ${ENABLE_FEATURES}方式调用cargo build。ENABLE_FEATURES默认已包含memory-engine、jemallocLinux 下还附加mem-profiling、portable、sse等特性当TIKV_FRAME_POINTER1默认开启时还会强制加入-Cforce-frame-pointersyes并启用pprof-fp以保证稳定的 CPU 采样栈回溯。交互式开发阶段更适合用cargo check——只做语法解析、借用检查与 lint不产出二进制cargo check --allmake devPR 前的完整自检准备提交变更前应运行devtarget。它依次做格式化、启用 clippy 的构建并跑测试。按 Makefile 定义dev: format clippy env FAIL_POINT1 make test即make devformatclippy 开启 failpoints 特性FAIL_POINT1会令ENABLE_FEATURES追加failpoints后的全量测试。提交 PR 之前应保证它能无失败跑完。部分测试偶发不稳定或并非在所有平台通过遇到疑问可以向社区提问确认。make dev运行测试套件可以单独跑测试套件也可以只跑某个具体测试# 运行完整测试套件 make test # 运行指定测试--nocapture 输出打印内容 ./scripts/test $TESTNAME -- --nocapture # 或通过 make 环境变量方式 env EXTRA_CARGO_ARGS$TESTNAME make testmake test实际调用 scripts/test-all。该脚本先执行 scripts/test 做一次工作区全量cargo test排除 fuzz 相关 crate在 Linux 上还会以MALLOC_CONFprof:true重跑ifdef_malloc_conf测试最后用--message-formatjson-render-diagnostics -q --no-run编译一次并用 scripts/check-bins.py 校验产物。scripts/test内部通过make run复用 Makefile 环境自动追加docker_test容器内等特性并导出LOG_LEVELDEBUG、RUST_BACKTRACEfull便于排查。也可以用 nextest 运行测试env EXTRA_CARGO_ARGS$TESTNAME make test_with_nextest对应 Makefile 中的test_with_nextesttarget它将CUSTOM_TEST_COMMAND设为nextest run --nocapture并开启 doctest 持久化选项。格式化与静态检查TiKV 遵循 Rust 社区代码风格使用 Rustfmt 与 Clippy 自动格式化并检查代码这两项在 CI 中会被强制校验make dev也已包含# 运行 Rustfmt make format # 运行 Clippy注意部分 lint 被忽略直接 cargo clippy 会产生大量误报 make clippy值得说明的是为什么文档强调直接cargo clippy会误报查看 Makefile 中clippytarget它在 scripts/clippy-all 之外还依次执行check-redact-log、check-log-style、check-dashboards、check-docker-build、check-license、deny等仓库自有检查脚本format则除了cargo fmt还会用cargo-sort按CARGO_SORT_VERSION锁定版本校验 Cargo.toml 中依赖的排序。在 Docker 中跑测试也可以在 Docker 环境内运行测试make docker_test它会基于 Dockerfile.test 构建pingcap/tikv_dev镜像并运行 TiKV 单元测试之后可直接复用该镜像做临时测试。从 Dockerfile.test 可以看到测试镜像的构成基于 Rocky Linux 8安装 make/git/gcc/cmake/curl/protoc 等构建依赖安装 Rust 工具链后预装cargo-nextest并将工作目录挂载为/tikv。运行过程中会出现大量看似报错的信息其实并非错误而是 rustc/cargo 的输出例如jemalloc: Invalid conf pair: prof:true构建疑难与调优为降低编译时间与磁盘占用TiKV 默认不包含完整调试信息只有测试包启用行号级 debuginfo。需要调试信息时用RUSTFLAGS覆盖RUSTFLAGS-Cdebuginfo1 make dev RUSTFLAGS-Cdebuginfo1 cargo build-Cdebuginfo1只保留行号-Cdebuginfo2保留完整调试信息。用 make 构建时cargo 会自动启用流水线pipelined编译提升并行度直接用 cargo 时需显式开启CARGO_BUILD_PIPELININGtrue cargo build关于 FIPS如果在 macOS 上以ENABLE_FIPS1构建参见仓库内 Dockerfile.FIPSTiKV 仍会启用gcp_v2FIPS 路径此时需要自行向进程提供匹配的aws_lc_*FIPS.dylib例如通过DYLD_LIBRARY_PATH等标准 macOS 动态库搜索路径。运行 TiKV要把 TiKV 作为真实 Key-Value 存储运行需要以集群方式启动单节点集群即可用于测试可在单机或多机上完成。集群由 PDPlacement Driver管理即使是单机单节点也不例外。官方部署文档提供了完整安装与启动步骤若从源码构建可跳过下载安装包一步tikv-server位于target目录下。仓库内也有配套参考如 doc/deploy.md部署说明与 doc/http.mdHTTP 状态接口。两个实用提示建议将进程可打开文件数上限提高到 82920 以上否则运行高负载测试时可能触发文件描述符不足WSL2 用户若修改ulimit遇到困难可参考社区相关讨论见原文档指引。配置文件TiKV 的全部配置项以带注释模板的形式存放在仓库根目录的 etc/config-template.toml 中它是理解各配置项含义的第一手资料在线文档中的配置指南与之一一对应。日常部署时复制该模板并修改即可。贡献流程整体工作流一个典型的贡献者工作流大致如下确认想贡献的内容已有关联 Issue 跟踪规则见下文链接 Issue社区会在 Issue 中讨论问题与方案从基础分支通常是 master创建 Git 分支编写代码、补充测试用例并提交提交信息格式见下文运行测试并确保全部通过将改动推送到 fork 的分支并提交 Pull Request提交信息中必须提及第 1 步创建的 IssuePR 进入评审评审可能要求修改改动后 PR 需重新评审并获得批准PR 过期时可直接使用 GitHub 的 update branch 按钮出现冲突时可在本地合并解决后推送仅解决冲突不必重新评审但若有显著改动应请求重新评审仓库的 CI 系统会自动测试所有 PR社区的 bot 负责合并 PR评论/merge即可触发要求测试通过且有两个 approve可能需要请评审人操作。TiKV 的代码文档Rustdoc可作为理解代码库的补充资料。维护指南变更前的必读材料TiKV 在 doc/maintenance-guides/ 下维护了一套面向维护者与评审者的指南而不是面向用户的说明书。这套指南服务于四个问题哪个子系统拥有该行为、哪些文件是真正的入口、哪些不变量容易破坏、哪些测试和指标应随改动迁移。对覆盖到的子系统做非平凡改动前应先阅读对应指南跨组件改动从 仓库总览 开始若改动触及所有权边界、启动/关闭时序、数据或元数据契约、不变量、可观测性、或推荐阅读路径应在同一个 PR 中同步更新对应指南各子系统指南约定了统一的章节契约目的与范围、架构视图、进程生命周期与启动时序、数据模型与元数据契约、可观测性与运维信号、变更管理指引、阅读地图、术语表、必读文件顺序、变更影响矩阵。这套指南目前覆盖了经典raftstore路径与RaftKv2/raftstore-v2路径涉及 components/raftstore、components/raftstore-v2、components/resource_control、components/batch-system、components/server、src/server、src/storage、src/coprocessor、src/coprocessor_v2 等模块并为cdc、backup、engine_rocks、pd_client、sst_importer等尚未有专篇指南的子系统提供了跨组件审查清单请求热路径、边界层、线程归属、region 作用域假设、资源控制钩子、可观测性、动态配置、失败语义、测试随行为迁移等。寻找合适的工作任务对新手社区准备了大量难度已标注的任务可以在 Help Wanted 标签的 Issue 列表中挑选。如果计划做较大改动涉及多组件或改变现有行为务必先开 Issue 与社区讨论。TiKV 团队还积极开发并维护一批被 TiKV 依赖的独立项目同样欢迎贡献rust-prometheusRust 的 Prometheus 客户端即 TiKV 的指标采集与上报库rust-rocksdbRocksDB 的 Rust 绑定与封装raft-rsRust 实现的 Raft 分布式共识算法grpc-rs基于 gRPC C Core 与 Rust Futures 的 gRPC 库fail-rsRust fail points故障注入点库。链接 Issue强制性要求TiKV 社区的代码仓库要求所有PR 关联其对应 Issue。PR 描述中必须有一行以Issue Number:开头通过关键字关联相关 Issue若 PR 解决该 Issue 并希望在合并后自动关闭它使用closeIssue Number: close #123若只是关联而不关闭使用refIssue Number: ref #456多个 Issue 需为每个完整书写并用逗号分隔Issue Number: close #123, ref #456要关闭其他仓库的 Issue 时需先在本仓库创建 Issue 并以此为跟踪载体。如果 PR 描述缺少上述内容bot 会为其添加do-not-merge/needs-linked-issue标签阻止合并。提交信息Commit Message格式仓库 bot 会提取 PR 标题作为一行式主题subject并将 PR 描述中commit-message代码块里的内容作为提交信息正文。例如一个标题为pkg: whats changed in this one package、描述中包含如下代码块的 PRcommit-message any multiple line commit messages that go into the final commit message body * fix something 1 * fix something 2 最终生成的提交信息为pkg: whats changed in this one package (#12345) any multiple line commit messages that go into the final commit message body * fix something 1 * fix something 2格式要点第一行subject即 PR 标题不超过 50 个字符其余行每行不超过 72 个字符即常见的 50/72 规则改动涉及多个子系统时用逗号分隔如util/codec,util/types:涉及大量子系统时可用*代替如*:正文应说明为什么做这个改动以及代码在高层面上如何工作。签署提交DCO项目启用 DCODeveloper Certificate of Origin检查提交信息中必须包含Signed-off-by行。使用git commit -s即可自动签署bot 会汇总 PR 中所有提交的签名并追加到最终提交信息正文。使用 LocalStack 本地测试 AWS 集成测试 TiKV 的 AWS 集成代码不需要AWS 账号使用 LocalStack 即可在本地模拟 AWS 服务。先在本地启动 LocalStackgit clone https://github.com/localstack/localstack.git cd localstack docker-compose up例如测试 KMS 时先创建密钥pip install awscli-local awslocal kms create-key把返回的密钥 ID 填入 TiKV 配置的key-id字段。查看 etc/config-template.toml 中[security.encryption.master-key]的注释可知kms类型用于对接云厂商 KMS 服务模板中给出了 AWS KMS 的完整示例type kms、region、endpoint、key-id 字段。文档中的最小化示例如下[security.encryption.master-key] type kms region us-west-2 endpoint http://localhost:4566 key-id KMS key id运行 TiKV 前还需设置 LocalStack 的凭据export AWS_ACCESS_KEY_IDtest export AWS_SECRET_ACCESS_KEYtest该流程在仓库源码中有对应验证AWS KMS 实现位于 components/cloud/aws/src/kms.rs其中包含名为test_aws_kms_localstack的本地集成测试components/cloud/aws/src/kms.rs#L361可在无真实 AWS 账号的前提下覆盖加解密与主密钥管理逻辑。结语TiKV 的贡献链路——从固定 nightly 工具链与 Makefile 统一构建环境、make dev的一站式自检、failpoints 与 Docker 测试到 Issue 强制关联、50/72 提交信息规范与 DCO 签署——都围绕让大规模分布式系统可被社区安全地共同维护这一目标设计。无论你从 Help Wanted 任务入手还是深入 components/raftstore 之类的核心子系统都可以先按本文搭好环境再结合 doc/maintenance-guides/ 的指南阅读代码提交你的第一个 PR。【免费下载链接】tikvDistributed transactional key-value database, originally created to complement TiDB项目地址: https://gitcode.com/GitHub_Trending/ti/tikv创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TiKV 贡献指南：从开发环境搭建到首个 Pull Request 的完整实践
TiKV 贡献指南从开发环境搭建到首个 Pull Request 的完整实践【免费下载链接】tikvDistributed transactional key-value database, originally created to complement TiDB项目地址: https://gitcode.com/GitHub_Trending/ti/tikvTiKV 是 Rust 实现的分布式事务型 Key-Value 数据库最初为补充 TiDB 而诞生。本文基于仓库根目录的 CONTRIBUTING.md 展开结合 Makefile、rust-toolchain.toml、doc/maintenance-guides/ 等仓库实文件系统讲解在本地构建、运行、测试 TiKV 的完整流程以及从提 Issue、写提交信息到提交 PR 的协作规范。读完本文你将掌握一套可复现的开发工作流配好工具链、跑通make dev全量检查、用 Docker 或 nextest 测试、按项目规范提交变更并用 LocalStack 在本地验证 AWS 集成代码。TiKV 社区为贡献者准备了入门路径导航图指出不同背景的开发者适合的贡献方向开发环境搭建前置依赖TiKV 主要由 Rust 编写同时包含 C 组件RocksDB、gRPC并使用 Rust nightly 工具链。开始前至少需要安装工具用途git版本控制rustupRust 安装器与工具链管理器make构建工具驱动常见工作流cmake构建工具gRPC 需要awk模式扫描/处理语言被构建脚本使用protocGoogle Protocol Buffer 编译器C 编译器gcc 5 或 clanggRPC 需要如果目标平台不是 x86_64/aarch64 的 Linux 或 macOS还需要额外安装llvm和clang用于生成不同平台的绑定并构建原生库grpcio、rocksdb 依赖。获取仓库git clone https://github.com/tikv/tikv.git cd tikv # 后续所有指令均假设已位于该目录配置 Rust 工具链rustup是 Rust 官方工具链管理器。TiKV 通过仓库根目录的 rust-toolchain.toml 将工具链固定到指定 nightly 版本rustup与cargo会自动读取该文件无需手动切换[toolchain] channel nightly-2026-01-30 components [rustfmt, clippy, rust-src, rust-analyzer] profile minimal从该文件可以看到除了固定 nightly 版本外还声明了rustfmt、clippy、rust-src、rust-analyzer组件并以minimalprofile 避免安装多余组件。若组件缺失可显式安装rustup component add rustfmt rustup component add clippy构建、格式化与测试标准构建与增量检查TiKV 的 Makefile 封装了常见工作流并统一了构建环境。也可以用cargo直接构建为了避免因环境差异导致重复编译建议让命令在 Makefile 同一环境中运行方法是在命令前加scripts/env前缀./scripts/env cargo build查看 scripts/env 的实现可知它本质上是把收到的命令转交给make run去执行从而复用 Makefile 注入的环境变量与 feature 组合。正式构建make build查看 Makefile 中buildtarget 的实现它设置TIKV_PROFILEdebug以--no-default-features --features ${ENABLE_FEATURES}方式调用cargo build。ENABLE_FEATURES默认已包含memory-engine、jemallocLinux 下还附加mem-profiling、portable、sse等特性当TIKV_FRAME_POINTER1默认开启时还会强制加入-Cforce-frame-pointersyes并启用pprof-fp以保证稳定的 CPU 采样栈回溯。交互式开发阶段更适合用cargo check——只做语法解析、借用检查与 lint不产出二进制cargo check --allmake devPR 前的完整自检准备提交变更前应运行devtarget。它依次做格式化、启用 clippy 的构建并跑测试。按 Makefile 定义dev: format clippy env FAIL_POINT1 make test即make devformatclippy 开启 failpoints 特性FAIL_POINT1会令ENABLE_FEATURES追加failpoints后的全量测试。提交 PR 之前应保证它能无失败跑完。部分测试偶发不稳定或并非在所有平台通过遇到疑问可以向社区提问确认。make dev运行测试套件可以单独跑测试套件也可以只跑某个具体测试# 运行完整测试套件 make test # 运行指定测试--nocapture 输出打印内容 ./scripts/test $TESTNAME -- --nocapture # 或通过 make 环境变量方式 env EXTRA_CARGO_ARGS$TESTNAME make testmake test实际调用 scripts/test-all。该脚本先执行 scripts/test 做一次工作区全量cargo test排除 fuzz 相关 crate在 Linux 上还会以MALLOC_CONFprof:true重跑ifdef_malloc_conf测试最后用--message-formatjson-render-diagnostics -q --no-run编译一次并用 scripts/check-bins.py 校验产物。scripts/test内部通过make run复用 Makefile 环境自动追加docker_test容器内等特性并导出LOG_LEVELDEBUG、RUST_BACKTRACEfull便于排查。也可以用 nextest 运行测试env EXTRA_CARGO_ARGS$TESTNAME make test_with_nextest对应 Makefile 中的test_with_nextesttarget它将CUSTOM_TEST_COMMAND设为nextest run --nocapture并开启 doctest 持久化选项。格式化与静态检查TiKV 遵循 Rust 社区代码风格使用 Rustfmt 与 Clippy 自动格式化并检查代码这两项在 CI 中会被强制校验make dev也已包含# 运行 Rustfmt make format # 运行 Clippy注意部分 lint 被忽略直接 cargo clippy 会产生大量误报 make clippy值得说明的是为什么文档强调直接cargo clippy会误报查看 Makefile 中clippytarget它在 scripts/clippy-all 之外还依次执行check-redact-log、check-log-style、check-dashboards、check-docker-build、check-license、deny等仓库自有检查脚本format则除了cargo fmt还会用cargo-sort按CARGO_SORT_VERSION锁定版本校验 Cargo.toml 中依赖的排序。在 Docker 中跑测试也可以在 Docker 环境内运行测试make docker_test它会基于 Dockerfile.test 构建pingcap/tikv_dev镜像并运行 TiKV 单元测试之后可直接复用该镜像做临时测试。从 Dockerfile.test 可以看到测试镜像的构成基于 Rocky Linux 8安装 make/git/gcc/cmake/curl/protoc 等构建依赖安装 Rust 工具链后预装cargo-nextest并将工作目录挂载为/tikv。运行过程中会出现大量看似报错的信息其实并非错误而是 rustc/cargo 的输出例如jemalloc: Invalid conf pair: prof:true构建疑难与调优为降低编译时间与磁盘占用TiKV 默认不包含完整调试信息只有测试包启用行号级 debuginfo。需要调试信息时用RUSTFLAGS覆盖RUSTFLAGS-Cdebuginfo1 make dev RUSTFLAGS-Cdebuginfo1 cargo build-Cdebuginfo1只保留行号-Cdebuginfo2保留完整调试信息。用 make 构建时cargo 会自动启用流水线pipelined编译提升并行度直接用 cargo 时需显式开启CARGO_BUILD_PIPELININGtrue cargo build关于 FIPS如果在 macOS 上以ENABLE_FIPS1构建参见仓库内 Dockerfile.FIPSTiKV 仍会启用gcp_v2FIPS 路径此时需要自行向进程提供匹配的aws_lc_*FIPS.dylib例如通过DYLD_LIBRARY_PATH等标准 macOS 动态库搜索路径。运行 TiKV要把 TiKV 作为真实 Key-Value 存储运行需要以集群方式启动单节点集群即可用于测试可在单机或多机上完成。集群由 PDPlacement Driver管理即使是单机单节点也不例外。官方部署文档提供了完整安装与启动步骤若从源码构建可跳过下载安装包一步tikv-server位于target目录下。仓库内也有配套参考如 doc/deploy.md部署说明与 doc/http.mdHTTP 状态接口。两个实用提示建议将进程可打开文件数上限提高到 82920 以上否则运行高负载测试时可能触发文件描述符不足WSL2 用户若修改ulimit遇到困难可参考社区相关讨论见原文档指引。配置文件TiKV 的全部配置项以带注释模板的形式存放在仓库根目录的 etc/config-template.toml 中它是理解各配置项含义的第一手资料在线文档中的配置指南与之一一对应。日常部署时复制该模板并修改即可。贡献流程整体工作流一个典型的贡献者工作流大致如下确认想贡献的内容已有关联 Issue 跟踪规则见下文链接 Issue社区会在 Issue 中讨论问题与方案从基础分支通常是 master创建 Git 分支编写代码、补充测试用例并提交提交信息格式见下文运行测试并确保全部通过将改动推送到 fork 的分支并提交 Pull Request提交信息中必须提及第 1 步创建的 IssuePR 进入评审评审可能要求修改改动后 PR 需重新评审并获得批准PR 过期时可直接使用 GitHub 的 update branch 按钮出现冲突时可在本地合并解决后推送仅解决冲突不必重新评审但若有显著改动应请求重新评审仓库的 CI 系统会自动测试所有 PR社区的 bot 负责合并 PR评论/merge即可触发要求测试通过且有两个 approve可能需要请评审人操作。TiKV 的代码文档Rustdoc可作为理解代码库的补充资料。维护指南变更前的必读材料TiKV 在 doc/maintenance-guides/ 下维护了一套面向维护者与评审者的指南而不是面向用户的说明书。这套指南服务于四个问题哪个子系统拥有该行为、哪些文件是真正的入口、哪些不变量容易破坏、哪些测试和指标应随改动迁移。对覆盖到的子系统做非平凡改动前应先阅读对应指南跨组件改动从 仓库总览 开始若改动触及所有权边界、启动/关闭时序、数据或元数据契约、不变量、可观测性、或推荐阅读路径应在同一个 PR 中同步更新对应指南各子系统指南约定了统一的章节契约目的与范围、架构视图、进程生命周期与启动时序、数据模型与元数据契约、可观测性与运维信号、变更管理指引、阅读地图、术语表、必读文件顺序、变更影响矩阵。这套指南目前覆盖了经典raftstore路径与RaftKv2/raftstore-v2路径涉及 components/raftstore、components/raftstore-v2、components/resource_control、components/batch-system、components/server、src/server、src/storage、src/coprocessor、src/coprocessor_v2 等模块并为cdc、backup、engine_rocks、pd_client、sst_importer等尚未有专篇指南的子系统提供了跨组件审查清单请求热路径、边界层、线程归属、region 作用域假设、资源控制钩子、可观测性、动态配置、失败语义、测试随行为迁移等。寻找合适的工作任务对新手社区准备了大量难度已标注的任务可以在 Help Wanted 标签的 Issue 列表中挑选。如果计划做较大改动涉及多组件或改变现有行为务必先开 Issue 与社区讨论。TiKV 团队还积极开发并维护一批被 TiKV 依赖的独立项目同样欢迎贡献rust-prometheusRust 的 Prometheus 客户端即 TiKV 的指标采集与上报库rust-rocksdbRocksDB 的 Rust 绑定与封装raft-rsRust 实现的 Raft 分布式共识算法grpc-rs基于 gRPC C Core 与 Rust Futures 的 gRPC 库fail-rsRust fail points故障注入点库。链接 Issue强制性要求TiKV 社区的代码仓库要求所有PR 关联其对应 Issue。PR 描述中必须有一行以Issue Number:开头通过关键字关联相关 Issue若 PR 解决该 Issue 并希望在合并后自动关闭它使用closeIssue Number: close #123若只是关联而不关闭使用refIssue Number: ref #456多个 Issue 需为每个完整书写并用逗号分隔Issue Number: close #123, ref #456要关闭其他仓库的 Issue 时需先在本仓库创建 Issue 并以此为跟踪载体。如果 PR 描述缺少上述内容bot 会为其添加do-not-merge/needs-linked-issue标签阻止合并。提交信息Commit Message格式仓库 bot 会提取 PR 标题作为一行式主题subject并将 PR 描述中commit-message代码块里的内容作为提交信息正文。例如一个标题为pkg: whats changed in this one package、描述中包含如下代码块的 PRcommit-message any multiple line commit messages that go into the final commit message body * fix something 1 * fix something 2 最终生成的提交信息为pkg: whats changed in this one package (#12345) any multiple line commit messages that go into the final commit message body * fix something 1 * fix something 2格式要点第一行subject即 PR 标题不超过 50 个字符其余行每行不超过 72 个字符即常见的 50/72 规则改动涉及多个子系统时用逗号分隔如util/codec,util/types:涉及大量子系统时可用*代替如*:正文应说明为什么做这个改动以及代码在高层面上如何工作。签署提交DCO项目启用 DCODeveloper Certificate of Origin检查提交信息中必须包含Signed-off-by行。使用git commit -s即可自动签署bot 会汇总 PR 中所有提交的签名并追加到最终提交信息正文。使用 LocalStack 本地测试 AWS 集成测试 TiKV 的 AWS 集成代码不需要AWS 账号使用 LocalStack 即可在本地模拟 AWS 服务。先在本地启动 LocalStackgit clone https://github.com/localstack/localstack.git cd localstack docker-compose up例如测试 KMS 时先创建密钥pip install awscli-local awslocal kms create-key把返回的密钥 ID 填入 TiKV 配置的key-id字段。查看 etc/config-template.toml 中[security.encryption.master-key]的注释可知kms类型用于对接云厂商 KMS 服务模板中给出了 AWS KMS 的完整示例type kms、region、endpoint、key-id 字段。文档中的最小化示例如下[security.encryption.master-key] type kms region us-west-2 endpoint http://localhost:4566 key-id KMS key id运行 TiKV 前还需设置 LocalStack 的凭据export AWS_ACCESS_KEY_IDtest export AWS_SECRET_ACCESS_KEYtest该流程在仓库源码中有对应验证AWS KMS 实现位于 components/cloud/aws/src/kms.rs其中包含名为test_aws_kms_localstack的本地集成测试components/cloud/aws/src/kms.rs#L361可在无真实 AWS 账号的前提下覆盖加解密与主密钥管理逻辑。结语TiKV 的贡献链路——从固定 nightly 工具链与 Makefile 统一构建环境、make dev的一站式自检、failpoints 与 Docker 测试到 Issue 强制关联、50/72 提交信息规范与 DCO 签署——都围绕让大规模分布式系统可被社区安全地共同维护这一目标设计。无论你从 Help Wanted 任务入手还是深入 components/raftstore 之类的核心子系统都可以先按本文搭好环境再结合 doc/maintenance-guides/ 的指南阅读代码提交你的第一个 PR。【免费下载链接】tikvDistributed transactional key-value database, originally created to complement TiDB项目地址: https://gitcode.com/GitHub_Trending/ti/tikv创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考