数据多副本

概述

Alluxio工作节点上文件数据和元数据的副本称为副本。文件多副本允许通过在不同工作节点上创建多个副本，让多个工作节点为客户端提供相同的文件。因此，当数据集被大量客户端并发缓存和访问时，文件多副本可用于提高I/O性能。

如果未启用文件多副本，文件在集群中一次只有一个副本。这意味着所有客户端对文件元数据和数据的访问都将由存储该副本的单个工作节点提供服务。在大量客户端需要并发访问此文件的情况下，该工作节点的服务能力可能会成为瓶颈。

请注意，对于给定文件，一个工作节点最多只能有该文件的1个副本。一个工作节点不会有同一个文件的多个副本。

配置多副本规则

在创建副本之前，您需要首先配置文件多副本的级别，即一个文件在集群中存在的副本数量。多副本级别可以通过协调器上的RESTful API端点进行管理：

http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule

列出当前多副本规则

要列出所有当前生效的多副本规则，请向该端点发送GET请求：

$ curl -G http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule

响应是一个包含所有多副本规则的JSON对象：

{
  "/": {
    "pathPrefix": "/",
    "clusterReplicaMap": {
      "DefaultAlluxioCluster": 1
    },
    "totalReplicas": 1,
    "type":"UNIFORM"
  }
}

此示例显示了在根路径上设置的多副本规则，所有文件都有1个副本。

创建新的多副本规则

要添加新的多副本规则，请使用以下命令发送POST请求：

$ curl -X POST -H 'Content-Type: application/json' -d '{"path": "/", "numReplicasPerCluster": 2}' http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule

请求的POST数据是一个JSON对象：

{
  "path": "/",
  "numReplicasPerCluster": 2
}

path字段指定多副本规则生效的路径前缀。numReplicasPerCluster字段指定此路径前缀下文件的多副本级别。

可以为不同的路径前缀指定多个多副本规则。例如，以下示例将/s3/vip_data下的文件设置为3个副本，将/s3/temp_data下的文件设置为1个副本：

$ curl -X POST -H 'Content-Type: application/json' -d '{"path": "/s3/vip_data", "numReplicasPerCluster": 3}' http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule
$ curl -X POST -H 'Content-Type: application/json' -d '{"path": "/s3/temp_data", "numReplicasPerCluster": 1}' http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule

请注意，目前如果创建了多个多副本规则，规则的路径不能嵌套。例如，不能同时存在设置在/parent上的规则和设置在/parent/child上的规则。因此，设置在根路径/上的规则不能与设置在任何其他路径上的规则共存。此限制将在未来版本中取消。

更新现有多副本规则

更新现有规则的方法与创建新规则相同，但在现有规则的路径上进行：

$ curl -X POST -H 'Content-Type: application/json' -d '{"path": "/s3/vip_data", "numReplicasPerCluster": 1}' http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule

以上示例将/s3/vip_data上的副本数从3更新为1。

删除多副本规则

要删除多副本规则，请向该端点发送DELETE请求，请求正文为要删除的规则的路径前缀：

$ curl -X DELETE -H 'Content-Type: application/json' -d '{"path": "/s3/vip_data"}' http://<coordinator_host>:<coordinator_api_port>/api/v1/replica-rule

默认多副本级别

如果未创建任何多副本规则，默认行为就像在根路径上设置了1个副本的规则一样：

{
  "path": "/",
  "numReplicasPerCluster": 1
}

因此，所有文件在Alluxio集群中将只有1个副本。

已弃用的配置属性alluxio.user.file.replication.min可用于更改默认多副本级别的数量，例如更改为2：

alluxio.user.file.replication.min=2

我们建议在根路径上设置显式规则，而不是依赖此已弃用的属性。

创建副本

副本可以通过缓存未命中被动创建，也可以通过分布式加载手动创建。

手动创建副本

Alluxio提供将文件分布式加载到Alluxio缓存中的功能。

bin/alluxio job load --path s3://bucket/file --submit

如果在/s3上存在规则，并且副本数设置为3，则加载完成后，位于/s3/file的文件将以3个副本加载到Alluxio中，这些副本将驻留在3个不同的工作节点上。在具有多个副本的加载作业结束时，即使某些副本未成功加载，加载作业状态也将报告为成功。对于任何失败的副本，它们将在请求时加载；请参阅被动创建副本。

