去中心化边缘计算副本放置

最新推荐文章于 2025-11-29 08:53:44 发布

原创最新推荐文章于 2025-11-29 08:53:44 发布 · 412 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#边缘计算 #副本放置 #去中心化 #地理局部性 #设施选址

示意图0

一种用于边缘计算的去中心化副本放置算法

摘要

随着构成互联网的设备变得越来越强大，协调云系统的算法正逐渐将更多的计算和存储责任交给这些设备。在当前的大数据时代，跨终端云设备的数据传播与存储正成为一个突出的问题，并受到这一扩展的影响。本文提出了一种分布式数据传播方法，该方法依赖于对底层网络边缘节点发出的数据请求进行持续监控，从而指导副本的动态创建/替换/删除。由于邻近区域内的客户端会产生大量常见的数据请求，我们的算法在传播过程中充分利用了数据的地理局部性。我们使用真实世界和合成数据的实验结果表明，与传统分布式系统中广泛使用的客户端缓存相比，去中心化的副本放置方法具有显著的成本效益。

索引术语

数据复制，副本放置，副本发现，设施位置，云计算，边缘计算。

I. 引言

近年来，由于功能更强大、更智能的设备的出现，云计算系统中的计算点已开始向网络基础设施的终端节点扩展。计算能力的这一扩展引发了一系列新的术语，包括雾计算[1], 、纳米数据中心[2],和云朵[3]。尽管这些概念各有不同特点和优势，但它们大致可归为一类方法，即在云基础设施中更广泛的分布式节点之间分发任务，而非仅限于少数互连服务器。在本文其余部分，我们将此类方法统称为边缘计算。

将计算能力带到网络边缘可以减少延迟并实现代码卸载到云。然而，许多服务需要访问集中存储的数据。因此，数据访问延迟可能成为瓶颈，并抵消边缘计算的优势，尤其是对于数据密集型服务而言。云系统中被吸收、传播和处理的数据量持续增长，要求采用智能的数据分发方法。

本文重点关注在具有大量节点且可用于计算目的的分布式云计算系统中进行数据分发。我们提出一种去中心化的方案来决定复制和将源自中心服务器的数据放置到云网络中的终端设备。我们考虑了云特有的成本和延迟之间的权衡，这是制定激进参数的主要标准，以决定数据向边缘实体推送的程度。

客户端缓存可被视为上述方法的一种特例，具有严格的复制策略，传统上用于分布式系统以减少数据访问延迟。云缓存靠近客户端，在缓存命中时可本地提供所请求的数据，或在缓存未命中时从中央存储远程获取所需数据[4]。然而，缓存方法通常导致数据副本的利用率较低，因为缓存只能为其所在位置的客户端提供服务。而复制则具有提供更具成本效益解决方案的潜力，当副本被放置在关键网络节点上时，可以为多个附近的地理位置的请求提供服务。从这个意义上说，复制不仅可以利用请求的时间局部性，还可以利用地理局部性。

图1展示了边缘计算架构[5]和假设的服务模型。用户设备连接到最近的边缘节点，这些边缘节点之间也通过一定的网络拓扑相互连接。假设所有显示的用户设备频繁请求一个数据对象。在缓存情况下，这三个用户所使用的边缘节点都必须存储相同的数据，以避免每次请求时从中央存储（大规模云数据中心）获取数据而导致高延迟。然而，通过智能复制，只需在灰色突出显示的节点上放置一份该数据的副本即可，该节点与这三个节点连接良好，从而降低了成本并保持了与本地访问相近的延迟。此处，数据对象是任意类型的单个或多个文件的抽象术语。我们的方法对数据对象的大小不做任何假设。

数据复制可以用于实现多个不同的目标，例如提高可用性、安全性、容错性，或降低响应时间和带宽消耗。它在分发中心存储负载和提升可扩展性方面也具有显著效果 [6]。在本研究中，我们重点关注数据复制的性能优势，并特别考虑副本‐客户端接近度，以减少延迟和带宽消耗。

我们的目标是回答以下问题，以在带宽和成本有效的方式下最小化平均副本‐客户端距离。
- 复制哪些数据对象？
- 何时创建或销毁副本？
- 每个对象需要创建多少个副本？
- 每个副本存储在哪里？
- 如何将请求重定向到最近的副本？

尽管将所有数据对象复制到所有存储节点可以实现最佳的接近性和延迟，但由于每个数据对象的需求各不相同且可能具有区域性，这种做法非常浪费[7]。此外，在云计算范式中，服务提供商通常并不拥有存储基础设施，而是以按使用付费的方式从IaaS提供商处租用。因此，通过考虑数据对象的流行度来优化副本数量和位置至关重要[8]。由于存在大量地理分布存储选项，并且有可能利用不同区域和提供商之间的价格差异，智能副本放置技术在多云场景中尤为有效[7]。

本文的其余部分组织如下。在子章节 I‐A 和 I‐B 中，我们分别介绍了对数据引用局部性的分析，该分析启发了我们的方法，并阐述了我们在边缘计算中副本放置方面的贡献。随后，在第二节中，我们对副本放置方法的相关文献进行了详细的回顾和分类。第三节解释了设施选址问题（FLP）及其在副本放置中的应用。我们在第四节和第五节中分别提出了分布式副本放置（D‐ReP）算法并展示了其实验评估结果。最后，我们在第六节中总结了本文的工作。

A. 引用局部性

地理上分布的用户对数据的访问表现出多种模式。这些引用模式可以归纳为三类：时间局部性、空间局部性和地理局部性[9]。时间局部性和空间局部性是已被深入研究并得到广泛解决的问题，而地理局部性由于在大规模分布式系统中存储和处理的数据量不断增加，在我们的研究中被特别关注并日益重要。本文后续部分将采用如下所述的局部性分类。

