Jujutsu 版本控制与分片存储
什么是 Jujutsu
Jujutsu 是 Google 开源的下一代版本控制系统，兼容 Git 存储格式。与 Git 相比，Jujutsu 没有暂存区概念，工作副本即 commit，所有操作都可以 undo，非常适合自动化和智能体场景。
MDMS 使用 Jujutsu 管理百科词条的主存储，解决三个核心问题：超大规模文件存储（亿级 .md 文件）、版本历史追踪（十亿级编辑记录）、多智能体并行写入（无冲突协作）。
为什么选择 Jujutsu 而不是 Git
Git 在大仓库场景下有明显瓶颈：git status 扫描百万文件需要数秒，分支切换需要重写工作目录，合并冲突处理需要人工介入。
Jujutsu 的优势：工作副本即 commit，无需 git add / git commit 两步操作；所有操作可 undo，智能体误操作可以一键回退；原生支持匿名分支，每个智能体自动获得独立工作空间；底层使用 Git 存储格式，现有工具（如 GitHub）可以直接访问。
架构概览
MDMS 读写请求
↓
分片路由层（hash(slug) % N）
↓
┌──────────┬──────────┬──────────┐
│ shard-00 │ shard-01 │ ... │ shard-99 │
│ Jujutsu │ Jujutsu │ │ Jujutsu │
│ 仓库 │ 仓库 │ │ 仓库 │
└──────────┴──────────┴──────────┘
↓
Manticore Search（全文检索索引）
↓
PageRank（内容权重排序）
每个分片是一个独立的 Jujutsu 仓库，包含约 50-100 万个 .md 文件。读写请求通过 hash(slug) % N 路由到对应分片。
环境要求
操作系统: Linux（CentOS 7+ / Ubuntu 20.04+ / Debian 11+）
内存: 分片操作主要是磁盘 IO，额外内存占用很小，建议服务器总内存不低于 4GB
磁盘: 每个 .md 文件平均 2-5KB，1 亿词条约 200-500GB（Git 压缩后更小），建议 SSD
Jujutsu 版本: 0.25.0 及以上
安装 Jujutsu
方式一：下载预编译二进制（推荐）
curl -LsSf https://github.com/jj-vcs/jj/releases/latest/download/jj-x86_64-unknown-linux-musl.tar.gz | tar xz -C /usr/local/bin
jj version
方式二：通过 Cargo 安装
# 需要先安装 Rust
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
source ~/.cargo/env
cargo install --locked jj-cli
jj version
验证安装
jj version
输出类似 jj 0.28.0 表示安装成功。
初始配置
jj config set --user user.name "MDMS System"
jj config set --user user.email "mdms@localhost"
分片架构
分片规则
分片数量 N 默认为 100。每个词条根据 slug 的哈希值分配到对应分片：
分片编号 = FNV32(slug) % 100
例如 slug 为 "manticore-search" 的词条，FNV32 哈希后取模，可能分配到 shard-42。
分片目录结构
/data/shards/
├── shard-00/ # 独立 Jujutsu 仓库
│ ├── .jj/
│ └── content/
│ └── md/
│ ├── article-aaa.md
│ └── article-bbb.md
├── shard-01/
│ ├── .jj/
│ └── content/
│ └── md/
├── ...
└── shard-99/
初始化分片
首次使用时，MDMS 会自动初始化所有分片仓库。也可以手动初始化：
for i in $(seq -w 0 99); do
mkdir -p /data/shards/shard-$i/content/md
cd /data/shards/shard-$i
jj git init
cd -
done
智能体协作模型
工作流程
每个智能体拥有独立的命名分支，写入流程如下：
第一步: 智能体在目标分片创建自己的分支
cd /data/shards/shard-42
jj new main -m "agent/bot-001 开始编辑"
第二步: 智能体写入或修改 .md 文件
第三步: Jujutsu 自动记录变更（工作副本即 commit，无需手动 commit）
第四步: 描述本次变更
jj describe -m "agent/bot-001: 更新词条 manticore-search"
第五步: 合并到 main 分支
jj rebase -d main
冲突处理
当两个智能体同时修改同一个词条时，后合并的会触发冲突。Jujutsu 的冲突处理方式：
Jujutsu 允许冲突状态被 commit，不会像 Git 那样阻塞流程。冲突词条会被标记，等待人工或高优先级智能体审查。
MDMS 后台的「智能体管理」页面会展示所有冲突词条，管理员可以查看 diff 并选择保留哪个版本。
版本回退
任何智能体的操作都可以回退：
jj undo # 撤销上一步操作
jj op log # 查看操作历史
jj op restore # 恢复到指定操作点
与 Manticore Search 配合
Jujutsu 负责存储，Manticore 负责检索。配合方式：
全量索引: 扫描所有分片仓库的 .md 文件，写入 Manticore 索引
增量索引: 监听各分片的 commit 事件，仅将变更的词条同步到 Manticore
搜索请求: 用户搜索时走 Manticore，不直接扫描分片目录
这样搜索性能不受分片数量影响，始终保持毫秒级响应。
后台管理
MDMS 后台提供以下 Jujutsu 相关管理功能：
分片状态总览: 每个分片的词条数、最近 commit 时间、磁盘占用
版本历史浏览: 选择任意词条查看完整编辑历史和 diff
智能体管理: 注册智能体、查看活跃分支、审查合并冲突
分片健康检查: 检测分片仓库完整性、自动修复损坏的仓库
数据迁移
从现有 content/md 迁移到分片
如果已有大量 .md 文件在 content/md 目录下，MDMS 提供一键迁移工具：
后台进入分片管理页面，点击「从 content/md 迁移」，系统会自动将现有文件按 slug 哈希分配到各分片仓库，并执行初始 commit。
迁移过程中原文件不会被删除，确认无误后可手动清理。
常见问题
jj 命令不存在
检查 Jujutsu 是否安装到 PATH 中: which jj。如果是通过 tar 解压安装，确认解压到了 /usr/local/bin/。
分片仓库损坏
单个分片损坏不影响其他分片。可以删除损坏分片的 .jj 目录后重新初始化，然后从 Manticore 索引或备份恢复内容。
磁盘空间不足
Jujutsu 使用 Git 存储格式，支持压缩。可以对分片执行垃圾回收：
cd /data/shards/shard-XX
jj git gc
智能体写入速度
单分片的写入性能约为每秒 100-500 次 commit。100 个分片并行写入时，理论总吞吐量可达每秒 1-5 万次写入，足以支撑大规模智能体协作。