调整同步备份方案，增加临时目录，APP端轻校验跑满带宽，以NAS性能换app同步时间缩短

如题， 不是来指点江山的，是真的使用起来巨蛋疼。个人觉得hash比对是放在App端的，同步花费耗时巨长。对的，因为有对比，那就是飞牛的同步备份！！！

如果现有方案就是NAS端计算hash，那么麻烦能打开app端的文件上传个数限制吗？ 每次只处理3个，请问要同步到何时？
在同步扫描阶段不就应该知道哪些文件已同步备份了嘛！！！ 为何还要一个一个的去校验比对？！
一个文件请求一次消耗一秒半秒的，那也要等到何时？！

背景：
手机相册有500G，文件有2万多个，同时绿联NAS上已有事先从其他备份设备拷贝的非全量相册文件。现在想要手机app端快速同步到绿联NAS，显示已同步。

现实是，绿联云手机端上传处理是先对文件hash，然后比对hash再判定是否需要上传。
这样带宽根本跑不满，而且手机性能被计算hash占用。本来就已经拷贝了大部分相册文件到NAS相册就是为了能快速的跳过已备份文件的同步处理，那事先拷贝相册文件到NAS就没有任何意义了。


述求：
如何改进现在的同步方案，期望能跑满手机wifi带宽。同时已部分同步的文件如何快速跳过app端的同步处理。只需同步未上传文件。 然后下次有增量文件的时候，只同步增量文件。  

解决NAS相册目录迁移，手机端APP重置备份设置后再快速显示已同步的问题。

核心就是希望 先上传文件到NAS临时目录，NAS端再对文件hash比对，根据同步设置，是添加还是丢弃。当然也要考虑如果跳过处理已备份文件的问题，最后以NAS的性能 换取 手机端备份时间的缩短。

下面是豆包给出的app端、NAS端技术改进实施方案。

--------------------------------------------------------------------------

绿联云手机相册快速同步技术改进实施方案（APP 端 + NAS 端）​
一、方案核心目标​

• 性能解放：手机端彻底规避全文件 hash 计算，降低 CPU / 内存占用，专注文件传输；​
  

• 带宽拉满：增量上传阶段以多线程 + 分片传输跑满 WiFi 带宽，大幅缩短同步耗时；​
  

• 快速对齐：利用 NAS 端已存文件（含事先拷贝文件），通过 NAS 端校验实现 “秒级标记已同步”，无需手机端重复处理；​
  

• 兼容场景：支持 NAS 相册目录迁移、APP 重置备份设置后，快速重新对齐已同步文件；​
  

• 安全可控：通过 “临时目录缓冲 + 校验机制” 避免文件冲突、传输损坏，保障数据一致性。​
  

二、核心技术架构​
颠覆 “手机端 hash 校验→比对→上传” 的传统流程，构建 “手机端轻量元数据上报 + NAS 端核心校验 + 临时目录缓冲 + 满速传输” 的反向架构，核心逻辑如下：​

• 手机端：仅采集文件元数据（路径、名称、大小、修改时间），不做 hash 计算，专注多线程分片上传；​
  

• NAS 端：承担 hash 计算、文件比对、冲突处理核心工作（利用 NAS 硬件优势提升效率）；​
  

• 缓冲机制：文件先上传至 NAS 临时目录，校验通过后再迁移至目标相册目录，避免污染原始数据；​
  

• 双标识校验：“元数据初筛 + hash 精筛”，兼顾效率与准确性。​
  

三、APP 端技术改进方案​
（一）轻量元数据采集与上报​
1. 采集内容（无 hash 计算）​

• 核心元数据：文件相对路径（基于手机相册根目录，如 “2024/06/15/IMG_8976.jpg”）、文件名、文件大小（字节级精确）、修改时间（精确到秒，兼容不同时区）；​
  

• 辅助信息：文件类型（图片 / 视频 / 音频）、手机设备 ID、备份任务 ID、APP 同步策略版本（用于 NAS 端适配）。​
  

2. 上报机制优化​

• 分批上报：每批上报 100-200 个文件元数据（避免单次请求过大导致超时），支持断点续传（记录已上报偏移量，网络中断后恢复无需重传）；​
  