TemporalLocality 用户访问的数据对象很可能再次被同一用户访问。缓存系统利用时间局部性，在首次请求后本地响应后续请求[10]。

SpatialLocality 用户访问过的数据对象附近或相关的数据对象很可能也会被该用户访问。当存储连续数据块而非独立对象时，缓存也可以利用空间局部性，假设顺序存储的数据对象彼此相关。已有一些方法（例如[11]），通过使用过去的引用记录来预测相关数据对象，并预取以供本地访问。在本研究中，假设数据对象彼此独立，因此未考虑空间局部性。

地理局部性 在分布式系统中一个典型的现象是，被某个用户访问的数据对象很可能也会被附近的其他用户访问。尽管地理局部性普遍存在于大多数分布式系统中，但在某些极端情况下尤为明显，例如在交通拥堵区域，该区域内的驾驶员对地图/交通数据的需求远高于人口稀少地区。这类数据需求的激增往往是动态的，在实际中难以预测。另一个例子是社会活动，如体育比赛或音乐会，用户持续请求相似的数据，例如事件中某一特定时刻的视频流。地理局部性也可能是近乎持久性的，例如城镇居民访问在线公共服务，或游客查阅旅游指南的场景。

为了展示全球互联网请求中地理和时间局部性的程度，我们研究了CAIDA 2015年匿名互联网流量数据集[12] ，时间跨度为一小时（2015年2月19日13:00至14:00）。对不同日期、时间和持续时间的分析得出了几乎相同的分布结果。该数据集包含通过高速骨干链路上的监控器收集的通用互联网流量，我们认为这能较好地估计边缘计算未来的流量特征。云计算基于超大规模数据中心，其流量模式并不适用于去中心化的边缘计算场景。有关CAIDA数据集的更多详细信息见第五节‐A部分。

示意图1
图2显示了请求的请求源距离直方图。它总结了一个随机选择的数据对象的26890个请求对之间的距离分布。根据我们的分析，超过20%的请求相距 1000km 。当我们将直径增加到 2000km时，它几乎覆盖了所有请求的 30%。在 [13] 中关于 Facebook 用户之间的交互也得到了与我们类似的结果。缓存无法从地理局部性中受益，因为用户无法访问且不了解其他附近用户的缓存。因此，需要一种智能的数据复制和副本发现策略，在保持相似数据访问时间的同时降低存储成本。

B. 贡献

本研究的主要贡献有两点。首先，我们提出了一种完全去中心化、动态且在线的算法，用于在边缘计算场景中跨 IaaS提供商进行数据副本放置。其次，我们提出了一种低开销的消息传递方法论，以通知边缘实体附近的副本信息，使其能够将未来的数据请求提交给这些附近副本，而非远程的中央存储。

副本放置算法 我们提出了D‐ReP算法，其中存储副本的存储节点分析对副本的观测需求，并充当局部优化器。它们评估存储副本的成本以及预期的延迟改善，从而决定将副本迁移或复制到某个邻居节点，也可能决定删除本地副本。这些决策旨在基于FLP最大化目标函数。该算法还允许用户通过输入参数控制成本优化与延迟优化之间的平衡。在真实和合成工作负载轨迹上的实验结果表明，副本访问延迟、网络开销和存储成本均有显著改善。

MessagingMethodology 为了获得D‐ReP算法所承诺的优势，边缘实体在请求数据对象时应知晓最近的副本。然而，完全知晓只有通过集中式控制或定期广播副本位置才能实现。我们提出了一种副本发现方法，其中识别出最相关的节点，并仅通知这些节点有关副本的创建或删除。

II. 相关工作

表I总结了关于副本放置的文献。其中，为简洁起见，我们仅对与我们的方法最相关的研究进行评述。我们基于三个二元分类规则（即集中式/去中心化、完全/部分信息、静态/动态）对这些研究进行分类。此外，我们提供了有关其目标环境、网络拓扑限制和优化目标的信息。下文将对表格各列提供更详细的说明。

去中心化（DC）： 勾号（3）表示副本放置算法在多个位置并行执行。其他方法则从单个节点管理放置。

部分信息（PI）： 集式方法总是使用完整的需求和拓扑信息进行放置。然而，一些去中心化算法仅需局部和部分信息即可运行。

动态（DY）： 如果副本的数量和位置根据观察到的需求和/或成本随时间变化，则复制是动态的。网络状态是动态性的另一个来源。在静态复制中，副本在初始创建后不会被复制、迁移或删除。

环境： 算法的执行环境可以是以下之一：云、内容分发网络（CDN）、基于云的内容分发网络（Cloud‐CDN）、点对点系统（P2P）、数据网格、网页（例如互联网服务），或无限制/未指定（N/A）。

拓扑： 如果某种方法对节点之间的网络拓扑图存在限制，我们将在本列中指明。选项包括树、完全图、多层和无限制（即任意图）。

目标： 本列列出了旨在通过复制进行优化的标准。在文献回顾中遇到的标准如下所列。

接近度（PX） 表示用户访问副本的时间。对网络延迟、响应时间、跳数的优化以及距离均归入此标准之下。
成本（CT） 表示存储副本的货币成本。不显式考虑货币成本的方法但旨在最小化副本数量的方法也被包括在内。
带宽 (BW) 表示网络开销和带宽利用率。
可用性 (AV) 表示容错性或可靠性。
负载均衡 (LB) 表示通过将需求分散到多个节点上来避免热点。

另一种副本放置算法的分类可以在[44]和[45]中找到。感兴趣的读者还可以参考综述[6]和[46]，以了解有关数据网格中动态副本放置的更多细节。

