本文主要是介绍详解 JuiceFS sync 新功能，选择性同步增强与多场景性能优化，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
JuiceFS sync 是一个强大的数据同步工具，支持在多种存储系统之间进行并发同步或迁移数据，包括对象存储、JuiceFS、NFS、HDFS、本地文件系统等。此外，该工具还提供了增量同步、模式匹配（类似 Rsync）、分布式同步等高级功能。
在最新的 v1.2 版本中，针对 Juice sync 我们引入了多项新功能，并对多个场景进行了性能优化，以提高用户在处理大目录和复杂迁移时的数据同步效率。
新增功能
增强选择性同步
** 匹配规则
在 v1.2 版本以前，JuiceFS sync 不支持 ** 匹配（匹配任意路径元素，包括 /）。例如，当用户在传输中需要排除某个名为 bar 的文件，该文件位于根目录下 foo 目录再向下递归任意层级。之前的版本无法处理这一需求，在 v1.2 中，该需求就可以通过 --exclude /foo/**/bar 来实现。
一次性过滤模式
在 v1.2 版本以前，JuiceFS sync 同步数据的过滤模式为“逐层过滤”，这种模式与 Rsync 的行为基本一致，用户可以将 Rsync 的经验应用到 JuiceFS sync 。然而，很多用户反馈，这种过滤模式在一些场景下比较难以理解与使用。
例如“只同步根目录下 /some/path/this-file-is-found”这个需求时，使用逐层过滤模式的规则写法为：
--include /some/
--include /some/path/
--include /some/path/this-file-is-found
--exclude *
这个规则可能会让不熟悉逐层过滤模式的用户感到困惑（关于逐层过滤的使用文档请看参考这里）；同时，对于这个简单的需求，这种写法也显得异常繁琐。
因此，在 v1.2 版本中新增了 “一次性过滤” 模式， 同样针对上述例子，“只同步根目录下 /some/path/this-file-is-found”，使用 “一次性过滤” 模式的写法就极为简单而且便于理解：
--include /some/path/this-file-is-found
--exclude *
--match-full-path
用户可通过 --match-full-path 开启这个模式。
原理
针对待匹配的对象，“一次性过滤” 模式直接将其完整对象名与多个模式进行依次匹配。流程如下图所示：
以下是一些 exclude/include 规则一次性过滤模式的例子：
--exclude *.o将排除所有文件名能匹配*.o的文件。--exclude /foo**将排除传输中根目录名为foo的文件或目录。--exclude **foo/**将排除所有以foo结尾的目录。--exclude /foo/*/bar将排除传输中根目录下foo目录再向下两层的bar文件。--exclude /foo/**/bar将排除传输中根目录下foo目录再向下递归任意层次后名为bar的文件。( ** 匹配任意多个层次的目录)- 同时使用
--include */ --include *.c --exclude *将只包含所有目录和 C 源码文件，除此之外的所有文件和目录都被排除。 - 同时使用
--include foo/bar.c --exclude *将只包含foo目录和foo/bar.c。
inplace 参数
--inplace 参数引入了一种新的数据写入方式，允许 JuiceFS sync 原地写入目标文件。JuiceFS sync 同步数据到文件系统类型的存储（File，HFDS，NFS，SFTP）时，默认会在目标端先创建一个临时的文件，将数据先写入临时文件，最后再调用 rename 完成数据同步。这种方法虽然减少了对目标端文件系统的影响，但是 rename 也带来了一定的性能开销。从 v1.2 版本开始，用户可通过 --inplace 参数改变这一默认行为，允许用户直接将数据写入最终的目标文件，即使文件已经存在（已经存在文件其内容会被清空）。
进度指标
JuiceFS sync 的同步进度，会通过进度条的方式打印在终端中，这使得用户可以便捷地观测进度，但这种方式不便于其他应用程序准确地获取该信息。为此我们为 sync 子命令添加了 --metrics 参数，该参数允许将 sync 的进度以一系列 Prometheus 指标的形式暴露在特定的地址。
juicefs_sync_checked{cmd="sync",pid="18939"} 1008
juicefs_sync_checked_bytes{cmd="sync",pid="18939"} 3.262846983e+09
juicefs_sync_copied{cmd="sync",pid="18939"} 0
juicefs_sync_copied_bytes{cmd="sync",pid="18939"} 0
juicefs_sync_failed{cmd="sync",pid="18939"} 0
我们还添加了--consul 参数，该参数允许将 sync 服务注册到 consul 中。
性能优化
在 v1.2 版本中，我们针对以下 3 个场景做了性能优化
超大文件同步
在 v1.2 版本以前，JuiceFS sync 传输超大文件时，会遇到内存占用过高或者带宽无法跑满的问题。核心原因是超大文件同步我们使用的是分块上传的方法 ，它会对原始对象先分块再并发上传块，由于分块数量最多为 10000，所以原始对象越大分块越大，分块越大同样的并发下内存占用就会越高（内存占用 = 并发度 x 块大小）。
为了避免同步超大对象时内存占用过高，一种方案是减少并发度，但这样会导致带宽未能充分利用，因此这不是一个理想方案。另一种方案是减少实际上传时分块大小，同样的并发度下，分块越小内存占用越低。通过减小实际上传时分块的大小，我们可以根本上降低内存占用。
基于第二个方案，在 v1.2 版本中，我们优化了超大文件同步的逻辑，详细流程如下图所示。简单来讲，对于初次分块后仍旧过大的块，我们会再次进行分块上传，合并得到一个普通对象，然后调用 UploadPartCopy API 再将其转化为一个分块，最终合并所有分块即可。
整个过程相比以前多了一次分块拆分，带来的好处是经过两次拆分，降低了实际上传时的分块的大小，这样就从根本上解决了超大文件同步时内存占用过高和带宽无法跑满的问题。
强制更新模式
JuiceFS sync 默认会同时 list 源端与目标端的对象列表，通过两边对比，跳过那些已经在目标端存在的对象。在使用 --force-update 参数时，将强制同步源端所有对象。 在这种情况下，目标端的 ListObjects 请求不再必要。为了提高效率，在 v1.2 版本中，我们对此进行了优化，当使用 --force-update 参数时不再 list 目标端。这个优化在同步数据到超大目录时可大幅提高性能。
同步单个文件
当用户遇到下面这种单个文件同步的场景：
juicefs sync s3://mybucket1.s3.us-east-2.amazonaws.com/file1000000 s3://mybucket2.s3.us-east-2.amazonaws.com/file1000000 --limit 1
JuiceFS sync 默认会 list 源端与目标端的对象列表，目的是通过比较跳过目标端已经存在的对象。而上述这个场景只需要同步 file1000000 这一个对象即可。为了获取一个对象的信息而 list 整个 bucket 是低效的。我们可以用 HeadObject API 直接请求 file1000000 这个对象的信息即可。
所以在 v1.2 版本中，针对同步单个文件的场景，在获取待同步对象信息时，我们使用 HeadObject API 替换 ListObjects API ，这个优化对于在超大目录之间同步单个文件有很大的性能提升。
欢迎大家下载试用：https://github.com/juicedata/juicefs/releases/tag/v1.2.0-beta1
这篇关于详解 JuiceFS sync 新功能，选择性同步增强与多场景性能优化的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
