Pinterest 推出其下一代异步计算平台 Pacer，用以取代旧的解决方案 Pinlater。随着公司的发展，Pinlater 在伸缩性和可靠性方面面临着挑战。新的架构使用 Kubernetes 来调度作业，使用 Apache Helix 来进行集群管理。
Pinterest 之前构建了一个异步作业执行平台Pinlater，并在几年前将其开源。Pinlater 已在生产环境中使用了多年，并支持许多关键的功能领域。Pinterest 在AWS EC2上运行了几个 Pinlater 集群，每分钟处理数百万个任务。
Pinterest 软件工程师Li Qi和Chen Zhihuang解释了促使他们构建新平台的动机：
随着 Pinterest 在过去几年的增长和 Pinlater 流量的增加，我们发现 Pinlater 存在许多局限性，包括伸缩性瓶颈、硬件效率、缺乏隔离性和可用性。我们在平台方面也遇到了新的挑战，包括那些影响我们数据存储吞吐量和可靠性的挑战。
基于他们使用 Pinlater 的经历，团队意识到他们不可能在现有架构中解决所有已知的问题，于是他们决定构建下一代平台。
新的架构 Pacer 包含了一个无状态的Thrift API 服务（与 Pinlater 兼容）、一个数据存储（MySQL）、一个有状态的脱队列代理服务（Dequeue Broker），以及在Kubernetes上运行的作业执行 Worker 池。Apache Helix（带有Zookeeper）被用来将作业队列分区分配给脱队列代理。
Pacer 架构（来源：Pinterest工程博客）
脱队列代理是一种有状态服务，负责从数据存储中预取作业队列数据并将其缓存到内存中，以减少延迟和隔离入队列和脱队列的工作负载。每个脱队列代理分配到一组作业队列分区，因此可以独占获取和执行作业，从而避免出现争用的情况。Kubernetes 为每个作业队列提供了一个专用的 Pod 池，消除因不同作业类型对资源倾斜消耗所带来的影响。
新的脱队列和执行模型缓解了 Pinlater 所遭遇的问题，包括在从热点分区获取数据时避免扫描所有分区或减少锁的争用。此外，它支持按照排队顺序（FIFO）的方式执行作业，前提是为作业队列配置单独的分区。
新的架构需要给脱队列代理实例进行独占式队列分区分配，与Kafka
消费者主题分区分配类似。Pinterest 的团队选择使用 Apache Helix 来实现这个功能。Apache Helix 提供了一个通用的集群管理框架，用于给集群内的脱队列代理进行分区分配。Helix 使用 Apache Zookeeper 实现嵌在脱队列代理实例中的 Helix 控制器和 Helix 代理之间的资源配置通信。
用 Apache Helix 和 Zookeeper 协调脱队列代理（来源：Pinterest工程博客）
Helix 控制监控加入和离开集群的脱队列代理实例，以及对已配置的作业队列做出的任何变更，如果发生变更，它将重新计算理想的队列分区与代理分布。在最新的分区分配被保存到 Zookeeper 之后，各个代理实例就会更新它们的内部状态，并从它们负责的队列分区中获取数据。