集中式方法缺乏可扩展性，并在副本放置中产生性能瓶颈。对于诸如互联网和云之类的大规模分布式系统而言，这些方法尤其不可行。然而，由于去中心化带来的额外复杂性，大多数关于副本放置的文献仍采用集中式方法。首先，在动态环境中，复制算法的输入（如需求、延迟、成本）和输出（如副本的数量和位置）的高效同步具有挑战性。其次，与全局知识相比，关于环境的局部知识会降低放置质量。因此，一些去中心化方法假设每个位置都具备全局知识，从而像集中式方法一样面临可扩展性问题。

A. 集中式方法

在[26]中研究了云服务共享数据的地理放置。建议的技术将数据放置在其用户的加权地理中心，并在考虑负载均衡的同时，将其映射到最近的数据中心。在[28],中，首先根据数据的流行度、时效性和客户指定的重要性计算副本数量。然后通过最小化距离度量，将计算出的副本数量放置在数据中心。

在[20],中，作者提出了一种方法论，以放置数据副本来实现双重目标：通过将互补片段放置在非相邻位置来提高安全性，以及通过将副本放置在中心位置来减少数据访问时间。他们利用中介性、接近性和离心率中心性度量以及图着色来实现这些目标。建议方法为每个数据片段始终创建单个副本，而不考虑其流行度。副本被放置在对该数据访问次数最多的节点上。

在另一项研究 [8], 中，提出了一种除副本选择和放置之外的请求重定向策略。该策略优化了在存储云上向用户分发内容时的数据存储和传输成本。提供了混合整数规划和多种启发式解决方案。实验比较表明，在线和动态算法在成本以及服务质量违规数量方面具有优越性。

在[22]中提出了一种将任务映射到副本以及将副本映射到数据中心的两阶段映射方法。所提出的遗传算法解决方案假设副本数量预先已知，并旨在通过减少数据中心之间数据移动的数量和大小来降低成本和延迟。

还存在一些研究，专注于在特定类型的图拓扑上进行副本分布。文献[14]考虑了树形网络，并特别关注读写成本。另一种基于树拓扑的解决方案[31]旨在最小化延迟方面的服务质量违规次数。建议方法利用已实施的复制实践（旨在提高可用性），将具有高服务质量要求的应用程序数据放置在高性能节点上。最近，复制与擦除编码的结合利用编码机制来提升多云中的可用性[47],[48]。

通常，集中式方法通过利用中心性度量来实现副本的最优或近似最优放置。然而，与分布式和去中心化方法相比，这些方法存在以下缺点[42]。
- 收集和传输完整的系统状态（例如每个文件的需求、存储成本、网络信息等）会导致网络开销，尤其是在动态大规模系统中。
- 类似地，分发控制数据（例如副本文件及其位置）会占用带宽并导致延迟，从而增加算法的响应时间。
- 优化计算代价高，且随着节点数量的增加扩展性差。
- 算法通常不是迭代的。因此，即使对于微小的变化，也必须进行完整的重新优化。
- 对于基于中位数的算法，副本数量必须先验给定。
- 中央副本控制器是单点故障。

B. 去中心化方法

在最早尝试动态副本放置[40],的研究中，作者提出了一种分发树来复制和同步数据。其目标是在满足延迟保证和负载均衡的同时，在访问路径上放置最小数量的副本。此外，除了复制外，还使用了缓存来实现这一目标。

提出了一种文件复制算法，该算法将副本放置在 P2P系统的客户端‐服务器路径上的所谓流量枢纽节点上 [41]。其目标是使复制比在路径的所有节点上创建副本更具成本效益，并且相比客户端缓存能实现更高利用率的副本。流量枢纽是指针对同一文件的多条客户端‐服务器路径交汇的节点。所建议的算法是去中心化的和自适应的，即每个节点可以通过分析流经自身的流量并确定最流行文件来自主决定是否存储副本。尽管此类分析在某些P2P场景中是可行的，但在云环境中会引起隐私问题。

文章[39]的作者提出了一种用于由复制组（例如大学中的院系）组成的系统的分布式副本放置算法。当请求数据时，可以从组内的其他服务器提供，从而比从源服务器获取数据减少访问时间。然而，这种算法不适用于云或边缘计算模型，因为在这些模型中固有的复制组不存在，且拓扑结构巨大且高度动态。

在[37],数据网格拓扑被划分为网络区域，其中复制和放置决策得到优化。此处的主要重点是避免网络拥塞。类似地，研究[35]的作者建议划分云拓扑图，并在每个集群中贪婪决定副本的数量和位置，以尽量减少内容提供商与其用户之间的跳数。尽管这些方法以分布式方式进行副本放置，但仍需要完整的拓扑信息用于集中式划分阶段。

与我们的工作最相似的研究之一是[36]。作者提出了一种基于博弈论模型的算法，该算法在每个节点上自主执行，可根据可用性、通信成本和货币成本决定复制、迁移或删除其数据。他们的方法与我们的主要区别在于，每个节点都知晓其他副本的位置以及所有其他节点的租金价格、需求和带宽。此外，这些信息必须定期更新，这在拥有数百甚至数千个节点的边缘计算场景中将导致性能瓶颈。

基于原始‐对偶的分布式近似算法在图论文献中被提出用于FLP，并且其变体已应用于互联网服务部署 [42],[43]。在前者中，针对邻近的一组节点（称为r‐球）迭代地求解小尺度FLP。后者研究引入了条件介数中心性度量，并取消了设施位置必须位于r‐球内的限制。为此，在每次迭代时计算拓扑中最中心的节点，并在所选节点子集上求解FLP。与这两种方法不同，我们的目标是消除非相邻节点之间的任何消息传递或广播。对于单个FLP实例（例如复制互联网服务），跨多跳报告需求估计、中心性值或设施位置决策是可以接受的。然而，在我们的情况下，数据对象的数量以及相应的FLP实例数量可能轻易达到数千甚至数百万，这将导致不可行的网络开销。因此，任何需要节点间频繁通信的副本放置算法对于细粒度数据对象而言都是不切实际的。

