文章主要介绍的是Retro，一个resource management framework for shared distributed systems。

具体而言，就是用AspectJ去提取按workflow抽象的资源用量；提了两个指标slowdown和workload来无单位地表示resource抽象的竞争；用令牌桶实现control points的限速； decouple控制策略，实现了三种策略。

有一个总结很好的地方：bottleneck可能是由于以下原因带来的：input workload；workload of other tenants；system tasks；overall state of the system（including caches）；the （nonlinear） performance characteristics of underlying resources

文章贡献

提出了workflows, resources, and control points的抽象
在hadoop上执行per-workflow resource tracking和resource aggregation
Targeted and reactive policies for providing latency SLOs, bottleneck resource fairness, and dominant resource fairness
一个中央控制器

Design

Retro abstractions

retro这边做了一下decouple，核心是三个概念：workflow、resources、control points

workflow：实际上就是把各种活动按照workflow去聚合。具体什么是workflow，由系统设计者决定。为了正确地将资源使用归属于各个工作流，Retro将工作流的ID沿着所有请求的执行路径传播。

resource：Retro的一个关键假设是，资源管理策略可以而且应该在一个共同的抽象下统一处理所有资源。为了克服这一挑战，Retro通过两个无单位的指标来捕获资源当前的一阶性能。

slowdown表示与没有竞争的基线性能相比，该资源目前有多慢。
负载是一个按工作流计算的指标，它决定了谁是造成速度下降的原因。

Retro中的反应式策略允许这些指标为复杂的非线性行为提供一个线性近似。这些策略不断地测量资源指标，同时进行增量的资源分配变化。在这样一个反馈循环中运行，可以实现简单的抽象，同时对资源的基本性能特征的非线性作出反应。

这种抽象的一个重要含义是，不可能查询一个资源的容量。相反，如果减速超过某个固定的常数，策略可以将资源视为已达到其容量。直接测量真正的容量通常是不可能的，因为支持许多请求类型（例如磁盘上的打开、读取、同步等），并且由于缓存或缓冲的影响，工作流需求不是线性组成的。另外，由于limping hardware，估计当前的工作能力几乎是不可能的。

Control points：控制点是请求执行过程中的一个点，在这里Retro可以执行资源调度策略的决定。核心意义在于策略的集中配置。

每个逻辑控制点有一个或多个实例。有一个实例的点是集中式的，比如HDFS NameNode中RPC队列前面的一个点。分布式的点，如在DataNode或其客户端，有许多，可能是成千上万的实例。每个实例测量当前每个工作流的吞吐量，并在控制器中进行汇总。

为了实现细粒度的控制，一个请求必须通过控制点，否则，它可能会消耗无限制的资源量。

architecture

首先，Retro有一个测量基础设施，提供所有系统资源和组件的近实时资源使用信息，并按工作负载划分。
第二，逻辑上集中的控制器使用资源库将原始测量结果转化为负载和减速指标，并将其作为Retro策略的输入。
第三，Retro有一个分布式的、协调的执行机制，将政策的决定一致地应用于系统的控制点。我们在以下段落中讨论控制器的设计。

在目前的系统中，资源管理政策被硬编码到系统实现中，使得它很难随着系统和政策的发展而维护。Retro后面的一个关键设计原则是将机制（§4）与政策（§5）分开。

Implementation

Per-workflow resource measurement

End-to-end ID propagation：Retro将执行请求的线程与工作流相关联，将其ID存储在线程局部变量中；当执行完成后，Retro将删除这一关联。虽然开发者必须在RPC或批处理操作中手动传播工作流ID，但当使用Runnable、Callable、Thread或队列时，我们使用AspectJ来自动传播工作流ID。

Aggregation and reporting：Retro不会像X-Trace或Dapper那样记录或转发单个跟踪事件，而只是在内存中聚合计数器。当一个资源被截取时，Retro确定与当前线程相关的工作流，并增加内存中的计数器，跟踪每个工作流的资源使用情况。

Batching：系统可能会将多个工作流的请求批量化为一个请求。在这些情况下，我们创建一个批处理工作流ID，以汇总批处理任务的资源消耗。组成的工作流报告他们对批处理的相对贡献（例如，事务的序列化大小），控制器将批处理消耗的资源分解给贡献的工作流。

Automatic resource instrumentation using AspectJ： Retro使用AspectJ来自动检测所有硬件资源和通过Java标准库暴露的资源。通过拦截文件和网络流上的构造器和方法调用来捕获磁盘和网络消耗。在线程与工作流相关联的过程中，CPU消耗被跟踪。对所有Java监控锁和所有Lock接口的实现者的锁定进行检测，而线程池则使用Java的Executors框架进行检测。唯一需要手动检测的是由开发者创建的应用级资源，如自定义队列、线程池或流水线处理阶段。

Resource library

主要捕捉以下资源

CPU
Disk
Network
Thread pool
Locks

Coordinated throttling

Retro被设计为支持多种调度方案，如各种队列调度器或优先级队列。在Retro当前的实现中，每个控制点是一个按工作流分布的令牌桶。线程可以从当前工作流的令牌桶中请求令牌，阻塞直到可用。队列可以延迟请求，直到相应的工作流的桶中有足够的令牌可用，才会被取消队列。对于一个特定的控制点和工作流程，策略可以设置一个速率限制R，然后（在幕后）按照观察到的吞吐量比例在所有的点实例上进行分割。 Retro跟踪新的控制点实例的到来和离开--例如，映射器的开始和结束--并在它们之间正确分配指定的限制。

Policies

实现了三种策略

Bottleneck fairness
Dominant resource fairness
Latency SLO

具体就没看了