被动创建副本

当客户端从Alluxio读取文件时，如果文件未被任何工作节点缓存，则会将其加载到Alluxio中。如果启用了文件多副本，客户端将尝试从不同的工作节点加载文件，从而被动地创建多个副本。请注意，由于被动创建而创建的副本数量将取决于加载文件的客户端数量。由于一个客户端一次只会从一个工作节点读取文件，因此如果文件仅由一个客户端请求，则只会在一个工作节点上创建一个副本。如果客户端数量足够多，则被动创建的副本数量可能会达到多副本规则中设置的指定多副本级别。这与通过分布式加载手动创建的副本不同，后者会主动加载多副本规则中指定的尽可能多的副本。

并发读取多个副本

如果根据有效的多副本规则，文件有多个副本，客户端将能够读取多个副本。对于多副本文件，客户端选择哪个副本由副本选择策略控制。

副本选择策略决定了在给定所有候选工作节点的列表的情况下，客户端应访问哪个工作节点来读取文件。 Alluxio提供两种副本选择策略：

全局固定：所有客户端按照候选工作节点列表中列出的相同顺序选择工作节点。
客户端固定：每个客户端看到相同的候选工作节点集，但工作节点的顺序可能不同。因此，不同的客户端将选择不同的工作节点来读取文件。
随机：每次读取文件时，每个客户端都会从候选工作节点中随机选择一个副本。

要设置副本选择策略，请将配置alluxio.user.replica.selection.policy设置为GLOBAL_FIXED、CLIENT_FIXED或RANDOM。

如果副本选择策略选择的工作节点由于临时故障而不可用，客户端将使用候选列表中的下一个工作节点，直到用尽所有选项并以错误失败。

请注意，默认情况下，客户端在尝试从工作节点读取之前不会检查该工作节点是否实际缓存了文件。如果选定的工作节点未缓存文件，该工作节点将从UFS获取并缓存文件，然后将其发送给客户端。除非当前选定的工作节点不可用，否则客户端不会切换到另一个副本工作节点。要通过使用已缓存的副本来提高I/O性能，请参阅下一节。

多副本文件的优化I/O

如果文件在多个工作节点上多副本，Alluxio支持优化I/O以加快访问速度，方法是优先考虑已经完全缓存数据的工作节点。当Alluxio客户端读取多副本文件时，它将首先检查文件是否被副本选择策略选择的任何副本工作节点缓存。如果是，客户端将尝试从第一个完全缓存文件的工作节点读取。如果没有工作节点完全缓存文件，客户端将使用上一节中描述的相同方式使用工作节点进行冷读取。

请注意，与根本没有缓存文件的工作节点相比，部分缓存文件的工作节点不会被优先考虑。

要为多可用区多副本文件启用优化I/O，请设置以下配置：

alluxio.user.replica.prefer.cached.replicas=true

用于自动创建副本的被动缓存

启用优化I/O后，在初始检查过程中，如果客户端发现它尝试读取的文件在首选工作节点上未缓存或部分缓存，则客户端将切换到文件的次选数据源，而不是进行冷读取。首选工作节点没有完全缓存文件而次选工作节点却缓存了文件的原因有很多：

首选工作节点上的文件缓存已被逐出，以便为最近访问的文件腾出空间
集群已扩展，首选工作节点是新添加到集群中的

由于客户端不会在首选工作节点上触发冷读取，因此除非用户运行显式加载作业将文件加载到工作节点中，否则工作节点不会缓存文件。这将增加一个恒定的额外I/O延迟，该延迟是探测和确定首选工作节点是否已缓存文件所需的，每次读取请求都会产生。为了消除增加的延迟，用户可以启用被动缓存功能，该功能在缓存未命中时自动并异步加载文件。当客户端稍后访问同一文件时，首选工作节点将完全缓存该文件，因此客户端不必切换到次选工作节点，从而优化了I/O延迟。

要启用被动缓存，请添加以下配置：

# multi-replica optimized IO must be enabled for passive cache to work
alluxio.user.replica.prefer.cached.replicas=true
alluxio.user.file.passive.cache.enabled=true