III. 设施选址问题

设施选址问题（FLP）关注的是在地理上分散的客户需求下，以最小成本设置设施的位置[49]。在某个位置开设设施的成本取决于该设施所服务客户之间的距离及其需求，其中还可能包括任意固定成本。不同的目标函数和约束条件导致了该问题的多种变体，但这些变体均包含上述核心思想。

在本节中，我们首先概述文献中现有的问题模型及其优缺点，然后详细阐述如何将问题应用于在分布式云基础设施上放置数据副本的情况。表II列出了本文通篇使用的符号及其定义。

A. 问题模型背景

为简洁起见，此处我们仅讨论离散FLP模型，其中设施只能在有限数量的地点设立。在此类模型中，客户和可能的设施位置及其距离可以表示为一个简单的加权无向图。

最基本的离散FLP模型旨在寻找单个设施的最优位置，使得从所有客户位置到该设施的距离总和最小。在 [50],

表II D‐REP算法和FLP符号说明
| 符号 | 解释 |
| — | — |
| hi | 特定客户的单位需求水平 |
| dij | 给定客户与设施之间的距离或单位需求的运输成本 tomer和设施每单位需求 |
| fi | 在特定位置开设设施的成本 |
| Xij | 二元变量，表示是否给定设施 ity是距离给定客户最近的开放设施 |
| Yi | 指示在给定位置设施是否开放的二元变量在给定位置开放 |
| unit_pricei | 在给定边缘节点中每分钟存储单位数据（例如字节、MB，等）的价格（美元）副本_大小要复制的数据对象的大小，单位相同 |
| epoch | 预定义的时段持续时间（分钟） num_requestsi给定副本在前一个时期 |
| 延迟ij | 给定用户与副本之间的端到端延迟位置（以毫秒为单位） |
| λ | 副本扩展级别 |

定义了三类问题：中位数、覆盖和中心问题。

在中位数问题中，要定位的设施数量（k）是预先已知的。在此类问题中，每个客户的成本函数定义为该客户的需求（hi）乘以其到最近设施位置的距离（dij）。最优解是使所有成本之和最小化的 k 个工厂的位置，如公式1所示。其中 Xij 是一个二元变量，如果位于 j 的设施是客户 i 的最近设施，则该变量被设置。

$$
Total Cost=\sum_{i}\sum_{j} h_i \cdot d_{ij} \cdot X_{ij} \quad (1)
$$

在覆盖问题中引入了开设设施的固定成本，其目标是在保持预定义的最大可接受服务距离的前提下，最小化总固定成本。在此类问题中，无需事先提供最优设施数量。

FLP 的第三类在 [50] 中被称为中心问题。给定要定位的设施数量，其目标是最小化客户与最近设施之间的最大距离。

所有这些问题类别都需要预先知道设施的数量或最大可接受距离。在[51]中提出了一个没有此限制的FLP一般定义。公式1使用相同符号，其一般成本如公式2所示，其中引入了另一个二元变量Yj ，用于表示在j处是否开设设施，以及f j，表示在j处开设设施的固定成本。此外，此处 di j应被视为单位服务成本而非距离。

$$
Total Cost= \sum_{j} f_j \cdot Y_j +\sum_{i}\sum_{j} h_i \cdot d_{ij} \cdot X_{ij} \quad (2)
$$

设施选址问题的进一步变体包括具有有限设施容量、参数的有限信息（例如需求和成本）、多种类型的需求、多种类型的设施以及未来参数的不确定性的模型[49],[50]。

B. 问题的调整

在副本放置问题中，最优副本数量无法先验得知。因此，公式2中的成本函数更符合我们的情况。此外，我们考虑该问题的无容量限制版本，因为云资源的分配超出了本研究的范围。读者可以参考我们之前关于云系统中去中心化资源分配的工作[52]。

具有多种产品（即多商品FLP）的FLP模型旨在确定能够优化所有产品到需求距离的设施位置。这在工业案例中至关重要，因为在特定位置建设设施具有固定成本，且为每种产品单独建造设施是不可行的[49]。然而，在存储即服务（STaaS）场景中，前期成本和承诺被消除，客户仅需为其使用的存储付费。因此，无需将多个副本聚合到一个提供商中，每个副本的位置都可以单独优化。因此，我们为每个副本求解单商品FLP实例。设施开启成本（f j）转化为IaaS提供商直到算法下一次迭代（即下一个周期）为止所收取的存储成本。

$$
f_j= unit_price_j \cdot replica_size \cdot epoch \quad (3)
$$

客户的需求（hi）与前一个时期内副本接收到的请求数量成正比。

$$
h_i= num_requests_i \cdot replica_size \quad (4)
$$

最后，选择距离度量 dij 作为虚拟机与副本位置之间的延迟。由于 f j 是货币单位，因此 dij 也应转换为相同的单位，以使加法两边具有可比性。这就是我们建议引入一个单位转换因子 λ 的原因，它表示为每单位需求的单位延迟减少所愿意支付的可消耗单位成本。 λ 参数的值还决定了副本扩展级别，我们将在第四节中进行解释。

$$
d_{ij} = latency_{ij} \cdot \lambda \quad (5)
$$

适应后的FLP的成本函数的最终定义见公式6。注意，副本_大小从加法的两侧都被移除，因为它在每个问题实例中是常数，对最小化目标没有影响。

$$
Total Cost= \sum_{j} unit_price_j \cdot epoch \cdot Y_j +\sum_{i}\sum_{j} num_requests_i \cdot latency_{ij} \cdot \lambda \cdot X_{ij} \quad (6)
$$