• 增量上报：首次同步全量上报，后续同步仅上报 “新增 / 修改 / 删除” 的文件元数据（通过手机端本地维护 “同步状态缓存表” 实现）；​
  

• 压缩传输：元数据采用 JSON 压缩格式上报（如 gzip），降低传输开销，提升上报速度。​
  

（二）多线程分片上传优化（跑满带宽）​
1. 传输策略设计​

• 动态线程数：默认 4-8 线程（可根据 WiFi 带宽自动调整，如带宽≥100Mbps 时启用 8 线程，≤20Mbps 时启用 4 线程）；​
  

• 智能分片：文件＜10MB 时不分片，≥10MB 时按 10MB / 片拆分（大文件如 4GB 视频拆分为 400 片），支持分片并行传输；​
  

• 断点续传：每片传输完成后，NAS 端返回 “分片校验成功” 回执，手机端记录已完成分片；网络中断后，仅重传未完成分片，无需重传整个文件；​
  

• 带宽适配：上传前测试当前 WiFi 带宽，动态调整分片发送速率（避免因速率过高导致丢包，或过低浪费带宽）。​
  

2. 临时目录上传适配​

• 手机端仅需将文件上传至 NAS 端指定的临时目录（如 “/backup/temp/[设备 ID]/[任务 ID]/”），无需关心最终存储路径；​
  

• 上传请求携带 “分片 ID、总分片数、文件唯一标识（元数据组合）”，供 NAS 端拼接文件与校验。​
  

（三）同步状态管理与展示​
1. 本地状态缓存​

• 手机端维护 “同步状态缓存表”（本地数据库，如 SQLite），记录文件元数据、同步状态（未同步 / 同步中 / 已同步 / 冲突）、上传进度、NAS 反馈结果；​
  

• APP 重置或重装后，可通过 “重新上报元数据 + NAS 端校验” 重建缓存表，无需重新上传已同步文件。​
  

2. 可视化展示​

• 实时显示：已同步文件数、待上传文件数、传输速度（MB/s）、剩余时间（基于已传输速率估算）；​
  

• 增量更新：NAS 端每完成一批文件校验，实时反馈给手机端，更新 “已同步” 计数（无需等待全部校验完成）；​
  

• 冲突提示：对 NAS 端判定的 “冲突文件”（如元数据匹配但 hash 不匹配），展示冲突原因（如 “文件内容已修改”），提供用户操作选项（覆盖 / 保留 / 重命名）。​
  

（四）兼容性适配​

• 系统权限优化：Android/iOS 端申请 “相册读写权限 + 后台传输权限”，支持后台持续上传（锁屏 / APP 退后台不中断）；​
  

• 旧版本兼容：若 NAS 端未升级，APP 自动降级为原 hash 校验流程（避免功能不可用）；升级后自动启用新流程。​
  

四、NAS 端技术改进方案​
（一）临时目录设计与管理​
1. 目录结构​

• 根目录：/backup/temp/（独立于正式相册目录，避免传输中文件污染）；​
  

• 子目录：按 “设备 ID→备份任务 ID→文件相对路径” 分级创建，如/backup/temp/device_123/task_456/2024/06/15/；​
  

• 清理机制：​
  

• 自动清理：传输完成并迁移至正式目录后，1 小时内删除临时文件；​
  

• 异常清理：超过 24 小时未完成传输的分片文件，自动清理（释放存储空间）；​
  

• 手动清理：提供管理员后台手动清理入口。​
  

2. 文件拼接与完整性校验​

• 分片拼接：接收完某文件所有分片后，按分片 ID 排序拼接为完整文件；​
  

• 分片校验：对接收到的每个分片，计算 CRC32 校验码（与手机端上报的分片校验码比对），避免分片传输损坏；​
  

• 完整文件校验：拼接完成后，计算文件 SHA-256 hash（核心校验，用于后续比对）。​
  

（二）双阶段校验机制（快速对齐 + 精准匹配）​
阶段 1：元数据初筛（快速排除已同步文件）​

• 遍历范围：NAS 端正式相册目录（或用户指定的备份目录）+ 临时目录（未迁移的已完成文件）；​
  