通过指标监控副本

当alluxio.user.replica.prefer.cached.replicas启用时，指标alluxio_multi_replica_read_from_workers_bytes_total监控跨集群的数据读取模式。此指标提供了对读取流量分布和高可用性配置下多副本缓存有效性的洞察。

类型：counter
组件：client
描述：跟踪客户端在读取多副本文件时从Alluxio工作节点读取的总字节数。此指标仅在alluxio.user.replica.prefer.cached.replicas设置为true时生效。它有助于分析客户端从本地集群与远程集群读取的频率，以及读取是否来自完全缓存的副本。
标签：
- cluster_name：提供读取服务的工作节点所在的集群名称。
- local_cluster：如果工作节点与客户端属于同一集群，则为true，否则为false。
- hot_read：如果工作节点已完全缓存正在读取的文件，则为true；如果工作节点未缓存或仅部分缓存了副本，则为false。

启用被动缓存后，存在指标alluxio_passive_cache_async_loaded_files来监控由被动缓存功能加载的文件数。

类型：counter
组件：worker
描述：跟踪由被动缓存触发的工作节点加载的文件总数。此指标仅在alluxio.user.file.passive.cache.enabled设置为true时生效。它有助于分析在首选工作节点上遇到缓存未命中的文件数量，因此需要由被动缓存加载。
标签：
- result：加载文件的的结果，为“submitted”、“success”和“failure”之一。当文件提交以进行异步加载时，“submitted”标记的指标会增加。当加载成功或不成功完成时，“success”或“failure”标记的指标会分别增加。

限制

可变数据的一致性问题

多个副本最适合不可变数据，因为副本之间不会存在不一致。如果UFS中的数据是可变的并且会随时间变化，则在不同时间从UFS加载的副本可能是文件的不同版本。因此，如果两个客户端选择同一文件的两个不同副本，可能会出现不一致。

为避免文件可变时出现潜在的不一致，您可以

手动刷新副本的文件元数据并使现有缓存的副本无效。

这可以通过带有--metadataOnly选项的加载作业来完成：

bin/alluxio job load --path s3://bucket/file --metadataOnly --submit

此命令将启动一个分布式作业来加载文件s3://bucket/file的元数据。如果文件存在任何现有副本，并且Alluxio检测到文件在UFS中已更改，则现有副本将被无效。随后访问文件时，Alluxio将从UFS加载最新数据。

为文件设置具有适当缓存控制策略的缓存过滤器。

例如，如果文件预计平均每10分钟更新一次，则可以使用10分钟的maxAge策略：

{
  "apiVersion": 1,
  "data": {
    "defaultType": "maxAge",
    "defaultMaxAge": "10min"
  },
  "metadata": {
    "defaultType": "maxAge",
    "defaultMaxAge": "10min"
  }
}

当副本的最长存在时间为10分钟时，它将在10分钟后失效并从UFS重新加载。每次对UFS中的文件进行更新时，至少等待10分钟，以便任何现有副本都将失效。

多副本级别未主动维护

多副本规则指定的目标多副本级别仅作为多副本选择算法的输入参数。在任何给定时刻，集群中存在的实际副本数量可能小于、等于或大于配置的值。Alluxio不会主动监控副本数量并尝试维持目标多副本级别。

由于多种原因，实际副本数量可能小于目标多副本级别。例如，如果文件在某个时刻缓存在某些工作节点上，但由于缓存容量不足而从某些工作节点中逐出，则其实际多副本级别将小于目标。另一种情况是，如果由于缓存未命中而被动创建副本，并且客户端发现文件已由工作节点缓存，则将直接从缓存中提供文件，并且不会创建新副本。文件的多副本级别将保持不变，直到客户端访问尚未缓存文件的工作节点。

当工作节点成员资格发生变化时，实际副本数量可能大于目标。加入或退出集群的工作节点可能会改变多副本选择算法的结果，从而导致包含副本的工作节点永远不会被选中，从而导致副本无法访问。此副本将保留在工作节点的缓存中，直到由于缓存容量不足而被工作节点逐出或由清除陈旧缓存操作手动触发。

Last updated 14 days ago