我们假设已知每个数据对象的当前需求以及IaaS提供商的存储价格。存在一些战略型FLP变体，用于建模未来需求和成本的不确定性。这些变体会将设施作为长期投资进行部署，从而降低因未来变化带来的风险，因为建设设施是一项成本和时间敏感的决策。然而，在云计算的情况下，此类约束不再适用。得益于按需付费存储，副本可以即时重新定位，且几乎无需成本。通过在副本迁移到目标节点之前始终将其保留在源节点，我们避免了服务中断。

IV. 去中心化副本管理

A. 需求与假设

D‐ReP算法的主要要求是以最小化公式6中给出的成本函数的方式，在存储节点（基于云的存储提供商和边缘实体）之间放置副本。此外，我们的场景中还涉及若干非功能性需求。

首先，该算法必须是分布式且完全去中心化的。如第二节所述，由于节点数量庞大，集中式算法不适用于边缘计算场景。在中心节点收集全局拓扑和需求信息并执行完整优化算法，其可扩展性随节点数量的增加而显著下降 [43],[53]。关于副本放置的节点间通信也应保持最小化，以避免额外开销。其次，多云和边缘计算环境是高度动态的。边缘用户通过具有各种延迟的连接不断加入和离开网络。每个节点对每个数据对象的需求以及存储价格也可能随时间发生显著变化。因此，副本的数量和位置应具备动态性。最后，该算法应为在线算法，因为无法获得关于未来请求和环境的先验知识。

考虑到上述约束，D‐ReP算法的输入仅限于以下几项。在节点中执行的每个算法实例仅了解该节点及其在无向网络拓扑图中的直接邻居。我们假设以下列出的信息可以通过标准监控工具（例如Skitter）、DNS查询或路由表收集。
- 每个存储在该节点中的副本的请求数量
- 每个请求所通过的邻居节点到每个相邻节点的感知延迟
- 每个邻居节点的单位存储价格

我们研究中的另一个假设涉及副本的一致性。由于在云计算和边缘计算场景中，数据一致性与传统分布式系统相比没有显著差异，因此将其视为范围之外。我们假设数据为只读数据（如内容分发网络 [9],[27],[28] 中的典型情况），或存在一个独立一致性服务。在后一种情况下，可实现任意基于主副本的分布式协议，例如视图标记复制、 Paxos 或 Zab。

B. D-ReP算法

该算法的两个版本（即源端和边缘端）在等间隔的 epoch中被触发，并迭代地将副本从源节点（中央存储）推向请求的边缘节点。一组邻近且重复请求相同数据对象的节点会引发副本的创建和向它们的迁移。当需求减少时，副本会被丢弃或迁移到其他位置。

源版本算法在与中央存储相同的节点上运行，且只能在该节点的邻居中创建数据对象的副本。而边缘版本在至少存在一个副本的每个节点（即活动节点）上运行。每当租用存储空间以在该位置存储第一个副本时，云服务提供商都会配置一个微型虚拟机。当没有剩余副本或经过一段时间的不活动后，该虚拟机可以自行关闭或终止。此版本可决定是否将副本复制或迁移到邻居、删除副本，或不执行任何操作。两个版本中的所有操作均通过比较预期收益与成本来决定。这两个版本之间或算法的边缘实例之间不存在通信或交互。

1) 源版本： 如果数据对象 k在中心存储节点 c的邻居 n中创建副本所带来的预期延迟改善值得付出该副本的存储成本，则在此处创建副本。换句话说，复制后公式6 中的成本值应降低。公式7是创建新副本的条件。

$$
num_requests_{knc} \cdot latency_{nc} \cdot \lambda > unit_price_n \cdot epoch \quad (7)
$$

这里num_requests_knc表示在最近的epoch(s)内，通过n 由c接收到的关于k的请求数量。如果该条件对于任意邻居均不成立，则在当前迭代中不会为该数据对象创建副本。

2) 边缘版本： 如果新副本预期带来的延迟收益大于其存储成本，则副本可以在其当前宿主节点n的相邻节点 h上进行复制。公式8与源版本中的新副本创建条件（公式7）相同，只是将c替换为h。

$$
num_requests_{knh} \cdot latency_{ynh} \cdot \lambda > unit_price_n \cdot epoch \quad (8)
$$

如果邻居不满足复制条件，则转而评估公式9中的迁移条件。这里，N是h的所有邻居的集合。当通过n接收的请求延迟将减少latency_nh时，我们假设来自所有其他邻居的请求延迟将增加相同的量，因为这些请求将通过h响应。实际上，这些邻居可能与n之间存在更低延迟的连接，并可能绕过h。但由于算法仅拥有局部拓扑信息以实现去中心化，因此无法知晓此类连接。

$$
(num_reqs_{knh} −\sum_{i∈N, i≠n} num_reqs_{kih}) \cdot latency_{nh} \cdot \lambda >(unit_price_n − unit_price_h) \cdot epoch \quad (9)
$$

由于新副本的创建或需求的变化，副本可能会变得利用率不足。在这种情况下，应将其丢弃，以避免不必要的存储成本。副本或缓存替换是分布式系统中，特别是数据网格中一个研究较为充分的领域。相关技术不仅包括传统的超时、 LRU、LFU 或 FIFO，还包括更复杂的基于权重 [54] 和基于预测 [55] 的方法。为了集中关注副本放置问题，我们采用基于阈值的权重计算，即当某个副本在上一个 epoch 的利用率低于一个动态阈值时，该副本将被移除。该阈值被计算为一个预定义的比例（即 fade_rate ∈ [0, 1]) 在创建副本时的预期利用率（即original_num_req_sh），如公式 10 所示。

$$
\sum_{i∈N} num_requests_{kih} < original_num_reqs_h \cdot fade_rate \quad (10)
$$

