Pinterest 大规模缓存集群的架构剖析

随着越来越多的用户到 Pinterest 寻求灵感，Pinterest 核心基础设施系统的需求增长的比以往任何时候都快。我们的核心存储系统之一是位于许多微服务和数据库前面的分布式缓存层。它处于 Pinterest 基础架构技术栈的底部，负责吸收由用户增长驱动的绝大多数后端流量。

Pinterest 的分布式缓存集群建立在 AWS 的 EC2 实例上，由数千台机器组成，缓存了数百 TB 的数据，高峰时，每秒可处理 1.5 亿个请求。该缓存层通过降低整个后端技术栈的延迟，来优化顶层性能，并通过减少昂贵的后端所需的容量来提供显著的成本效率。

本文中，我们将对支持 Pinterest 的大规模缓存集群的架构进行深入的技术研究。

应用数据缓存

每个对 Pinterest 的 API 请求都会在内部根据技术栈分发到复杂的 RPC 树，并在完成其关键路径前会涉及数十个服务。这可能包括查询关键数据（例如 Pinterest 的图片和收藏板）的服务，推送相关图片的推荐系统和垃圾内容检测系统。在这些服务中，只要其输入数据可以被唯一键值表示，就可以将该离散的查询单元的结果缓存在临时存储系统中，以便将来重用。

在 Pinterest，分布式缓存层的最常见用途是通过后备语义（look-aside semantics）来存储这类中间计算的结果。这使得缓存层能吸收一大部分流量。如果没有缓存层，这些流量会流向涉及复杂计算和昂贵存储的服务和数据库。凭借着毫秒级的尾延迟（tail latency），以及极低的单位请求基础架构成本，这个分布式缓存层提供了一个高性能低成本的后端扩展机制，以满足 Pinterest 不断增长的需求。

简化版的 Pinterest 的 API 请求生命周期：经过主要 API 服务，其依赖于后端以及分布式缓存层

通过提供分布式缓存层即服务，应用开发人员可以专注于实现业务逻辑，而不必担心分布式数据的一致性、高可用性或者内存容量。缓存层用户使用通用的路由抽象层，以确保应用程序具有容错性和一致的数据视图。此外，缓存服务端集群可以独立于应用层横向扩展，从而透明地调整内存或吞吐量，以适应资源使用情况的变化。

分布式缓存的骨干：Memcached 和 Mcrouter

Memcached 和 mcrouter 构成了 Pinterest 分布式缓存基础架构的骨干，并且在 Pinterest 的存储基础架构中起着至关重要的作用。 Memcached 是由纯 C 语言编写的开源且高效的内存键值存储。Mcrouter 是应用层的 Memcached 协议代理，位于 Memcached 集群的前面，并提供强大的高可用性和路由功