共计 11874 个字符，预计需要花费 30 分钟才能阅读完成。
内容速览：
本期分享的题目是 Alluxio 元数据和数据的同步，从设计实现和优化的角度进行探讨，包含以下 6 个方面内容：
01. Alluxio 简介
Alluxio 是云原生的数据编排平台，通过解耦计算和存储层，在两头产生了一个数据编排层，负责对下层计算利用暗藏底层的工夫细节。
02. Alluxio 的数据挂载
挂载操作有一个进阶版操作，所做的事件就是让用户能够把两个存储挂载到同一个门路下，能够相互笼罩。同时通过配置读写策略，定义读写文件到哪个存储里，并给出操作的先后顺序。
03. Alluxio 和底层存储的一致性
Alluxio 和底层存储的一致性，要从 Alluxio 命名空间中文件的起源说起。
文件的操作分为两类：
（1）下层利用通过 Alluxio 创立一个文件，通过 Alluxio 写入 UFS；
（2）下层利用通过 Alluxio 读一个文件，当发现自己没有这个文件的时候，Alluxio 从 UFS 进行加载。
一致性能够分为两个局部：
（1）Alluxio UFS 元数据的一致性；
（2）Alluxio UFS 数据的一致性。
04. Alluxio 和 UFS 的元数据 / 数据同步
Alluxio 提供两种同步机制，一个是工夫戳机制，另一个是基于音讯的同步机制。
05. 元数据同步的实现原理和优化
目前元数据的同步粗略分为以下几个步骤：
（1）RPC 线程向 UFS 读取文件的元信息。
（2）如果在解决递归的时候，发现上面还有其余目录，整棵树都须要进行一次搜寻，此时把递归文件 / 文件夹提交到同步线程池（sync thread pool）。
（3）预取线程池负责从读取文件或者文件夹信息，把后果交给这个同步线程池，来减速这个具体的同步过程。
优化次要蕴含 3 种形式：
（1）性能优化 - 缓存；
（2）算法优化 - 锁优化；
（3）性能优化 - 调整并行度；
06. 对不同场景的举荐配置
场景一：文件全副由 Alluxio 写入，之后从 Alluxio 读取。
场景二：大部分的操作通过 Alluxio，但不排除有一些场景会绕过 Alluxio 间接改变原来外面的文件。
场景三：大部分或全副更新都不通过 Alluxio，而更新又十分频繁。
以上仅为大咖演讲概览，残缺内容可点击观看：
附件：大咖分享文字版残缺内容可见下文
01. Alluxio 简介
Alluxio 是云原生的数据编排平台，通过解耦计算和存储层，在两头产生了一个数据编排层，负责对下层计算利用暗藏底层的工夫细节。Alluxio 提供了对立的存储命名空间，在中间层提供了缓存和其余数据管理性能。在下图能够看到有 Spark、Hive、Map reduce 这一类传统的 Hadoop 大数据计算利用、Presto 这种 OLAP 类型的数据分析，还有像 Tensorflow、Pytorch 这样的 AI 利用。存储层比拟丰盛，包含各种各样的存储。
上面是 Alluxio 用户列表，这些公司都公开展现了 Alluxio 的应用场景。通过粗略分类，看到十分多的行业，包含互联网、金融、电子商务、娱乐、电信等。感兴趣的同学能够关注公众号，下面有相干文章的汇总。
02. Alluxio 数据挂载
这部分将首先回顾 Alluxio 如何通过数据挂载实现对立编排层；之后探讨 Alluxio 如何和底层存储保持一致；介绍元数据和数据同步性能；Alluxio 的工夫原理和优化；最初对不同场景的举荐配置给出倡议。
1. Alluxio 对立的数据命名空间
首先介绍数据挂载这个性能。Alluxio 通过把底层存储挂载到 Alluxio 层上，实现了对立的数据命名空间。
上图的例子中 Alluxio 挂载了 HDFS 和对象存储。Alluxio 的文件系统树就是由左右两棵树合成，造成了一个虚构文件系统的文件系统树。它能够反对十分多的底层存储系统，对立把它们称作 Under File System。称为 Under 是因为它们都处于 Alluxio 的形象层下。Alluxio 反对各种各样不同的底层存储系统，比方不同版本的 HDFS，反对 NFS, Ceph, Amazon S3, Google Cloud 之类不同的对象存储。除此之外还反对十分多其余类型的对象存储，比方微软 Azure、阿里、华为、腾讯，也包含国内其余供应商，如七牛对象存储。左下图中的例子是在本人的电脑上运行 Alluxio，能够挂载不同的存储，比方挂载 HDFS，另外还能够挂载不同版本的 HDFS，挂载对象存储，挂载网盘。
2. Alluxio 挂载点
Alluxio 的对立命名空间，理论就是把挂载合成了一个 Alluxio 的虚构层。Alluxio 的挂载点能够粗略分成两种：
（1）根挂载点
（2）嵌套挂载点
根挂载点间接挂在根节点上，组成了 Alluxio 的根节点。如果没有根节点，无奈产生，持续造成上面的构造。所以要求在配置文件外面定义根挂载点，系统启动的时候就进行挂载，不挂载就没有方法启动。
嵌套挂载点比拟灵便，能够通过指令进行挂载。通过这个命令行，发出通知，做挂载的操作。同样地，能够挂载，也能够卸载，就是把 Mount 换成 Unmount。嵌套挂载点是嵌套在目录的上面，能够挂在某个局部上面，不肯定挂载在根节点上面。这里有个要求，即两个嵌套点的树不能相互笼罩，这样带来的益处是比拟灵便。如果根挂载点未来须要更换，为了防止须要改配置和重启服务，能够应用一个 dummy 的根挂载点，比方就挂载在本地门路上面，不应用它，且不在它上面创立任何文件，它存在的惟一目标就是能够启动 Alluxio 服务。而后在此基础上，把所有要治理的存储，都以嵌套挂载点的形式挂载下来。之后如果要扭转，就间接卸载更换为其它挂载点，这样就很灵便。所有挂载和挂载操作，都会记录在日志里，重启零碎，并重启服务之后，无需再手动操作。
3. Alluxio 策略化数据管理
挂载操作有一个进阶版操作，目前只蕴含在商业版本外面。所做的事件就是让用户能够把两个存储挂载到同一个门路下，能够相互笼罩。同时通过配置读写策略，定义读写文件到哪个存储里，并给出操作的先后顺序。同时 Alluxio 有一个迁徙策略，让文件能够主动在 Alluxio 的治理下，在多个存储之间进行迁徙。例如，把 HDFS 和对象存储同时挂载到同一门路下，下层用户只能看到这样一棵树，然而实际上背地有两个不同的存储。通过配置，让 Alluxio 把 HDFS 的数据，依据一些规定，定期迁徙进 S3，例如规定将超过七天的数据，认定是不罕用到的冷数据之后，把它从 HDFS 的集群拿进去，迁徙到 S3，节俭 HDFS 的存储空间。
03. Alluxio 底层存储一致性
在把底层存储挂载到 Alluxio 的对立命名空间上之后，如何放弃 Alluxio 和底层存储的一致性？咱们在这一部分进行剖析。
Alluxio 和底层存储的一致性，要从 Alluxio 命名空间中文件的起源说起，文件的操作分为两类：
一类是写，下层利用通过 Alluxio 创立一个文件，通过 Alluxio 写入 UFS；
一类是读，下层利用通过 Alluxio 读一个文件，当发现自己没有这个文件的时候，Alluxio 从 UFS 进行加载。
一致性能够分为两个局部：
（1）Alluxio UFS 元数据的一致性
（2）Alluxio UFS 数据的一致性
上面先看写数据的一致性：
1. Alluxio 写文件流程
首先 Alluxio 写文件的流程能够把它形象成两步：
第一步是客户端到 Alluxio；
第二步是 Alluxio 到 UFS。
其中的每一步都能够形象成上面的三个步骤：
（1）创立文件
（2）写数据
（3）提交文件
同样 Alluxio 到存储系统也能够同样地形象提取。
客户端和 Alluxio 之间，次要流程分三步：
（1）客户端向发申请创立一个文件；
（2）找到 Alluxio Worker 写具体对应的数据；
（3）在写完数据之后，提交这个文件。
同样 Alluxio 到存储系统也形象成三步。不同存储系统的形象和具备的一致性，都不同，此处进行形象只是为了便于了解。比方要求强一致性保障，然而很多对象存储，给的一致性保障会弱很多，比方写进去之后不能马上读到这个数据。在这里，不思考这种自身的不一致性的问题。假如 Alluxio 向存储提交了之后，就能保障存储端的文件就是须要的样子。
Alluxio 为了满足不同的需要，设计了几种不同的写策略，上面逐个剖析写策略的流程以及带来的数据一致性保障。
2. Must-Catch 写模式
首先是罕用的 MUST_CACHE 模式。在这种模式下，只会写 Alluxio 缓存不写 UFS。这个模式分为三步：
首先客户端会向 Alluxio 收回创立文件申请，创立的文件只是一个空文件，作为一个占位；
之后 Alluxio Worker 实现具体数据的写操作，具体数据会被宰割成多个数据块，作为 Block 存在于 Alluxio Storage 外面。
在缓存写之后，客户端对 Master 做提交文件的申请，通知 Master 写了这些数据块，写到 Worker，而后更新对应的元数据，也晓得了这些数据块和 Worker 所对应的地位。
在这样的流程之后，Alluxio 不会向 UFS 创立这个文件，也不会写这个文件，所以 Alluxio 和 UFS 之间的元数据和数据都不统一。
3. Through 写模式
THROUGH 的写模式有所不同，这里同样的 createfile() 收回一个申请，而后找 Worker 写数据。Worker 会做三件事：
（1）创立文件
（2）写文件
（3）提交文件
在第二步完结后，客户端会向 Alluxio 提交这个文件。因为 Alluxio 的提交是产生在文件写完了之后，所以，Alluxio 和 UFS 此时的元数据是统一的。因为没有数据缓存，所以也不存在数据一致性的问题。
Alluxio 的缓存是在须要读之后才会产生，而这种 THROUGH 模式是比拟适宜用来写已知不再会被 Alluxio 读取的数据。所以在这种状况下，元数据是统一的，也不存在数据不统一的问题。
4. CACHE_THROUGH 写模式
上面的 CACHE_THROUGH 模式就是后面两种模式的联合。
惟一的不同点是在第二步，写缓存的同时又写了 UFS。在这两个都胜利之后，第二步才会胜利，之后客户端才会做提交操作。同样的情理，因为 Alluxio 在 UFS 更新之后才更新，所以两者的元数据和数据都是统一的。
5. ASYNC_THROUGH 写模式
最初是 ASYNC_THROUGH 异步写模式，和后面的模式惟一的区别是第二步中的 UFS 写变成了异步，放在了第四步。
在 Alluxio 写缓存之后，首先创立了文件之后，在第二步写了 Alluxio 缓存；在第二步缓存写完之后，Worker 就向客户端返回胜利；而后由客户端向 Master 提交文件。留神在这个时候，Worker 还没有去 UFS 创立这个文件，也没有向 UFS 写文件。在 Alluxio 向客户端返回申请胜利之后，在之后的某个工夫，由 Job Service 把这个文件创建到 UFS 外面，并且长久化。
须要留神：在异步的模式下，长久化因为某些起因失败了，比方 Alluxio 胜利之后，忽然有人间接向外面创立了一个同名的文件，在第四步的时候，因为缓存和之间产生了不统一，导致这个文件无奈创立、无奈写入。这个时候，Alluxio 会有不统一的问题，此时须要人工染指来解决这个抵触。
6. 读文件流程
前文介绍以上四种不同的写模式以及一致性保障，当初来看 Alluxio 的读文件流程。读文件也能够粗略分成两种：冷读和热读。
简略来说，冷读状况下 Alluxio 不晓得这个文件，须要从加载元数据和数据。热读的时候，缓存命中，不须要加载元数据和数据。
① 冷读文件
在冷读流程里，客户端向 Alluxio 申请元数据，此时 Master 还没有这个元数据，所以会向 UFS 收回一个申请，并从 UFS 加载这个元数据，这也称之为元数据同步。
在客户端具体读数据的时候，客户端找到 Worker，Worker 此时还没有缓存，于是 Worker 会向 UFS 做缓存的加载，这就是常说的缓存冷读。在做完这两个步骤之后，缓存是和元数据统一的。
② 热读文件
在热读的状况下，元数据能够在缓存外面找到，数据能够在 Worker 外面找到；此时不会有对 UFS 的读申请。
在缓存命中的时候，如何保障缓存与和是统一的？这里包含元数据的统一和数据的统一。这个简略的来说，就是通过 Alluxio 的元数据和数据的同步机制，也就是下一部分的内容。
04. Alluxio 和 UFS 元数据和数据同步
1. 查看 Alluxio 元数据 / 数据一致性
首先思考这个问题：在什么时候须要查看 Alluxio 的元数据和数据的一致性？
首先在写数据的时候须要查看。如果这个文件在曾经存在了，作为缓存，除了放弃这个操作之外，也没有其余的选项。因为不能在用户不知情的状况下，笼罩掉用户在外面的数据。
在读数据的时候，同样须要思考如果文件在外面曾经更新了，那缓存也须要对应进行更新，须要 UFS 思考外面的文件是否产生了变动。
2. 保障 Alluxio 元数据 / 数据一致性
元数据和数据的一致性分成两步来一一探讨。首先探讨如何保障 Alluxio 元数据和统一。Alluxio 通过两种形式来保障：
① 通过基于工夫的假如
第一种是通过基于工夫的假如，在外面的文件，在一段时间内它是不变的。判断办法是在每一次文件源信息、元数据申请的时候，查看 Alluxio 的元数据是否足够新。
这个判断分成了两个不同的局部：
（1）在每一次申请的时候
（2）查看这个元数据是否足够新
这种元数据的同步机制是惰性的，只有在申请的时候才会进行查看。这样设计的理念是尽量避免拜访慢的操作、低廉的操作。这样的事件越少越好、越懒越好。如果 Alluxio 所知的文件信息足够新，就假如 Alluxio 和 UFS 是统一的。如果不够新，就放弃这个假如再做一次同步；同时更新 Alluxio 外面的元数据。
② 基于告诉
另外一个思路就是摈弃基于工夫的假如，基于告诉，依赖文件更改的告知。这个不是假如，是一个确定的信息。如果没有告诉文件有变动，就确定 Alluxio 和当初的文件是统一的。
其次是如何保障 Alluxio 和 UFS 的数据保持一致。思路也非常简单：保持数据的统一，只须要确定元数据及是否统一。这里做出的假如是：如果 UFS 的数据，文件内容有所扭转，那这个扭转肯定会反映在文件的元数据上。要么是文件的长度扭转，要么是这个文件的 Hash，也就是哈希值会产生扭转。通过观察这个 Alluxio 和的元数据，能够发现这些变动点。
如果基于这个假如，Alluxio 的元数据和 UFS 保持一致时缓存和 UFS 也会统一。如果察看元数据发现内容有变动，那么就更新元数据并摈弃已有缓存。在下一次读的时候，从新加载缓存。如果发现文件的内容没有变动，只做必要的元数据更新，不摈弃数据缓存。
3. 数据同步机制
Alluxio 提供两种同步机制，这里先介绍工夫戳机制，再介绍基于音讯的同步机制。
① 基于元数据工夫戳的同步机制
上面先看一下第一种机制，基于元数据工夫戳的同步机制。
工夫戳次要是通过配置项 alluxio.user.file.metadata.sync.interval，通常称之为 sync.interval 或者 interval。比拟同步数据上次同步的工夫戳和配置项。配置项中有几种不同的配置形式：
（1）配置为 -1，就只在第一次加载的时候进行同步，之后就永远不再和这个底层存储去做同步了；
（2）配置为 0，每一次拜访的时候，都会进行同步，摈弃所有常识，不做任何假如。
（3）比拟罕用的一种是用户指定一个配置值，做一个假如，如果上一次同步的工夫还没有超出这个工夫，就假如原信息是新的。这个假如是基于对这个文件的理解，比方：晓得文件的起源，晓得文件由哪些业务流程产生的。在此基础上，能够做一个正当的推断：只需每隔这样一段时间去查看的就足够。如何进行配置，请看下图。
（4）这张图展现了不同的配置形式带来什么样的行为。这张图的纵轴是一个 RPC 实现所需工夫。不同的环境、不同测试形式都会失去不一样的后果。次要看相互之间的大小关系。如果把 interval 设成零，就是每一次都同步，那每一个 RPC 都会有元数据同步的开销，提早会比拟高；
（5）如果 interval 设为 -1，齐全关掉同步，只有文件存在于 Alluxio 外面，实现第一次加载，之后的每一次，RPC 都会有一个低的提早，因为没有做 UFS 的操作。
（6）最罕用的是设置成一个适中的值，实际上带来这样一个后果，就是如果还在 interval 之内，RPC 能失去疾速的返回；如果达到了 interval，触发一次同步，那在下一次 RPC 就会有一个比拟高的开销。通过这样的形式，实际上把这个元数据同步的开销，均匀到每一次的 RPC 申请中。这也是为什么大家比拟喜爱这种形式，因为获得了一个均衡。
② 同步工夫距离配置
这个工夫距离具体配置有三个，优先级是由低到高，前面的配置能够笼罩后面的配置：
第一种最根底是配置文件 / 环境变量形式，是最不灵便的形式。因为整个集群外面文件都不同，假如也不同，很难应用同样距离，所以个别都给一个默认值。
第二种形式是基于门路的设置做配置。比方：通过管理员指令给这个 Alluxio 的 /data_center1 门路，增加 property 也就是 sync.interval。意思就是假如来自数据中心这个门路下的所有文件夹上面所有门路，都依照一个小时一次的工夫距离，在超过一个小时之后，才去再进行一次原文件的同步。这样的假如的本源就是：晓得来自数据中心的文件，它的更新不是特地频繁，那能够做出这样的一个判断。
第三种形式是间接写在指令外面。ls 是大家最罕用的命令。比方：对 /data/tables 上面的文件做 ls 操作的时候，给予一个大于零的值。意思就是：如果因为不小心误操作或者多做了几次 ls，不小心多敲了几次回车或者脚本写错，至多还有一个盘旋的余地，不会一下子触发大量元数据同步的操作。
Alluxio 还提供一些语法糖指令，比方：loadMetadata 指令就是专门为了触发元数据同步。如果加上 - F 选项，实际上的意思就是把 sync.interval 设成 0，相当于强制进行一次元数据的刷新。ls 和 metadata 这两个指令的区别：ls 把文件展现在背后，ls 的 RPC 有网络开销，会把信息发给你，客户端要保留下来，并且展现进去。这个不是每一次都须要，如果只是想要触发一次元数据的同步，只需 loadMetadata 就能够，返回值只有胜利或者失败，能够节约很多网络带宽和的内存开销。
③ 基于音讯的同步机制
以上是基于工夫的同步机制，上面看一下另外一种思路，就是基于音讯同步机制。
首先须要 Alluxio 2.0 版本以上，以及 Hadoop 2.6.1 版本以上，因为 HDFS 底层的 inotify 机制是在 2.6 版本加进去的。实际上产生的就是从 HDFS 的 namenode 间接读取 HDFS 有哪些文件产生了变动。实现原理就是保护了一个 Alluxio 和 namenode 之间通过 HDFS 的 inotify 机制放弃了一个信息流。Alluxio 定期心跳从这个信息流外面去读，有哪些文件产生了变动，而后依据这个变动的具体的类型，Alluxio 决定要不要再去 namenode 触发一次元数据的同步。
这样的元数据同步是对症下药，不再是基于工夫猜想。每一次同步都是有理有据，晓得文件曾经扭转，称为 Active Sync，也是因为在这里化被动为被动，不再被动去猜，而是被动晓得了有哪些变动，而后被动去触发同步。然而这个 inotify 只能通知通知咱们哪些文件产生了变动以及变动是什么类型，蕴含的信息很少，具体要做同步还须要一个元数据同步的机制，所以这一步是绕不开的。具体的应用也非常简单，能够通过指令来开启它，也能够敞开，或者查看当初有哪些 HDFS 门路或挂载点开启了这个性能，这些指令也受 Journal 日志爱护，当开启了 Active Sync 性能之后，就会被记录在 Journal 日志外面，在重启集群之后，无需重敲一遍指令。
4. Active Sync 性能取舍
Active Sync 也不是万能药，它做了一些性能的取舍。每种设计都有它的取舍，因而也有适宜和不适宜的场景。
Active Sync 在确定了文件更改之后，再去做同步操作，它省掉了那些没有变动、无用的同步操作。然而每一个文件的更改，都会触发同步操作。具体文件的更改并不一定是客户端的申请，尽管是被动加载它，但实际上并不一定用到，有可能是多余的操作。
Active Sync 和基于工夫戳的同步机制，各有利弊。具体抉择时须要进行考量，在前面的章节会总结剖析哪种场景适宜的配置。同时要留神 Active Sync 只反对 HDFS，起因是只有 HDFS 提供 API，其余存储没有机制能够晓得有哪些文件产生了变动，所以没有方法来实现。
05. 元数据同步实现与优化
在理解了机制后，当初理解一下元数据同步的实现原理，而后再看元数据同步的优化。
1. 元数据同步原理
目前元数据的同步粗略分为左下角的这几个步骤。左上角咱们列出了元数据同步的参与者。包含了 RPC 线程，就是 Master 端，来自于 RPC 的线程池。第 2 个参与者称作同步线程池（sync thread pool）。第 3 个参与者称作预取线程池（prefetch thread pool）。这里有一个 InodeTree，就是 Alluxio 外面保护的所有文件的元数据，造成了一个树状的构造。图中的 UFS 代表着理论的底层存储。所有对 UFS 的连线都是一个对外部零碎的 RPC，是比拟低廉的操作。
同步步骤分三步：
① RPC 线程向 UFS 读取文件的元信息。在解决申请 ls -R 时，对根节点全量的文件树进行一次 ls 操作。此时基于工夫戳，须要触发元数据同步，RPC 线程就会读取文件根节点的信息，查看挂载 HDFS://alluxio 根节点的信息。如果发现信息有更新，就去 InodeTree 外面找根节点，则 RPC 线程对应地更新 / 创立 / 删除 Alluxio 的 Inode 元信息，并且这个节点进行更新。
② 如果在解决递归的时候，发现上面还有其余目录，整棵树都须要进行一次搜寻，此时把递归文件 / 文件夹提交到同步线程池（sync thread pool）。用广度优先搜寻的形式进行遍历，也就是常说的 BFS。当提交这个工作后。会去同步线程池，在 BFS 的过程中，依照肯定的程序遍历这棵树，data -> user -> others -> report …
在这个过程中，次要是做两件事件：
（1）如果发现走到某个节点，须要对进行一次申请，它不会本人做这个申请，而是把这个申请交给预取线程池（prefetch thread pool）。
（2）如果发现下一步要去遍历 User -> others -> report …
就把工作提前交给预取线程池，通知它去读 HDFS 外面相干的这些门路，这也就是称为预取的起因。在真正解决这个门路之前，就提前通知它，因为操作会须要很长的工夫，保障性能最好的形式就是提前做这个事件；等工作解决到的时候，曾经筹备好了。这样最高地利用了多线程的并发。
在解决每个节点的时候，确认预取线程池筹备好的后果；如果有更新，就更新本人的 InodeTree。
③ 预取线程池负责从读取文件或者文件夹信息，把后果交给这个同步线程池，来减速这个具体的同步过程。
2. 性能优化 - 缓存
在这个工夫原理的根底上，进行了一系列的优化。
首先就是做了缓存的优化。次要的设计理念就是因为 UFS 操作十分贵、十分慢，心愿尽可能多的地缓存后果，节俭的操作。
缓存优化波及上面这几种缓存：
（1）缓存了哪些门路不存在，因为确定这个缓存不存在，须要去读取 UFS，又须要有一个内部的 RPC；
（2）缓存哪些 UFS 文件最近被读取过，和工夫戳相互配合。晓得上一次读取的工夫戳，就能够依据工夫戳确定是否再次读取；
（3）缓存 UFS 文件的具体信息，预取线程和同步线程用来替换信息的数据结构。在预取完之后把后果放到缓存里，由这个同步线程将后果更新进 Alluxio InodeTree。
3. 算法优化 - 锁优化
在缓存优化之外，基于 Alluxio 的版本迭代，也做了各种各样的元数据同步优化，其中比拟大的就是算法的优化。
在 Alluxio2.3 版本之前，所有的 RPC 线程是本人进行元数据的同步。如果递归基于 DFS 本人遍历这棵树，从头到尾都持有门路的写锁。如果是递归，实际上是写锁锁住了整个子树。在锁住子树的过程中，其余线程就无奈读取子树里的内容，并发度低，因为是单线程，做了十分多须要 Block 工夫长的操作。
在 Alluxio2.3 外面十分大的优化，就是把它改成了多线程并发同步的算法，更多利用线程池操作，DFS 改成了 BFS。依据须要，读锁降级，而非从头至尾持有写锁。读写锁的益处就是让不同的线程之间有了更高的并发度。这样在同步某一棵子树的过程中，其余线程还有机会能够读到这外面的内容，所以整体的并发会更高。
4. 性能优化 - 调整并行度
第三个优化来自于用户对线程池的配置。
在 Alluxio 2.3 外面退出了线程池之后，能够通过配置参数调整元数据同步的并行度。之前单线程没有配置可言。调整并行度个别是通过这三个参数。
（1）第一个参数管制了单个 RPC 申请外面的这个元数据同步，它的 BFS 并行度调的越高，并行度越高，更快的机会也就越大，同时对这个零碎的占用也会越多；
（2）第二个是同步线程池大小；
（3）第三个是预取线程池大小。
两个线城池的大小，倡议配置成 CPU 数的倍数，具体比例以及零碎应该配多大，取决于这两个线程所做工作的工夫，以及两头的配合形式。所以没有给出对立倡议，倡议依据具体程序运行的时候，CPU 比方能够做一些火焰图、剖析提早以及 inodetree 更新的提早，做一个更加正当的配比。默认的配比都是 CPU 的倍数，如果没有在无数据同步看到非常明显的瓶颈，不须要进行特地细粒度的调节。
06. 对不同场景的举荐配置
最初针对不同的场景具体分析问题，举荐比拟好的配置。
1. 场景 1
最简略的场景就是：所有的写和读全都通过了 Alluxio。无疑 Alluxio 所有的元数据都是最新，此时无需做元数据同步。能够敞开元数据同步，晋升性能。
2. 场景 2
第二个场景略微简单一些。大部分的操作通过 Alluxio，然而不排除还有一些场景，会绕过 Alluxio 间接改变原来外面的文件。
在这种场景下，为了保障 Alluxio 和 UFS 元数据和数据的统一，还是要保留一部分元数据同步的操作。在这里分 HDFS 和非 HDFS 进行思考，次要是因为这些 HDFS 比他人多一个选项 Active Sync。
HDFS 的状况下，须要思考这几个点：如果 HDFS 更新十分频繁，就是绕过 Alluxio 的更新十分频繁，或者 HDFS 的 namenode 的压力比拟大，不倡议应用 Active Sync，而是应用基于工夫的被动同步。应用被动同步的起因是 Active Sync 是基于 Alluxio 心跳，去 namenode 拉取具体有哪些文件产生了改变，每一次拉取都是一次 RPC，给 namenode 施加的压力。同时如果文件产生了改变，Alluxio 就又会向 namenode 发动 RPC 去同步这些文件。因而心愿尽量减少这些操作来升高 namenode 的压力。
如果基于工夫的被动同步，能给予缩小元数据同步操作的机会，则应用基于工夫的被动同步；反之要应用 Active Sync，因为更加被动，时效性更高。如果不会带来性能累赘，齐全能够去尝试一下。
如果不是 HDFS，只能用基于工夫的被动同步。
倡议尽量节约元数据同步的操作，具体做法思考每个数据、每个门路更新的频率大略是如何。基于这样的考量，尽量给 sync interval 设一个比拟大的值，尽量减少元数据的触发。
3. 场景 3
第三个场景略微有些不同。大部分或全副更新都不通过 Alluxio，而更新又十分频繁。
在这种状况下，应用 HDFS 而且时效性又十分重要，应用 Active Sync 是惟一计划。因为如果把 sync interval 调到一个特地低的值，甚至可能触发比 Active Sync 更多的同步。如果把它设成零之后，每一次都不会触发同步，会进一步加大同步的操作开销。
如果时效性并不非常重要，倡议应用这个基于工夫的被动同步。通过节俭开销，缩小元数据同步的操作，就能晋升零碎的性能。同样如果不是 HDFS，则应用基于工夫的被动同步。
以上是三个场景的剖析，也是明天分享的全部内容。
07. 答疑
Q：在 ASYNC_THROUGH mode 当中，因 UFS 起因导致 ASYNC 上传始终失败，这种状况怎么优雅地解决，以防止不统一？
A：这个问题十分好，问到了痛点。目前没有一个特地优雅的解决方案。
在异步形式下没有 call back，或者 hook 的主动染指，只能人为染指。Alluxio2.4 商业版中退出了一个 job service dashboard 查看异步工作的状态。如果异步长久化失败了，这个中央能够看到所有失败的异步工作。目前只能通过这个形式察看到底有哪些货色失败了，而后再人为进行干涉。
咱们曾经留神到 job service 的问题，打算从新设计整个 job service，从几个方向，可扩大 Scalability, Fault-tolerance，包含 monitoring, failure mode, 复原等。将来版本外面会做出更好的设计，有很多场景，并退出人工干预模式。通过凋谢一些接口，能够自动化地读到这些货色，或是可能会减少界面，让用户定义一些形式。
Alluxio 到了一个新的阶段，要好好思考，用更加 scalable 的计划去解决这些问题。这些异步的操作曾经提上了议事日程。
Q：和 HDFS 能够不同门路设置不同的同步工夫吗？
A：能够用配置参数的办法去实现。
分享嘉宾
想要获取更多乏味有料的【流动信息】【技术文章】【大咖观点】，请关注[Alluxio 智库]：