• 比对逻辑：根据手机端上报的 “相对路径 + 文件名 + 文件大小 + 修改时间” 四元组进行匹配：​
  

• 完全匹配：直接标记为 “已同步”，无需计算 hash，反馈给手机端；​
  

• 部分匹配（路径 + 文件名相同，大小 / 修改时间不同）：标记为 “待 hash 校验”；​
  

• 无匹配：标记为 “待上传”（手机端需传输该文件）。​
  

阶段 2：hash 精筛（解决元数据冲突）​

• 批量计算：对 “待 hash 校验” 的文件，利用 NAS 多核 CPU 并行计算 SHA-256 hash（效率是手机端的 3-5 倍）；​
  

• 冲突判定：​
  

• hash 匹配：标记为 “已同步”（说明文件内容一致，仅元数据变更，无需重新上传）；​
  

• hash 不匹配：标记为 “冲突文件”，反馈给手机端让用户选择处理策略。​
  

（三）文件迁移与同步状态维护​
1. 从临时目录到正式目录的迁移​

• 迁移触发：临时目录中文件完成拼接 + hash 计算 + 校验通过后，自动触发迁移；​
  

• 迁移策略：​
  

• 新增文件：直接迁移至正式相册目录对应的相对路径下；​
  

• 覆盖文件：按用户预设策略（默认覆盖 / 保留旧文件 / 重命名新文件）执行；​
  

• 目录创建：若正式目录中无对应相对路径，自动递归创建目录。​
  

2. 同步索引库设计（核心优化）​

• 功能：存储所有已同步文件的 “元数据 + hash 值”，供后续快速比对（避免每次同步都遍历整个磁盘目录）；​
  

• 存储结构：采用轻量级数据库（如 LevelDB），索引键为 “设备 ID + 文件相对路径 + 文件名”，值为 “文件大小 + 修改时间 + SHA-256 hash + 同步时间”；​
  

• 更新机制：​
  

• 新增同步：文件迁移完成后，写入索引库；​
  

• 文件删除：手机端删除文件并同步后，索引库对应记录标记为 “已删除”；​
  

• 目录迁移：若用户迁移 NAS 相册目录，仅需更新索引库中 “目录根路径” 字段，无需重新计算所有文件 hash（解决目录迁移后快速对齐问题）。​
  

（四）增量同步与冲突处理​
1. 增量同步支持​

• 首次同步：完成索引库初始化后，后续同步仅需比对手机端上报的 “新增 / 修改” 元数据与索引库，无需遍历整个磁盘；​
  

• 变更检测：NAS 端定期扫描正式相册目录（可选功能，默认关闭），若发现文件被手动修改 / 删除，更新索引库状态，下次手机端同步时同步该变更。​
  

2. 冲突处理机制​

• 冲突场景：​
  

• 手机端文件与 NAS 端文件元数据匹配，但 hash 不匹配；​
  

• 手机端文件与 NAS 端文件同名，但路径不同；​
  

• 多设备同步同一目录导致文件覆盖。​
  

• 处理策略：​
  

• 默认策略：保留旧文件（NAS 端），新文件重命名（添加 “_设备 ID_时间戳” 后缀）；​
  

• 用户自定义：支持在 APP 端设置 “覆盖旧文件”“保留新文件”“提示用户选择” 三种策略；​
  

• 冲突日志：NAS 端记录所有冲突事件（文件路径、冲突类型、处理结果），供用户追溯。​
  

（五）性能优化​

• 并行计算：hash 计算采用多线程并行（线程数 = NAS CPU 核心数的 1/2，避免占用全部 CPU 资源）；​
  

• 磁盘 IO 优化：遍历目录时采用异步 IO，避免阻塞主线程；元数据读取优先从缓存读取，减少磁盘寻道时间；​
  

• 网络适配：NAS 端监听上传带宽，动态调整接收窗口大小，避免因接收速率不足导致手机端传输卡顿。​
  

五、关键场景落地流程​
场景 1：首次同步（NAS 端已有部分拷贝文件）​

• 手机端：扫描相册→采集全量元数据→分批上报 NAS；​
  

