> For the complete documentation index, see [llms.txt](https://documentation.alluxio.io/ee-ai-cn/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.alluxio.io/ee-ai-cn/how-alluxio-works.md).

# Alluxio 工作原理

本节解释了 Alluxio 架构和功能背后的基本概念。理解这些思想将帮助您最大限度地利用该系统。

## 1. 去中心化架构

Alluxio 基于**去中心化、无 Master 节点架构**构建，**元数据**（文件位置、目录结构和命名空间映射）的所有权通过**一致性哈希**分布到所有 Worker。客户端仅需一次网络跳跃即可直接与负责的 Worker 通信，无需任何中央权威节点。

这种去中心化设计提供了以下几个关键优势：

* **无单点故障：** 即使某些 Worker 节点发生故障，系统仍然可用。
* **线性可扩展性：** 随着添加更多 Worker，元数据和数据容量可水平扩展。
* **低延迟：** 客户端仅需一次网络跳跃即可解析元数据和数据位置。

### 一致性哈希环

Alluxio 使用一致性哈希算法将文件路径映射到 Worker。想象一个虚拟的"哈希环"，集群中所有 Worker 分布在这个环上——每个 Worker 负责环的一段，管理哈希落在其区间内的文件的元数据和缓存数据。

每个 Worker 在环上拥有多个**虚拟节点（vnode）**，这些虚拟节点由其 UUID（Worker 首次启动时分配的唯一标识符）确定性计算得出。这确保了数据在 Worker 之间的均匀分布，以及可预测的数据放置：相同的 UUID 始终映射到相同的环槽位。

为确保所有客户端对哈希环的视图保持一致，Alluxio 使用 **etcd**（一个分布式键值存储）来管理集群成员资格并跟踪哪些 Worker 在线。etcd 是任何 Alluxio 部署的必需基础设施组件。在 Kubernetes 上部署时，Alluxio Operator 会作为集群部署的一部分自动配置和管理 etcd；详见 [Kubernetes 安装](/ee-ai-cn/start/installing-on-kubernetes.md)。

{% hint style="info" %}
开源版本的 Alluxio 使用中央 **Master** 节点作为唯一的元数据服务——这种设计引入了单点故障、高并发下的元数据瓶颈，以及每次 I/O 操作的额外延迟。Alluxio 企业版架构彻底将 Master 节点移出 I/O 路径。完整设计分析请参阅[架构白皮书](https://www.alluxio.io/whitepaper/alluxio-architecture-a-decentralized-data-acceleration-layer-for-the-ai-era)。
{% endhint %}

### 关键组件

1. **Alluxio Worker：** 与计算节点同置部署（例如，在同一 Kubernetes 节点上）。使用本地存储（内存、SSD 或 HDD）存储缓存数据，并管理其命名空间部分的元数据。
2. **Alluxio 客户端：** 嵌入计算框架的库。包含一致性哈希逻辑，可定位任意文件路径对应的 Worker，实现客户端与 Worker 的直接通信，无需任何中央协调者。**Alluxio FUSE** 是该客户端的一种特殊形式：一个长期运行的进程，将 Linux VFS 操作（open、read、write 等）映射为 Alluxio 操作，对外暴露一个本地挂载目录，使任何应用程序无需修改代码即可通过标准文件系统调用访问 Alluxio。
3. **Alluxio Coordinator：** 与原来的 Master 节点不同，Coordinator 从不位于 I/O 关键路径上。它负责处理后台集群操作，包括 Worker 注册与健康监控、缓存预加载和逐出任务调度、集群配置管理。所有数据和元数据操作完全绕过 Coordinator，由客户端通过一致性哈希直接与 Worker 通信。

> 有关更深入的了解，请阅读 [Alluxio 架构白皮书](https://www.alluxio.io/whitepaper/alluxio-architecture-a-decentralized-data-acceleration-layer-for-the-ai-era)。

## 2. 统一命名空间

Alluxio 提供了一个**统一命名空间**，将所有连接的存储系统呈现为单个逻辑文件系统。这是通过将不同的底层文件系统（UFS）"挂载"到 Alluxio 内的路径来实现的。

例如，您可以将一个 S3 存储桶和一个 GCS 存储桶挂载到 Alluxio：

挂载表如下所示：

| Alluxio 路径 | 底层文件系统（UFS）路径            |
| ---------- | ------------------------ |
| `/s3/`     | `s3://bucketA/data/`     |
| `/gcs/`    | `gcs://bucketB/records/` |

现在，您的应用程序可以通过单一一致的 API 访问 S3 和 GCS 的数据，无需为每个底层存储系统显式提供凭据或其他系统特定信息。Alluxio 路径与 UFS 路径之间的映射存储在**挂载表**中，并保存在 **etcd** 中以确保其在所有 Alluxio 组件间高可用且一致。

> 有关更深入的了解，请参阅[连接到存储](/ee-ai-cn/ufs.md)。

## 3. 客户端接入方式

Alluxio 提供三种标准访问协议，让应用程序无需修改代码即可接入：

| API               | 协议           | 适用场景                                           |
| ----------------- | ------------ | ---------------------------------------------- |
| **POSIX（FUSE）**   | Linux 文件系统挂载 | AI/ML 训练框架、任何通过路径读取文件的应用                       |
| **S3 API**        | HTTP / S3 兼容 | 已使用 S3 SDK 的应用，无需修改代码                          |
| **Python FSSpec** | Python       | PyTorch DataLoader、HuggingFace Datasets、pandas |

三种协议均由同一组 Alluxio Worker 提供服务，共享同一底层缓存。API 的选择取决于集成偏好，而非性能差异。

> 有关配置和使用方法，请参阅[客户端 API](/ee-ai-cn/data-access.md)。

## 4. 容错与弹性扩缩容

### UFS 回退

当 Worker 不可用时，Alluxio FUSE 客户端会自动回退到直接从底层文件系统读取数据。应用程序无需中断——回退对调用方透明。

### 弹性扩缩容

由于 Alluxio 使用一致性哈希，Worker 可以随时增减，而不会中断服务：

* **扩容（主动）：** 新 Worker 加入哈希环并接管部分范围。其范围内的操作立即成功，数据在首次访问时从 UFS 加载。
* **缩容（计划性或故障）：** 当 Worker 被移除或发生故障时，其范围内的读取回退到 UFS，直到集群重新均衡。哈希环可以以**动态模式**（默认，环仅包含在线 Worker）或**静态模式**（保留离线 Worker 以在短期计划性维护期间保持缓存亲和性）运行。

> 有关哈希环调优和 Worker 生命周期操作，请参阅[哈希环与 Worker 生命周期](/ee-ai-cn/administration/managing-ring.md)。

## 5. Worker 存储：Page Store

每个 Worker 将缓存数据存储在本地 **page store** 中。文件被切分为固定大小的 **page**（默认 4 MiB），缓存以 page 为粒度——因此 Worker 通常只保存应用实际读过的那部分文件。一个文件是否被完整缓存取决于访问模式。

Page store 一般由本地 SSD 承载以获得高吞吐。一个 Worker 可以配置多个本地目录，让 page store 跨多块盘——每个目录对应一块盘，Worker 会将 page 分散到这些目录。也有部署选择用 RAID 0 将多块盘组成单一逻辑卷。缓存容量按 Worker 配置，与 UFS 大小无关。

Page store 是单一扁平层级——目前没有内置的冷热分层（如内存与磁盘、SSD 与 HDD 之间）。所有缓存的 page 都位于配置的 page store 目录中。

> 关于 page store 的配置（hostPath vs PVC、容量规划、多盘、异构 Worker），请参阅 [Worker 配置 — Worker 存储](https://documentation.alluxio.io/ee-ai-cn/pages/c4TWyXEiWHUuqlML94ZH#id-1.-worker-cun-chu)。

## 6. 数据缓存生命周期

Alluxio 将数据缓存在与计算节点同置部署的 Worker 上。这种同置部署是其性能优势的来源：

* **缓存命中：** 数据从 Worker 的本地存储（内存或 NVMe SSD）提供服务——通常比从远程对象存储读取快 10–100 倍。
* **缓存未命中：** Worker 从 UFS 获取数据，在本地缓存后提供给客户端。后续对相同数据的读取将从缓存提供服务。

缓存数据的生命周期分为三个主要阶段：

### 加载数据

数据以两种方式进入缓存：**按需**（被动）加载——应用程序首次读取时触发，这是默认行为；或通过预加载作业**主动**加载，提前"预热"缓存以备将来工作负载，确保初始请求以内存速度提供服务。

### 管理数据

数据进入缓存后，其生命周期由一组灵活的策略控制。管理员可以定义规则来控制**缓存哪些数据**，设置**存储配额**以确保不同数据集或租户之间的公平资源分配，并应用\*\*生存时间（TTL）\*\*设置以自动清除过时数据。

### 移除数据

当缓存已满时，**自动逐出**会根据配置的策略（如最近最少使用 / LRU）移除现有项目，为新数据腾出空间。**手动逐出**允许管理员明确地从缓存中释放特定文件或目录。

> 有关更深入的了解，请参阅[管理缓存](/ee-ai-cn/cache.md)。

## 7. 多租户和集群联邦

对于大型企业环境，Alluxio 支持多租户和多个集群的联邦。

* **多租户：** Alluxio 可以强制执行租户隔离，允许不同团队或业务部门安全地共享单个 Alluxio 部署。这包括每个租户的缓存配额、访问策略和配置。身份验证和授权通过与 Okta 等企业身份提供商和 OPA 等策略引擎的集成来处理。
* **集群联邦：** 当您拥有多个 Alluxio 集群（例如每个区域或业务部门一个）时，中央**管理控制台**和 **API 网关**可提供统一的监控、许可和运维视图。

> 有关更深入的了解，请参阅[多租户和联邦](https://documentation.alluxio.io/ee-ai-cn/pages/cuG1KYD7QZM6zV5EoHQ1#id-3.-duo-zu-hu-he-lian-bang)。