JuiceFS PB级数据同步对比：断点续传与带宽控制评测
在数据迁移、跨云同步和对象存储备份这类场景里，juicefs sync 几乎是个绕不开的工具。可一旦数据量到了 TB 甚至 PB 级，对象数量动辄上亿，单次任务的执行周期就能拖到几天甚至几周。
这时候，问题就来了：
- 任务跑到一半，网络抖一下、进程异常退出、节点重启了——再启动时，往往得从头扫描一遍，重新判定哪些已经同步、哪些还需要传。光是这个扫描过程，对亿级对象来说就是一笔巨大的时间和请求开销。
- 数据备份的明文传输，在某些合规需求面前明显不够用，加密成了刚需。
- 多个同步任务同时跑，带宽争抢得厉害，单靠每个任务各自限速，根本控不住总出口。
JuiceFS 1.4 这次在 sync 里补上了三块关键能力：断点续传、数据加解密，以及全局流量控制。下面就从场景、机制到使用方式，逐一展开聊聊。
01 断点续传
以前跑同步，最怕的就是中途断掉。重跑时，juicefs sync 得把源端和目标端重新扫一遍，对比出哪些已经传完、哪些还差着。对上亿对象或大文件场景来说，光是重新扫描这一轮，时间和请求开销就已经相当可观了。
1.4 里引入的 checkpoint 机制，就是为了解决这个痛点。任务启动后，sync 会把进度定期保存到目标端。如果中途中断，再跑一次相同的命令，它会自动找到对应的 checkpoint 文件，从上一次未完成的位置接着走，而不是重头来过。
工作原理
启用 checkpoint 后，sync 会在目标端生成一个 JSON 状态文件，文件名像这样：
.juicefs-sync-checkpoint..json 这个 hash 是根据源端、目标端和关键参数算出来的，目的是确保只有完全匹配的任务才能恢复对应的 checkpoint，避免误用。
整个流程大致是这样：
- 启动后，先在目标端查找匹配的 checkpoint。
- 找到就恢复，找不到就正常扫描开始同步。
sync会并发遍历多个前缀，每个前缀维护独立的状态，包括遍历是否完成、上次扫到哪个位置、待同步对象和失败对象列表。- 恢复时，先把之前记录的待同步对象和失败对象重新加入队列；对尚未遍历完的前缀，从中断位置继续扫描；已遍历完的，只处理还没传完的对象。
- 运行过程中，默认每 10 秒异步保存一次进度。
- 正常完成后，checkpoint 文件自动删除；如果中断或失败，文件保留，供下次恢复使用。
在集群模式下，checkpoint 由 Manager 统一维护。Worker 不直接写目标端文件，而是从 Manager 拉任务、执行同步、回传结果，Manager 再把结果合并到全局 checkpoint 里。
使用方式
# 启用断点续传
juicefs sync --enable-checkpoint SRC DST
# 自定义 checkpoint 保存间隔（默认 10s）
juicefs sync --enable-checkpoint --checkpoint-interval 30s SRC DST
# 忽略已有 checkpoint，强制从头同步
juicefs sync --enable-checkpoint --checkpoint-force-reset SRC DST02 数据加解密
跨云备份和归档场景里，客户端加密几乎成了标配——数据主权、静态保护、敏感数据迁移，哪条都躲不开。以前 juicefs sync 没有原生加解密能力，用户得自己搭一套额外工具。
1.4 把流式加密直接集成到了 sync 流程里，同步的同时就能加密、解密或重新加密，支持三类常见场景：
- 加密写入：明文数据加密后写到目标端，适合加密备份和归档。
- 解密恢复：从源端读加密数据，解密后写到目标端，适合数据恢复或明文迁移。
- 重新加密：用旧密钥解密，再用新密钥加密后写入，适合密钥轮换或算法迁移。
工作原理：分块流式加密
为了支持对象存储的 Range GET，同时避免大文件一次性加载到内存，sync 采用了 1 MiB 分块的流式加密方案。每个文件被拆成多个明文块，逐块加密后写入目标端。
原始文件结构：
[chunk 1: 1 MiB][chunk 2: 1 MiB] ... [chunk N: ≤1 MiB]加密后，每个明文块对应一个加密块。每个加密块由 4 字节头部（记录实际密文长度 ct_len）加密文数据组成：
[4B ct_len][ciphertext + padding]
好处是随机读取时只需定位到对应加密块，下载相关数据即可，不必拉整个文件。当然，因为多了头部、填充和加密元数据，目标端的对象会比原始文件大一些。
支持的算法
| 参数值 | 对称算法 | 密钥封装 | 适用场景 |
|---|---|---|---|
| aes256gcm-rsa（默认） | AES-256-GCM | RSA | 通用场景 |
| chacha20-rsa | ChaCha20-Poly1305 | RSA | 对 AES 硬件加速支持有限的环境 |
| sm4gcm | SM4-GCM | SM2 | 需要国密算法的场景 |
使用方式
下面以 RSA 密钥为例，展示加密、解密和重新加密的用法。
生成密钥对：
# 生成 RSA 私钥（公钥内嵌其中，JuiceFS 自动提取）
openssl genrsa -out private.pem 2048
# 带密码保护的私钥
openssl genrsa -aes256 -out private.pem 2048场景一：加密写入目标端
juicefs sync /local/data s3://mybucket/backup
--encrypt-rsa-key /path/to/private.pem场景二：解密读取源端，用于数据恢复或明文迁移
juicefs sync s3://mybucket/backup /local/data
--decrypt-rsa-key /path/to/private.pem场景三：重新加密，用于密钥轮换或算法迁移
juicefs sync s3://old-bucket/encrypted s3://new-bucket/re-encrypted
--decrypt-rsa-key /path/to/old-private.pem
--encrypt-rsa-key /path/to/new-private.pem如果私钥有密码保护，可以通过环境变量传入
# 加密场景使用 JFS_ENCRYPT_RSA_PASSPHRASE
export JFS_ENCRYPT_RSA_PASSPHRASE="your-passphrase"
juicefs sync /local/data s3://mybucket/backup --encrypt-rsa-key private.pem
# 解密场景使用 JFS_DECRYPT_RSA_PASSPHRASE
export JFS_DECRYPT_RSA_PASSPHRASE="your-passphrase"
juicefs sync s3://mybucket/backup /local/data --decrypt-rsa-key private.pem注意
- 加密后的数据采用 JuiceFS 私有格式存储，必须通过
juicefs sync并提供对应密钥才能解密读取。 - 私钥请务必备份妥善；一旦丢失，已加密数据将无法恢复。
03 全局流量控制
之前 juicefs sync 已经支持 --bwlimit 对单个进程限速。但多个 sync 同时运行时——比如分布式同步里的多个 Worker，或者多个独立任务共享同一条出口链路——单进程限速就管不住了，出口带宽很容易被打满。
1.4 新增的 --traffic-control-url 参数，就是让多个 sync 进程接入同一个外部流量控制服务，统一分配带宽配额，实现跨进程、跨任务的全局限速。
工作原理
这里用的是令牌桶模型。多个 sync 进程在传输数据前，都向同一个流量控制服务申请字节配额：
每个 sync 进程在传输前，向控制服务申请一定数量的字节配额（credit）。服务根据当前总带宽使用情况，决定授予多少配额以及有效时间。配额用完后继续申请；如果配额即将过期但没用完，未使用的部分会提前归还。
控制服务通过 HTTP 接口提供配额申请和归还能力，接口需要用户自行实现或接入现有服务：
POST /traffic-control
Content-Type: application/json
请求：
{"bytes": 1048576}
bytes > 0: 申请 bytes 字节的额度
bytes < 0: 归还 |bytes| 字节的未使用额度
响应：
{"granted": 524288, "expired": 1000}
granted: 本次授予的字节数
expired: 额度有效期（毫秒）同步过程中，sync 会在传输前申请配额。如果没有可用配额，传输会阻塞等待，直到获得新配额。这样一来，多个同步任务就能共享同一个全局带宽上限，避免各自限速但总流量失控的问题。
使用方式
# 先部署流量控制服务（示例：监听 8080 端口，限制总带宽 100 Mbps）
# （服务实现由用户自行决定，juicefs 只负责调用接口）
# 多个 sync 进程接入同一个控制服务
juicefs sync SRC1 DST1 --traffic-control-url http://127.0.0.1:8080/traffic-control &
juicefs sync SRC2 DST2 --traffic-control-url http://127.0.0.1:8080/traffic-control &--traffic-control-url 可以与 --bwlimit 同时使用，两个限制独立生效：--bwlimit 限制单个进程的最大带宽，--traffic-control-url 控制多个进程的全局带宽。
# 单进程不超过 50 Mbps，同时所有进程合计不超过服务端配置的上限
juicefs sync SRC DST
--bwlimit 50
--traffic-control-url http://controller:8080/traffic-control04 小结
JuiceFS 1.4 对 sync 的这三项增强，分别对应了实际运维中几个很具体的痛点：断点续传降低了中断恢复的成本，数据加解密让备份和迁移更安全，全局流量控制则让多任务并发时带宽分配更有序。对于数据迁移、跨云同步、对象存储备份和加密归档这些场景，用户可以根据自己的任务规模、网络条件和安全要求，灵活组合使用这些能力。