需求文档：分布式 SVN 代码库同步系统

天工无极
3 阅读7分钟

1. 背景介绍

1.1 业务背景

公司作为安防行业头部企业，研发中心遍布全球。受限于内部网络安全策略，各中心仅能访问本地 SVN 服务。随着跨区域协作项目增多，现有的“孤岛式”代码管理导致异地协作效率低下，迫切需要一套能跨中心同步且保证代码版本绝对一致的分布式方案 。

1.2 业务场景

场景/商业模式描述商业价值
标准服务单中心内部开发，访问本地 SVN。基础研发保障。
跨中心协作（本次范围）多中心针对同一项目代码库进行并发提交，需确保版本强一致性（CP）。打破区域限制，提升全球协同效率。

2. 产品概述

2.1 产品定位

在跨区域网络隔离场景下，提供分布式SVN代码库的版本锁与高效同步能力，服务全球研发人员的一款数据一致性中间件。

2.2 服务对象

  • 研发人员：在本地中心提交代码，无感知跨中心冲突。
  • 运维/配置管理：负责同步状态监控与故障恢复。

2.3 产品逻辑

系统采用“本地提交 + 全局仲裁 + 异步补偿”的架构：

  1. 全局仲裁（CP核心） ：任何中心的提交动作必须先获取全局分布式锁。
  2. 本地预转储：获取锁后，数据写入本地库。
  3. 高速同步：利用二进制差分技术将版本号及数据同步至其他中心；同步时机——提交成功在post-commit脚本中发起同步。

2.4 角色术语

角色定义职责
Global Lock (G-Lock)全局分布式锁确保同一时间只有一个中心能执行 Commit 操作 。
Local Mirror本地代码镜像各中心本地的 SVN 实例。
Sync Agent同步代理负责版本数据的分发、压缩与导入。

3. 需求说明

3.1 需求列表

模块需求名称目标优先级
并发控制全局提交仲裁锁确保并发提交时强一致性（CP），禁止版本跳跃。PO (最高)
数据传输高效增量同步引擎实现版本数据的高速传输与全量/增量导入。P1
容灾恢复快速一致性修复工具服务崩溃后，自动比对各中心版本号并强制对齐。P1
监控告警同步延迟与锁定监控实时监控各中心同步状态。P2

3.2 需求明细

3.2.1 全局提交仲裁锁（CP优先原则）
  • 需求描述：
    • 当研发中心 A 触发 svn commit 时，系统必须拦截并向“全局仲裁中心”请求该 Repo 的唯一提交锁。
    • 若研发中心 B 同时提交，因锁已被 A 占用，B 的提交必须立即失败并返回提示：“当前代码库正在由其他中心同步中，请稍后再试”。
    • 一致性校验：提交前必须校验本地版本号是否等于全局最高版本号，若不一致则强制要求 update。
  • 原型示意：
3.2.2 高效增量同步引擎
  • 需求描述：
    • 传输层：支持 Zstd 或 LZ4 高压缩比算法减少跨海缆带宽占用。
    • 数据层：采用 SVN Admin Dump --incremental 模式，仅提取增量修订版 。
    • 导入层：目标中心接收后，采用流水线作业，边下载边 load，减少磁盘 I/O 等待。
3.2.3 快速恢复补救方案
  • 需求描述：
    • 断点续传：同步过程中网络中断，恢复后支持从上次失败的版本号继续拉取。
    • 强制重同步（Force Sync） ：若本地库损坏，支持一键从其他中心拉取全量快照进行覆盖恢复。
    • 日志追溯：记录每次 G-Lock 的获取时间、持有中心及释放状态，方便审计 。

3.3 非功能需求

  • 性能：单次版本同步（100MB以内）在跨中心延迟 200ms 下，需在 10s 内完成对齐。
  • 可靠性：仲裁中心需部署高可用集群，防止单点故障导致全球无法提交。
  • 安全性：中心间数据传输必须经过 TLS 加密。

3.4 状态机与异常处理设计（基于 svnrdump + hook 机）

本章节基于 svnrdump + pre-commit / post-commit hook + 异步同步任务 的实际技术方案，对状态机、锁语义和异常处理进行修订与细化，确保方案可直接实现。