D‐ReP算法的伪代码如图3所示。在每个epoch中，该算法遍历所有本地存储的副本，并对尚未拥有相同副本的每个邻居节点验证公式 8 和 9。在第5行和第9行中，中断语句确保每个副本在一个epoch内最多只能做出一次复制或迁移决策。如果第二个for循环（第3–10行）正常终止（而非因中断语句退出），则执行else部分（第12–14 行），其中验证公式 10。这种for…else 结构保证了只有当副本未被选中进行复制或迁移到邻居节点时，才可被删除。还应注意，该算法建议的复制和迁移操作仅在目标节点具有足够存储空间的情况下才能执行。该算法的时间复杂度为O(|K||N|)，其中|K|表示该节点上存储的副本数量， |N|表示邻居节点的数量。

用户提供的参数 λ 可由服务提供商调整，以控制成本和延迟水平。较大的 λ 值会导致在网络中进行更激进扩展的副本部署，从而以更高的存储成本换取更低的延迟值。 D‐ReP 还可以被扩展以实现更精确的延迟保证。在这种情况下，所有请求的端到端延迟需要被监控并用于决策。

示意图2

C. 副本发现

在副本盲服务中，请求节点不知道副本位置，因此总是将请求提交给中央存储。如果在路径上存在拥有请求数据副本的节点，该节点将响应请求[25]。副本盲服务通常实现在特定领域的单租户分布式系统中，例如内容分发网络。然而，在云等多租户系统中，服务器无法分析流经它们的请求，因此必须具备副本感知能力。副本感知服务还使得可以通过靠近但不在通往中央存储路径上的副本位置来响应请求。

我们提出了一种用于副本发现的通信系统，以补充 D‐ReP算法。根据该算法的去中心化设计，该通信系统不依赖广播消息和集中控制。我们的目标是仅在某个节点预计将在不久的将来请求某个副本时，才通知该节点有关此副本的信息。这种预测性基于请求的时间局部性和地理局部性。每个活跃节点都维护一个已知副本位置（KRL）表。该表存储副本ID、副本节点以及到副本节点的延迟。它可为每个副本包含多个位置，并在以下情况下进行更新。
- 当副本从n1迁移或复制到n2时，新主机n2会通知在最近的epoch中曾向n1请求过该副本的所有节点。这些节点的列表随创建命令和副本一起从n1传输到n2 。
- n2在创建和删除副本时也会通知其邻居。
- 到副本节点的延迟通过从n2接收到通知消息所观测到的延迟来近似，并在n2响应请求时进行更新。

示意图3
图4展示了当用户在其本地边缘节点请求数据对象时所评估的决策树。如果该节点上存在该数据的副本，则以最小延迟响应请求。如果副本未存储在本地，但该节点知晓该数据的一个或多个副本，则向延迟最低的副本节点发送请求。否则，将从具有高延迟的中央存储中获取数据。为

D. 一个用例场景

让我们继续以第I‐A节中提到并在图5中详细说明的交通数据传播示例来阐述副本放置与发现的执行方式。在此示例中，由于交通拥堵，基于云的导航服务的用户聚集在某一区域。他们利用附近的边缘数据中心（E‐1）来满足其导航与路径规划方面的计算需求。考虑到这些用户位于同一条道路上，他们的数据需求（例如区域地图、交通密度等）是相似的。

假设E‐1最初不存储所需导航数据的副本，且其 KRL表中也不包含该数据的任何条目。因此，将通过数据 ID向中央存储（CS）请求该数据。同时假设，运行在 CS中的D‐ReP算法源版本由于来自该方向的高需求，决定在其中一个邻居节点——边缘数据中心2（E‐2）中创建该导航数据的副本。副本创建消息包括对该数据的最近访问位置（rec[]）以及数据本身。由于E‐1最近请求了该数据，当副本成功创建后，E‐2将向E‐1及其邻居（E‐2‐N）发送通知消息。通知消息指示将其新位置（loc）添加到该数据（id）的KRL表中。如果E‐1与E‐2之间的延迟低于 E‐1与CS之间的延迟，则后续对该导航数据的请求将被指向E‐2（见图4）。

让我们进一步假设，现在在E‐2中运行的算法的边缘版本决定在未来周期中将副本迁移到E‐1以进一步改善延迟。E‐2的邻居将收到此操作的通知，从而将其KRL表中该数据对应的E‐2条目删除，并根据其KRL表中的条目将后续请求指向E‐1（为简洁起见，我们省略了E‐1如何被添加到其KRL表的过程）。此外，E‐1中类似导航任务的数据需求将由本地响应。

V. 评估

我们扩展了广泛使用的仿真框架CloudSim[56],，以评估D‐ReP的性能并研究其运行时行为。同时在 CloudSim中建模了缓存系统和集中式存储（无复制）系统，以便与D‐ReP进行比较。本节将展示我们的研究结果和分析。

A. 实验设置

为了真实地评估D‐ReP算法和基线方法，我们使用 CAIDA 2015年匿名互联网流量数据集[12]。该数据集包含来自CAIDA的“equinix‐chicago”高速监测器的匿名被动流量轨迹。具体而言，我们使用2015年2月19日13:00至 14:00（协调世界时）之间的IPv4数据包数据，其中包含超过23亿条记录。由于模拟中涉及大量参数、详细的分析层次以及由此带来的高计算复杂度，我们无法分析更长时间段的数据。我们利用GeoLite2 IP地理定位数据库1将源IPv4地址映射到地理位置。我们使用亚马逊S3价格2来计算存储和数据传输成本。

由于CAIDA数据集不包含网络拓扑信息，因此使用 BRITE工具[58]基于巴拉巴西‐阿尔伯特无标度网络生成模型[57]生成一个无向网络拓扑图。该模型因借鉴了真实网络的两个特性——增量增长和优先节点连接性，被广泛用于表示互联网等人造网络。当新增节点时，边生成的概率函数确保新节点倾向于连接到连接度更高的节点，即中心节点。生成的拓扑包含放置在 1000× 1000坐标平面上的1000个节点、2994条边，以及带宽在10至1024 Mbps范围内的重尾分布（帕累托分布，形状参数为1.2）。选择上下限值是为了表示从边缘的终端用户网络到大型数据中心之间千兆以太网连接的广泛范围。中央存储的位置选择为具有最大接近中心性的节点。

