核心概念
本节解释了 Alluxio 架构和功能背后的基本概念。理解这些思想将帮助您最大限度地利用该系统。
1. 去中心化架构
Alluxio 基于去中心化、无主节点架构构建，旨在实现高可用性和大规模可扩展性。与依赖中央主节点的传统系统不同，Alluxio 将职责分布在整个集群中。该架构的核心是一致性哈希，它使客户端能够高效地定位数据和元数据，而无需查询中央服务。
这种去中心化设计提供了几个关键优势：
无单点故障： 即使某些工作节点发生故障，系统仍然可用。
线性可扩展性： 随着您添加更多工作节点，元数据和数据容量会水平扩展。
低延迟： 客户端可以在单个网络跳跃中解析元数据和数据位置。
一致性哈希环
Alluxio 使用一致性哈希算法将文件路径映射到一组分布式工作节点。想象一个虚拟的“哈希环”，集群中的所有工作节点都放置在这个环上。每个工作节点负责这个环的一部分。这种方法确保了均匀的数据分布、可扩展性和容错性。
关键组件
该架构由两个协同工作的主要组件组成：
Alluxio Worker: Worker 通常与您的计算应用程序位于同一位置（例如，在同一 Kubernetes 节点上）。它们使用本地存储（内存、SSD 或 HDD）来存储缓存数据。至关重要的是，每个 Worker 还负责管理其命名空间部分的元数据，这由一致性哈希环确定。
Alluxio 客户端: Alluxio 客户端是嵌入在您的计算框架中的一个库。它包含一致性哈希逻辑，用于定位任何给定文件路径的正确 Worker。
工作原理
当应用程序需要访问文件时：
哈希： Alluxio 客户端对文件路径应用哈希函数。
映射： 哈希的输出决定了环上哪个 Worker 负责该文件的元数据及其缓存数据。
直接通信： 客户端与负责的 Worker _直接_通信以获取所需信息，从而避免了中央主节点的瓶颈。
为了保持哈希环视图的一致性，Alluxio 使用像 etcd 这样的分布式键值存储来管理集群成员资格并跟踪哪些 Worker 在线。
2. 统一命名空间
Alluxio 提供了一个统一命名空间，将所有连接的存储系统呈现为单个逻辑文件系统。这是通过将不同的底层文件系统 (UFS)“挂载”到 Alluxio 内的路径来实现的。
例如，您可以将一个 S3 存储桶和一个 GCS 存储桶挂载到 Alluxio 中：
挂载表如下所示：
/s3/
s3://bucketA/data/
/gcs/
gcs://bucketB/records/
现在，您的应用程序可以通过单个一致的 API 访问来自 S3 和 GCS 的数据，而无需为每个底层存储系统明确提供凭据或其他系统特定信息。Alluxio 路径和 UFS 路径之间的映射存储在挂载表中。为确保此表在所有 Alluxio 组件中高度可用且一致，它存储在分布式键值存储 etcd 中。
有关更深入的了解，请参阅连接到存储。
3. I/O 弹性和高可用性
Alluxio 设计为高度容错。它具有多种机制，可确保即使在组件不可用时，I/O 操作也能正常继续。
UFS 回退： 如果客户端尝试从 worker 读取数据而该 worker 不可用，客户端可以自动回退到直接从底层文件系统读取数据。这确保了即使 Alluxio 集群无响应，应用程序的读取请求也能不间断地成功。
跨副本重试： 启用数据复制后，如果客户端无法从一个 worker 获得响应，它将自动在可能托管数据副本的其他 worker 上重试该请求。
多可用区高可用性： 为实现最大程度的容错，您可以在多个可用区 (AZ) 部署 Alluxio 集群。如果本地 Alluxio 集群不可用，客户端将故障转移并从其他可用区中的集群请求数据。
这些功能共同创建了一个强大的数据访问层，能够抵御常见故障。
故障转移优先级：操作顺序
当 Alluxio 客户端无法从其首选 worker 读取数据时，它将按以下顺序尝试不同的源进行自动恢复：
使用本地副本重试： 如果启用了数据复制，客户端将首先尝试从同一集群中拥有所请求数据副本的其他 worker 读取。
故障转移到远程集群（多可用区）： 如果所有本地副本都不可用并且启用了多可用区支持，客户端将接着尝试从其他联合集群中的 worker 读取，这些集群通常位于不同的可用区。
回退到 UFS： 如果所有 Alluxio worker（本地和远程）都不可用，客户端将作为最后手段回退到直接从底层文件系统（UFS）读取数据。
这种分层方法在优先选择最快可用数据源的同时，最大限度地提高了成功读取的机会。
Worker 生命周期事件如何影响 I/O
去中心化架构旨在处理集群成员资格的动态变化。
添加 Worker 时： 新的 worker 加入一致性哈希环并接管一部分哈希范围。其范围内的数据读取操作最初可能会因为从 UFS 加载数据而变慢，但操作会成功。
移除或发生故障的 Worker 时： 对已移除 worker 的正在进行的请求将失败。然后，客户端将触发上述故障转移过程。对于 FUSE 客户端，此过程是无缝的。对于 S3 或 FSSpec 客户端，应用程序可能会看到一个瞬时错误，但在客户端的 worker 列表视图更新后，应在重试时恢复。
重启 Worker 时： 这被视为先移除 worker，然后再添加。只要 worker 的身份被持久化，它就会重新加入环并收回其原始哈希范围，使其缓存的数据再次可用。
有关更深入的了解，请参阅高可用性数据访问。
4. 数据缓存生命周期
有效管理 Alluxio 中缓存的数据是实现最大性能和资源效率的关键。缓存数据的生命周期可以理解为三个主要阶段：加载、管理和移除。
加载数据
数据以两种主要方式进入 Alluxio 缓存。它可以按需（被动）加载，即应用程序首次读取数据时，这是默认行为。或者，数据可以通过预加载作业主动加载，这些作业会“预热”缓存以备将来工作负载之需，确保初始请求以内存速度提供服务。
管理数据
数据一旦进入缓存，其生命周期就由一组灵活的策略控制。管理员可以定义规则来控制缓存哪些数据，设置存储配额以确保不同数据集或租户之间的公平资源分配，并应用生存时间 (TTL) 设置以自动清除过时信息。这些控制允许对缓存内容和资源占用进行精细管理。
移除数据
数据可以自动或手动从缓存中移除。当缓存已满时，自动逐出会根据配置的策略（例如最近最少使用 (LRU)）移除现有项目，为新数据腾出空间。为了更直接地控制，手动逐出允许管理员明确地从缓存中释放特定文件或目录。
有关更深入的了解，请参阅管理缓存。
5. 多租户和集群联合
对于大型企业环境，Alluxio 支持多租户和多个集群的联合。
多租户： Alluxio 可以强制执行租户隔离，允许不同团队或业务部门安全地共享单个 Alluxio 部署。这包括每个租户的缓存配额、访问策略和配置。身份验证和授权通过与企业身份提供商（如 Okta）和策略引擎（如 OPA）的集成来处理。
集群联合： 当您有多个 Alluxio 集群（例如，每个区域或业务部门一个）时，中央管理控制台和API 网关可以为监控、许可和操作提供统一视图。这简化了大规模分布式数据环境的管理。
有关更深入的了解，请参阅多租户和联合。
Last updated