3.4.1 分布式 SVN 群组模型

  • 一个 分布式 SVN 群组（SVN Group） 包含多个 SVN 仓库节点
  • 任意时刻：
    • 仅允许一个 Master Node（最近一次成功提交的节点）
    • 群组维护一个 全局版本号（group_revision）

入组规则：

  • 第一个加入群组的仓库可为非空库
  • 后续加入群组的仓库 必须为空库，通过全量同步完成初始化

3.4.2 Repo / 群组状态机

状态含义是否允许提交说明
READY群组版本一致✅正常可提交
LOCKED有节点持有提交锁❌（其他节点）锁与 node_id 绑定
SYNCINGpost-commit 同步任务执行中❌防止版本前移
DEGRADED部分节点未同步❌允许释放锁
BROKEN群组元数据异常❌仅允许运维介入

3.4.3 提交锁（Commit Lock）语义（核心）

锁模型
  • 锁粒度：SVN Group 级
  • 锁字段：group_id + holder_node_id + lease_expire_at
  • 锁模式：租约锁（Lease） ，支持超时回收
pre-commit 阶段逻辑（强校验）
  1. 判断当前仓库是否属于某分布式 SVN 群组
  2. 若是：
    • 校验是否已持有提交锁
    • 若未持有锁：
      • 尝试获取锁（若锁已释放或超时）
    • 校验：local_max_revision == group_revision
  1. 校验通过：
    • 更新群组 master_node_id = current_node
    • 放行 commit
  1. 校验失败：
    • 直接拒绝提交（返回明确错误原因）

⚠️ pre-commit 阶段 不做任何同步行为，只做一致性与锁校验。

3.4.4 post-commit 阶段逻辑（状态推进）

  1. 本地 commit 成功
  2. 必须成功更新群组 group_revision = local_max_revision
    • 若失败：
      • 标记群组状态为 BROKEN
      • 阻断后续所有提交
  1. 查询所有从节点（slave nodes）版本号
  2. 为每个 在线且版本落后 的节点生成异步同步任务：
    • 同步方式：svnrdump dump --incremental → svnrdump load
  1. post-commit 结束，不阻塞用户返回

3.4.5 同步任务状态机（svnrdump）

状态含义
CREATED已创建任务
RUNNINGdump / load 执行中
SUCCESS同步完成
FAILED_NET网络不可达
FAILED_TIMEOUT网络超时

3.4.6 提交锁释放规则（关键修订）

后台任务统一管理锁释放：

  • 若 所有同步任务 SUCCESS：
    • 释放提交锁
    • holder_node_id = null
  • 若存在失败任务：
    • FAILED_NET：
      • 本次忽略该节点
    • FAILED_TIMEOUT：
      • 自动重试 3 次
      • 仍失败则忽略该节点
    • 无论是否存在失败节点，均释放提交锁

设计目的：保证 CP 前提下避免全局阻塞。

3.4.7 节点主动追赶机制（Anti-Entropy）

每个 SVN 仓库本地部署 版本检查服务：

  • 执行周期：每 60 秒
  • 检查条件：
    • local_revision < group_revision
    • 且当前无同步任务执行
  • 行为：
    • 主动向 master_node_id 发起同步请求
    • 同步方式仍使用 svnrdump 增量模式

最终保证：所有在线节点 最终追平群组版本。

3.4.8 关键异常场景补充

场景处理策略
pre-commit 后节点崩溃锁租约到期后可被其他节点获取
post-commit 更新版本失败群组标记 BROKEN，禁止提交
master 节点下线从节点通过版本检查服务触发追赶
锁释放前节点失联后台任务或租约回收

5. 设计取舍与非目标

5.1 设计取舍

  • 选择 svnrdump 而非文件级 rsync：
    • 保留 SVN revision 语义
    • 支持精确版本对齐
  • 锁释放不等待所有节点同步成功：
    • 明确选择 CP + 最终补偿
    • 通过主动追赶避免长期不一致

5.2 非目标（Non-Goals）

  • 不支持多 Master 并发提交
  • 不支持离线提交后自动合并
  • 不保证所有节点实时可见最新版本
  • 不解决 SVN 本身的分支 / merge 冲突

4. 人员&排期

阶段任务Q1Q2Q3
阶段 1分布式锁逻辑研发 & 环境搭建●
阶段 2增量传输优化与二进制差分测试●
阶段 3容灾恢复工具与压力测试●
avatar
文章
阅读
粉丝