(1)如果向集群添加新节点，为了平衡节点之间的内存空间利用率，Alluxio是否会进行重新平衡（即将缓存的块移动到新节点）？
否，当前还未实现对数据块的重新平衡。
(2)alluxio 如何读取数据
Alluxio还支持层次化存储
可以允许有三层的存储结构：
memoy
SSD
HDD
（3）alluxio写的策略：**
CACHE_THROUGH
数据被同步地写入到 Alluxio 的 Worker 和底层存储系统。
MUST_CACHE
数据被同步地写入到 Alluxio 的 Worker。但不会被写入到底层存储系统。这是默认写类型
THROUGH
数据被同步地写入到底层存储系统。但不会被写入到 Alluxio 的 Worker。
ASYNC_THROUGH
数据被同步地写入到 Alluxio 的 Worker，并异步地写入到底层存储系统。处于实验阶段。
对于需要持久化的对象， Alluxio会保存底层文件系统存储这些对象的文件夹的路径。例
如，一个用户在根目录下创建了一个Users目录，其中 包含Alice和Bob两个子目录，底层
文件系统（如HDFS或S3）也会保存相同的目录结构和命名。类似地，当用户在 Alluxio
文件系统中对一个持久化的对象进行重命名或者删除操作时，底层文件系统中对应的对象
也会被执行相同的操作。
（4）alluxio读的策略：
CACHE_PROMOTE
如果读取的数据在 Worker 上时，该数据被移动到 Worker 的最高层。如果该数据不
在本地 Worker 的 Alluxio 存储中，那么就将一个副本添加到本地 Alluxio Worker
中。 如果 alluxio.user.file. cache .partially.read.block设置为 true,没有完全读取的数
据块也会被全部存到 Alluxio 内。 相反，一个数据块只有完全被读取时，才能被缓存
CACHE
如果该数据不在本地 Worker 的 Alluxio 存储中，那么就将一个副本添加到本地
Alluxio Worker 中。如果 alluxio.user.file.cache.partially.read.block
设置为 true,没有完全读取的数据块也会被 全部
存到 Alluxio 内。 相反，一个数据块只有完全被读取时，才能被缓存。
NO_CACHE
仅读取数据，不在 Alluxio 中存储副本。
（5）alluxio的分配策略：
1、贪心分配策略
分配新数据块到首个有足够空间的存储目录。
2、最大剩余空间分配策略
分配数据块到有最大剩余空间的存储目录。
3、轮询调度分配策略
分配数据块到有空间的最高存储层，存储目录通过轮询调度选出。
(6)alluxio的回收策略：
1、贪心回收策略
移出任意的块直到释放出所需大小的空间。
2、LRU回收策略
移出最近最少使用的数据块直到释放出所需大小的空间。
3、LRFU回收策略
基于权重分配的最近最少使用和最不经常使用策略移出数据块。如果权重完全偏向最 近最少使用,LRFU回收策略退化为LRU回收策略。
4、部分LRU回收策略
基于最近最少使用移出，但是选择有最大剩余空间的存储目录(StorageDir)，只从该目录移出数据块。
(7)生存时间
当Alluxio运行时，活跃的master节点负责保存元数据在内存中。在内部，master进程运行一个后台线程定期检查文件是否已经到达它对应的TTL值。
后台线程在一个可配置的时间段内运行，默认为1小时。这意味着TTL在下一次检查间隔前不会强制执行，TTL的强制执行可以达到1 TTL间隔延迟。
间隔长度由 alluxio.master.ttl.checker.interval 属性设置。
SetTTL(path, duration, action)
path Alluxio命名空间中的路径
duration TTL操作生效之前的毫秒数，将覆盖任何之前的值
action 生存时间过后要采取的行动。FREE将导致文件被逐出Alluxio存储，不管pin状态如何。
DELETE将导致文件从Alluxio命名空间中删除，并在存储中删除。
注意:DELETE是某些命令的默认值，将导致文件被永久删除。
(8)alluxio中的Lineage的作用
Alluxio则使用lineage来表示文件之间的依赖。在代码层面，指的是fileID之间的依赖。
如何还引发lineage进行容错的？
checkpoint 重新进行计算
(9)如何同步Alluxio Meta UFS的Meta文件(alluxio1.8的优化点 元数据的管理)
加速Alluxio/底层存储同步
自从Alluxio v1.7问世以来，指纹串技术已经被用来检测文件或目录是否已经改变。这可以让Alluxio快速确定Alluxio中的文件与S3存储中的文件或其他对象存储(底层存储)中的文件是否同步。当用户不通过Alluxio而直接在底层存储中修改一个文件可能会发生这种不同步的情况。当指纹不同步时，将执行底层存储同步操作。1.8版本通过将指纹划分为两个组件(元数据组件和内容组件)改进了这一特性，从而进一步减少了Alluxio和底层存储之间所需的同步次数。
在此使用双组件指纹技术之前，如果底层文件系统(UFS)中文件/对象(所有者、模式等)的元数据发生更改，那么Alluxio则认为整个文件都不再同步，并认为对应的整个文件将无效。这可能会导致不必要的文件失效和数据的重新加载，从而增加大规模元数据操作的成本，比如在包含许多文件和目录的目录上递归地更改权限。元数据操作本身并不一定很慢，但是后续的文件内容操作会慢一些，因为在下一次读取操作中，Alluxio必须重新加载文件内容。
通过将文件元数据指纹和文件内容指纹分离开来，当文件只有元数据发生更改时，只有文件元数据的指纹是不同的，而文件内容的指纹并没有发生变化。因此，Alluxio不需要从底层存储重新加载数据，而是可以直接在内存中更新元数据。因此，在只有元数据发生更改的情况下，这是一种低成本的同步底层存储系统和Alluxio元数据的方法。
Alluxio需要的元数据支持规模 提供可以轻松超过最大的Hadoop部署。 特别是元数据管理被认为是Hadoop的弱点，但Alluxio应该将元数据管理变成一种优势。
（10） alluxio2.0 的新特性：
《1》使用的规则：堆外元数据存储：用户可以通过配置alluxio.master.metastore = ROCKS以使用嵌入式RocksDB进行堆外元数据存储，从而避免JVM的堆内内存资源限制和GC带来的性能下降，并使Alluxio文件系统可以扩展到管理超过10亿个文件。
《2》以前的是将文件系统日志写入到HDFS或者s3等外部存储实现高可用，引入外部依赖的过程中会导致服务强依赖于外部的稳定性。
alluxio 2.0 加入了journal ，Alluxio在2.0新添加的嵌入式Journal从原理上来说就是实现了一个完整的分布式状态机，无外部依赖的嵌入式文件系统Journal
《3》使用Alluxio 2.0，用户可以使用Alluxio的任何版本连接到多个HDFS集群，并统一数据访问。在此处查找支持的HDFS版本列表。
