制造业的设计团队有个经典矛盾：机械工程师在用SolidWorks改装配图，工艺工程师在改工艺文件，CAE分析师在跑仿真，三个人的文件版本不同步，谁都不知道对方改了什么，等发现的时候已经覆盖了两三个版本。
这不是团队协作意愿的问题，是同步机制的问题。
巴别鸟的同步机制，支持单向同步和双向同步两种模式，可以按需配置。我从协议原理、版本控制、冲突处理三个层面，把这套机制讲清楚。
一、同步协议：单向同步与双向同步的技术差异
同步机制的核心问题只有两个：谁发起和谁优先。
单向同步：数据流向是单向的，一端是源端，另一端是目标端。源端变更推送到目标端，目标端的变更不会回传。适用于”中心分发”场景。
双向同步：两端互相同步，任何一端的变更都会推送到另一端。适用于”协作编辑”场景。
两种模式的协议设计差异很大。
单向同步的协议设计
单向同步的实现相对简单，基于变更日志（Changelog）机制：
源端：检测文件变更 → 记录变更日志（文件名、MD5、时间戳、变更类型）
↓
目标端：定时拉取变更日志 → 按顺序重放变更 → 校验完整性
变更类型我们定义了四种：
– CREATE：新文件
– MODIFY：文件内容变更（通过MD5检测）
– DELETE：文件删除
– RENAME：文件重命名
目标端如何判断文件是否最新？每个文件有一个`version vector`，记录当前同步到的版本。当源端版本大于目标端时，触发同步。
// 单向同步的版本向量
{
"file_id": "DWG-ASSY-001",
"source_version": 15,
"target_version": 12,
"need_sync": true,
"pending_changes": [
{"type": "MODIFY", "version": 13, "timestamp": "2026-04-10T08:15:22Z"},
{"type": "MODIFY", "version": 14, "timestamp": "2026-04-10T09:03:45Z"},
{"type": "MODIFY", "version": 15, "timestamp": "2026-04-10T10:22:11Z"}
]
}
单向同步的延迟可以做到很低——源端检测到变更后，15秒内推送到目标端。
双向同步的协议设计
双向同步的难点在于冲突检测和解决。两端都可能产生变更，谁的变更优先？
我们用的是向量时钟（Vector Clock） + 最后写入者胜出（Last-Write-Wins）的混合策略。
向量时钟记录每个节点对文件版本的理解：
节点A的向量时钟：{A: 3, B: 2} -- A认为文件被修改了3次，B修改了2次
节点B的向量时钟：{A: 3, B: 3} -- B认为文件被修改了3次，自己修改了3次
当两个节点的向量时钟无法比较时（即A认为B改了2次，B认为B改了3次），说明有并发修改，需要进入冲突处理流程。
// 双向同步的向量时钟
{
"file_id": "DWG-ASSY-001",
"vector_clock": {
"node_desktop": 5,
"node_laptop": 4,
"node_server": 7
},
"last_sync": "2026-04-10T08:00:00Z",
"conflicts": []
}
关键设计：双向同步采用”最终修改时间戳”来判断谁是最新版本，但保留冲突文件的历史版本。不会直接覆盖，而是生成一个”冲突副本”，让用户手动决定用哪个版本。
二、版本控制：设计团队的版本管理痛点
设计团队对版本控制的需求，和程序员对Git的需求非常像，但他们的工具往往是文件名后缀——”V1″、”V2″、”_final”、”_真正final”、”_改了三版”。
巴别鸟的同步机制内嵌了版本控制能力，每次同步产生的变更都会生成一个快照版本。
版本存储策略
版本存储是很多云盘产品的痛点——每个版本都存一份完整文件，空间消耗太快。
我们用的是增量存储：
版本1：完整文件，100MB
版本2：相对于版本1的增量，假设变了10MB，存储10MB
版本3：相对于版本2的增量，假设变了5MB，存储5MB
这样10个版本下来，实际存储空间可能只有115MB左右，而不是1GB。
版本元数据结构：
{
"file_id": "DWG-ASSY-001",
"current_version": 12,
"versions": [
{
"version": 1,
"size": 104857600,
"checksum": "md5:abc123...",
"storage_path": "/versions/v1/",
"created_at": "2026-03-01T09:00:00Z",
"created_by": "zhangsan",
"change_summary": "初始版本"
},
{
"version": 2,
"delta_from": 1,
"delta_size": 10485760,
"checksum": "md5:def456...",
"storage_path": "/versions/v2/",
"created_at": "2026-03-01T14:30:00Z",
"created_by": "lisi",
"change_summary": "修改装配关系"
}
]
}
版本回退与对比
任何历史版本都可以一键回退，回退操作会生成一个新的版本（不是删除新版本，而是保留完整历史）。也可以对比任意两个版本的差异。
对于SolidWorks、AutoCAD这类图纸文件，版本对比能直接显示两个版本的模型差异——哪些零件变了、哪些尺寸改了，都可以直接标注出来。
三、冲突处理：并发编辑的解决方案
这是双向同步的核心难题，也是设计团队最头疼的问题——两个人同时改了同一个文件，后改的人覆盖了先改的人的工作。
巴别鸟的冲突处理策略分三层。
第一层：冲突预防（Conflict Prevention）
最好的冲突处理是让冲突不发生。巴别鸟支持文件锁定机制：
– 锁定期间，其他用户只能预览，不能编辑
– 锁定超时自动释放（默认30分钟，可配置）
– 锁定记录显示在文件列表里，其他用户一眼就知道”这个文件张工正在改”
文件锁定状态：
文件名：DWG-ASSY-001
状态： 已被 张三（桌面工作站）锁定
到期时间：10:45（剩余23分钟）
操作：申请解锁
锁定机制对设计团队特别有用。一个装配图有几十个零件，不同人可以同时改不同零件，但装配图主文件需要串行编辑——锁定保证同一时间只有一个人能改。
第二层：冲突检测（Conflict Detection）
如果两个人同时编辑同一个文件且没有锁定，系统会检测到冲突。
冲突检测基于向量时钟和MD5校验：
1. 同步前，A和B都有文件的version=5
2. A离线编辑，本地生成version=6
3. B也离线编辑，本地也生成version=6（同一时间不同步）
4. A上线同步，系统检测到B也修改了，推送成功，但标记冲突
5. B上线同步，检测到冲突，生成冲突文件
第三层：冲突解决（Conflict Resolution）
冲突文件不会被直接覆盖，而是：
1. 保留双方版本：原文件保留为`file.dwg`，冲突副本保存为`file_conflict_20260410_143022.dwg`
2. 通知相关用户：邮件/站内信通知双方有冲突
3. 提供对比工具：打开对比视图，显示两个版本的差异，手动合并
冲突文件列表：
├── DWG-ASSY-001.dwg（当前版本，来自张三）
├── DWG-ASSY-001_conflict_20260410_143022.dwg（冲突版本，来自李四）
└── [手动合并] → 生成新版本
手动合并后，删除冲突文件，生成新的正常版本。
四、场景案例：机械制造业的同步实践
苏州一家做非标自动化的机械厂，200多人，设计部30多人，用SolidWorks做三维设计。
他们的痛点：
– 装配图经常被覆盖，工程师不知道对方改了啥
– 图纸版本混乱，不知道用哪个是最新
– 外协加工的图纸发出去，版本不对，导致加工错误
上线巴别鸟同步机制后：
1. 双向同步覆盖日常协作
设计部内部用双向同步，SolidWorks文件实时同步到每个工程师的本地目录。张工改了一个零件，王工打开自己的文件就是最新版，不用手动传递。
2. 单向同步覆盖外协分发
外协加工商只接收单向同步——工厂的图纸推送到外协的云盘，外协只能看，不能改。外协把加工完成的回料图通过指定文件夹回传，工厂收到后手动合并到主版本。
这套机制运行半年，外协加工错误率从每月3-4起降到0。
3. 版本控制替代文件名后缀
以前桌面上一堆”V1″、”V2″、”_final”文件，现在直接用版本历史。”这个零件5月份改过哪几个版本、谁改的、改了啥”，一目了然。
五、技术选型的关键决策
做同步系统，绕不开几个技术选择：
1. 同步粒度：文件级还是块级
文件级同步是整个文件上传/下载，简单但大文件效率低。块级同步把文件切成4MB的块，只同步变化的块，效率高但实现复杂。
巴别鸟对小于100MB的文件用文件级，对大于100MB的文件自动切换到块级同步。SolidWorks的装配图通常几十MB，块级同步能节省70%以上的带宽。
2. 同步频率：实时还是定时
设计团队的诉求是”改完马上同步”，不是”等5分钟再同步”。我们用WebSocket保持长连接，检测到变更后立即触发同步，延迟控制在5秒以内。
对于网络不稳定的环境（比如出差时用酒店WiFi），系统会降级为”有变化时记录，离线可用，连上网络后自动同步”。
3. 冲突处理：自动还是手动
自动解决冲突（用时间戳或哈希）简单但可能丢数据。手动解决麻烦但不会丢数据。
我们默认是手动解决冲突，但提供”自动保留最新版本，历史版本不删除”的兜底策略——即使自动合并了，也能在版本历史里找到被覆盖的版本。
结语
同步机制的技术选型，本质上是在效率和一致性之间找平衡。
单向同步效率高但一致性弱，适用于分发场景。双向同步一致性强但实现复杂，适用于协作场景。设计团队两种场景都有，所以巴别鸟两种模式都支持，按目录、按项目灵活配置。
版本控制和冲突处理是配套能力。没有版本控制，同步的变更无法追溯。没有冲突处理，双向同步会变成数据灾难。
这三个模块协同运转，才是完整的企业云盘同步解决方案。