与D‐ReP不同，缓存系统中的副本直接在请求数据对象的节点上创建，且这些副本只能由其创建者使用。每个缓存中可存储的副本数量有限。当缓存容量满时，采用最近最少使用（LRU）缓存替换策略。仿真变量为周期长度、 λ和缓存容量。变量的范围和默认值见表III。每次实验中，其中一个变量发生变化

1 http://www.maxmind.com/
2 https://aws.amazon.com/s3/pricing/

表III 仿真变量的范围和默认值
| 仿真变量 | 范围 | 默认值 |
| — | — | — |
| 周期长度（分钟） | [1, 20] | 3, 10 |
| λ | [0.01, 0.20] | 0.10, 0.16 |
| 缓存容量 | [10, 200] | 30 |

而其他参数则被赋予其默认值。范围限制的选择需确保 D‐ReP和缓存算法的最佳性能，同时考虑实际约束（例如，即使算法表现良好，也不会使用不切实际的过短或过长的 epoch，或过小的缓存容量）。

除了CAIDA互联网流量数据外，该算法还通过合成用户需求进行评估，以推广结果和结论。此处同样采用上述描述的相同网络拓扑、基线方法和仿真变量。使用多种概率分布来生成请求的位置，以便实验不同层次和形式的地理局部性。在表IV中，均匀分布、指数分布、正态分布、卡方分布和帕累托分布被列为评估中使用的五种不同分布。对于后三种分布，分别使用三个不同的参数值，共形成十一种不同的情况。针对每种情况，在 1000×1000平面上使用相应概率分布的两个实例（分别对应x和y坐标），随机生成100000个请求的x和y坐标。

每个数据请求都被分配给在坐标平面上欧几里得距离最小的边缘节点。对于CAIDA跟踪数据，数据请求的地理坐标（即纬度和经度）均被投影到范围[0, 1000]内以实现此目的。另一方面，表III中随机分布的参数被选择为使得生成的大部分值都保持在范围[0, 1000]内。任何异常值都被重新分配到最近的端点。图6显示了从CAIDA跟踪数据分配到最多数据请求的200个节点。为了演示目的，这些节点的位置从 1000 × 1000平面逆向映射回地理坐标系。

B. 延迟和成本

我们使用延迟改进率来衡量D‐ReP和缓存解决方案相较于无复制方案在降低副本平均访问延迟方面的程度。在图7中，展示了算法随着λ变化的延迟改善情况。由于 λ 仅对D‐ReP有效，因此缓存的延迟改善保持在25.60%不变。当我们增加λ时，D‐ReP能够承担更多的副本，尤其是在边缘位置。因此，到副本的平均延迟稳步下降，达到与缓存相当甚至更优的水平。如图8所示，增加周期持续时间（e）也在一定程度上改善了延迟。然而，这种改善并不十分稳定，并且在约7分钟长周期后趋于收敛。较长的周期有利于聚合更多数据以进行有效分析，但会降低对需求微小变化的响应能力。

我们还测量了每种方法在中央存储成本之外引起的副本存储成本比率。图9和图10表明，在所有情况下，D‐ReP 引起的成本明显低于缓存，只有在 λ 值非常高（≥ 0.16）和 epoch 非常长（≥ 15mins）时例外。在此情况下，缓存引起的额外成本恒定为14.46%。为了更好地解释图7至图10中的相对改进率，我们列出了无复制方案的绝对成本和延迟值。平均数据访问延迟为1.82s，每次请求的数据存储和传输成本为0.24美元。因此，30%的延迟改善率对应于时间上0.55s 的提升，这对于用户而言意义重大，因为用户在一个会话中很容易请求数百个对象。

C. 效益成本比

我们使用效益成本比（BCR）指标[59]来评估算法在数据访问延迟与数据存储/传输成本之间权衡的效率。 BCR 汇总了一项方案的整体性价比，当最有利可图的选项并不明显时（例如，更昂贵的选项也更具优势），该指标有助于在不同选项之间做出决策。较高的 BCR 值更为理想，而 BCR 小于 1 的方案通常会被拒绝。在本例中， BCR 的计算方式为延迟改善率除以额外成本率。BCR 的公式见公式11。

$$
BCR= \frac{Latency\ Improvement(\%)}{Additional\ Cost(\%)} \quad (11)
$$

如图11所示，在所有 λ值下，D‐ReP 的成本效率更高，平均效益成本比（BCR）比缓存高出1.93倍。结合图 7和图9的结果可以看出， λ可用于以成本高效的方式控制所需的延迟水平。‘D‐ReP (e = 3)’的第一个数据点未在本图表中显示，因为其效益成本比（BCR）值异常高（18.87），原因是分母（附加成本）接近于零。而图12 则表明，较长的周期持续时间可能比缓存效率更低。尽管在图8中延迟改善已收敛，但在图10中成本仍在急剧上升。因此，周期持续时间并不是控制延迟的合适方式。

尽管我们在两幅图中展示了缓存的恒定效益成本比，但缓存的效率也因其容量而异。较大的容量意味着更高的缓存命中可能性，从而降低平均延迟。图13显示，在大多数情况下，缓存的效益成本比显著低于D‐ReP。仅在缓存容量非常小、延迟改善有限的情况下，两者才具有可比性。这些结果表明，缓存仅能在成本极低的情况下少量减少延迟，若要实现显著的延迟改善（例如 ≥ 20%），则是一种成本较高的方法。

表V 网络开销因素百分比
| 通知消息百分比 | 2.63% |
| — | — |
| 失败请求百分比 | .819‰ |
| 因失败导致的延迟百分比 | 1.11‰ |

