# 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)。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://documentation.alluxio.io/ee-ai-cn/how-alluxio-works.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.