• NAS 端：​
  

• 元数据初筛：比对正式目录 + 临时目录，标记 “已同步”“待 hash 校验”“待上传”；​
  

• 批量 hash 计算：对 “待 hash 校验” 文件计算 hash，精准匹配后更新状态；​
  

• 反馈结果：向手机端返回 “已同步 X 个，待上传 Y 个，冲突 Z 个”；​
  

• 手机端：展示状态→对 “待上传” 文件启动多线程分片上传至 NAS 临时目录；​
  

• NAS 端：接收分片→拼接文件→hash 校验→迁移至正式目录→更新索引库；​
  

• 手机端：同步接收 “上传成功” 回执→更新本地同步状态。​
  

场景 2：NAS 相册目录迁移后重新同步​

• NAS 端：管理员迁移正式相册目录→更新索引库中 “目录根路径” 字段（无需重新计算 hash）；​
  

• 手机端：APP 重置备份设置→重新上报全量元数据；​
  

• NAS 端：通过索引库快速比对元数据→标记 “已同步” 文件，仅需同步新增文件；​
  

• 后续流程同 “首次同步” 的上传与迁移步骤。​
  

场景 3：增量同步（手机端新增 100 个文件）​

• 手机端：扫描相册→仅采集新增文件元数据→上报 NAS；​
  

• NAS 端：索引库比对→标记 “待上传”→反馈手机端；​
  

• 手机端：多线程上传新增文件至临时目录；​
  

• NAS 端：校验→迁移→更新索引库；​
  

• 手机端：更新同步状态。​
  

六、效果预期​
​

指标​	原方案（手机端 hash）​	新方案（NAS 端校验）​	提升幅度​
手机 CPU 占用率​	30%-50%（同步时）​	5%-10%（同步时）​	降低 80% 以上​
同步带宽利用率​	30%-40%​	85%-95%​	提升 120% 以上​
首次同步耗时（500G，含 300G 已存文件）​	8-12 小时​	2-3 小时​	缩短 75% 以上​
目录迁移后重新对齐耗时​	同首次同步（8-12 小时）​	5-10 分钟​	缩短 99% 以上​
增量同步耗时（10G 新增文件）​	1-1.5 小时​	15-20 分钟​	缩短 75% 以上​

​
七、风险与应对​
​

风险点​	应对措施​
元数据冲突导致误判​	增加 hash 精筛环节，覆盖 99% 冲突场景​
临时目录占用过多空间​	自动清理机制 + 管理员手动清理入口​
多线程上传导致分片丢失​	分片校验 + 断点续传 + 重试机制​
旧版 NAS/APP 兼容性问题​	支持流程降级，自动适配旧版本​
大文件传输卡顿​	智能分片 + 带宽动态适配​

​
八、迭代规划​
V1.0（核心功能落地）​

• APP 端：轻量元数据采集、多线程分片上传、同步状态展示；​
  

• NAS 端：临时目录管理、双阶段校验、文件迁移、索引库基础功能。​
  

V1.1（性能与场景优化）​

• 优化 NAS 端并行 hash 计算效率；​
  

• 支持用户自定义冲突处理策略；​
  

• 完善断点续传与后台上传稳定性。​
  

V1.2（高级功能）​

• 多设备同步冲突可视化；​
  

• NAS 端带宽限制与优先级设置；​
  

• 同步日志导出与追溯功能。
• 
  

先上传浪费流量

formycat 发表于 2025-11-5 23:02
先上传浪费流量

局域网有啥流量浪费不浪费的，讲真 对比下飞牛，这个相册同步备份的功能稀烂！！！

这是一个家庭NAS最最最基础的核心功能了，都做的如此稀烂， 难道用户备份的相册就只有几百张照片吗？ 不会吧？ 不是吧？
每个文件都要对比一下，你说对于有1T这种相册容量的手机用户要怎么办？？？

不信邪，你可以把你手机备份设置好的目录重新调整一下，开启备份再关闭，然后切换回原备份目录，你看看同步进度是如何处理的，一个个的比对好吧，这么搞，和NAS端对齐要到啥时候？？？

试试吧，看看是不是我说的