D. 网络开销

D‐ReP算法和缓存都会降低整体网络利用率，因为部分请求可以从附近的节点响应。尽管迁移和复制带来了额外的数据传输，图14仍展示了相对于单一存储方法在网络利用率上的降低。对于大多数 λ值，结果具有可比性。与缓存不同，D‐ReP算法需要一种副本发现策略，如第IV‐C节所述。用于副本发现的通知消息除了常规数据请求和响应外，还会带来网络开销。我们提出了一种避免广播和集中控制副本位置的策略，以最小化网络开销。然而，由于这一限制，副本发现并非最优。也就是说，某些节点可能会向其KRL表中已实际被删除的副本位置发送请求。这种同步失败也可能导致网络开销。

表V展示了所有消息中通知消息的百分比、所有请求中失败请求的百分比，以及这些失败请求导致的延迟所占的百分比。我们的结果表明，这些比例均可忽略不计。

E. 收敛

D‐ReP 是一种近似算法，不能保证收敛到最优解。然而，可以考虑以下两点：(i) 当用户需求静态时，其在搜索空间中收敛到某一点的情况；(ii) 在使用真实世界动态需求时，系统中活跃副本总数的行为表现。对于后者，我们提供了实验评估；而对于前者，我们从理论上进行讨论。

D‐ReP算法的每次迭代都基于在前一个时期收集的数据快照进行操作。因此，即使创建了新的副本，图3中算法第1行和第2行的两个for循环也会在有限步后终止。

与此同时被其他实例占用。在静态环境中，就副本数量而言的最坏情况是每个节点都创建了一个副本（i×j个副本）。此后，内部for循环的域为空集，因为每个邻居n都有副本k，且元组(n,k)必须存在于节点h的KRL表中。因此，直接执行else部分（第12‐14行），而不检查迁移和复制条件。由于需求是静态的，并且 fade_rate定义在范围 [0, 1],内，第12行的if条件不成立。综上所述，要执行的操作集合O必然为空，优化（迁移、复制和删除）停止。

我们还使用CAIDA跟踪数据评估了系统中副本数量随时间的变化情况。图15展示了以一分钟为间隔的副本数量以及四种操作的发生情况。对于副本删除操作，参数 fade_rate的值设为0.5。结果表明，创建和删除的数量大致相等，副本数量在约200个副本时收敛。尽管迁移和复制操作的数量相对创建操作较少，但它们是D‐ReP算法的主要因素，使得副本能够更靠近请求者。

F. 合成数据

图16中的结果表明，D‐ReP在每种生成的请求位置情况下均能带来延迟改善。然而，改进速率取决于地理分布的程度。均值为500、标准差为50的正态分布产生的延迟改善最佳，而均匀分布产生的改善最差。效益成本比（ BCR）结果（为简洁起见省略）在分布的相对性能顺序方面类似。

这些结果并不意外，因为均匀分布导致数据请求中不存在地理局部性，即数据对象的请求位置完全是随机的。 D‐ReP 特别利用了地理局部性，因此在均匀分布情况下影响甚微或几乎没有影响。然而，随着非均匀性增加，结果得到改善。我们使用了方差

。)

通过概率密度函数（PDF）来估计分布的均匀性。例如，完全均匀分布的PDF是一个方差为零的常数函数。为了展示均匀性的影响，图17展示了分布的PDF方差（不要与分布本身的方差混淆）与使用该分布所达到的效益成本比之间的映射关系。这两个变量之间存在较强的正线性关系，皮尔逊相关系数（r）为0.78。从这些结果可以得出结论：当位置分布的PDF方差较高时，即请求的地理位置在某些区域密集聚集时，D‐ReP算法最为有效。这通常也是实际工作负载中的情况。

六、结论

随着云中数据量和速度的增加，数据产生、处理和消费的地理分布也变得越来越重要。将数据传输到远程数据中心进行处理，并将结果传回用户位置的做法正变得越来越不可行。在本研究中，我们致力于解决基于用户需求的规模和位置以及存储定价，在网络边缘实现延迟感知且成本高效的数据副本放置问题，以降低数据访问延迟。我们提出了一种完全去中心化的动态副本放置算法 D‐ReP，该算法基于 FLP 且仅需要局部拓扑信息。该算法还配有一种副本发现方法，能够通知相关节点有关附近副本的信息。

实验结果表明，D‐ReP在延迟和成本方面相较于非复制数据源和客户端缓存均表现出有效性。根据所选的权衡控制参数值，去中心化的副本放置要么以比缓存低14%的额外成本实现相同的延迟改善，要么在相同额外成本下将延迟改善提高26%。此外，还表明由副本放置和发现引起的通信开销和通信错误可以忽略不计。通过多种随机分布生成的合成使用模式的附加结果进一步推广了我们的发现，并表明算法性能与地理局部性程度之间存在相关性。

我们预计，所提出的方法将对数据请求或用户集中在多个相对较小地理区域（例如城市范围内）的软件服务产生最显著的影响。这是因为，在广域网中长距离移动副本会产生显著的传输延迟和成本。我们针对不同请求分布进行的实验支持了这一观点。同样，另一个需要考虑的因素是复制数据的大小。一些在请求局部性和数据大小方面我们认为合适的应用程序包括：交通监控与导航、移动（实时）视频流以及智能建筑。

在网络边缘进行复制的进一步研究是必要的，当地理分布式提供商的统一变得普遍时，才能充分实现其目的。关于统一最重要的问题是边缘提供商对应用程序编程接口的标准化。另一方面，D‐ReP 提供尽力而为的延迟改善和成本降低。尽管它的性能优于现有替代方案，但在电子健康、工业控制或自动驾驶汽车等领域的某些关键服务可能需要实时性能保证。因此，将 D‐ReP 扩展以具备此类能力仍是一个开放性问题。