Scaling Memcache at Facebook论文理解

原文地址：http://nil.csail.mit.edu/6.824/2020/papers/memcache-fb.pdf

体会

这篇论文读起来很有意思，设计体现了各方面的权衡，里面不仅考虑了分布式的CAP问题，也考虑到了计算机网络发包的机制和其他方面的内容，值得仔细品味。

读这篇文章的过程中也发现自己对于分布式体系概览不是很熟悉，RAFT和Memcache的应用范围划分不是很熟悉，另外写着写着发现自己对于K8S的应用范畴也不是很了解，没有梳理成体系，需要不断加深理解。

之后有机会得多看些企业内部各种技术框架，了解各个部分的意义。

本文有意思的点

lease、UTP/TCP传输机制、分布式锁机制，整个架构设计也很精巧

论文思路梳理

单集群（memcache原语、降低负载和延迟）->业务增长多集群（如何保证集群快速启动、保持集群信息一致性）

Introduction

Memcached是一个简单的内存cache组件，支持低延迟低成本的内存访问。这篇文章描述了Facebook如何基于memcache构造一个可以响应大量请求（98%读请求，2%写请求）的分布式key-value数据库（key-value数据库可以储存各种数据，视频二进制文件、图片、关注列表等）。

其中值得注意的是，集群进行了地理划分，相距很远。

OverView

没有十全十美，任何场景都能有突出表现的分布式系统。驱动这个设计方案的因素有如下两点：

1、人们更多消费内容而非创造内容（即读请求远多于写请求）。 

2、读请求获取到资源来自不同的底层设计，例如mysql、HDFS等。因此需要能够储存来自不同源点的cache plan。

Memcached很突出的一个特点是，他提供了非常简单的操作源语（set、get、delete）。简洁明了，这个特点也使其大受欢迎。（简洁性有时候对于一个算法，一个系统来说也很重要，比如Raft，比如Zookeeper原语）

query cache的方式

读请求：首先从memcache查询数据。如果cache里没有数据，就从后台的database获取数据，并把key-value pair更新到cache中。

写请求：首先对database进行修改，然后向cache发送请求，invalidate之前的旧数据。

这里值得注意的是，之所以选择删除cache而不是更新cache的key-value键值对是因为delete具有幂等性（多次执行对结果无影响），容错性更强。

另外工程师们还对开源的memcache进行了很多修改，例如：

1、令其能储存更多数据

2、在memcache基础上设计了一套封装配置、routing service、管理功能的系统。

FaceBook与这套系统共同成长，这个过程中也在不同阶段有不同的侧重点：

1、只有一个集群的时候，主要关注read-heavy workload和wide fan-out

2、在请求过多之后，修建更多FE clusters，开始关注data replication的问题（每个集群都得有对应的mecache）。

3、当在全球修建集群之后需要关注更多问题。

最后的architecture如下图所示：

最终设计将co-located的clusters构造成一个region，然后任命一个master region用来支持写请求并把数据更新给其他storage cluster（只有主集群支持写请求，其他的被动响应）。 

在设计上工程师们也对CAP进行了权衡，重点保障AP。即通过允许用户看到旧数据来避免后台压力过大（memcache主要限制的是stale 数据的时间不能太长，而非完全不能看到旧数据）。

In a Cluster:Latency and Load

首先考虑数千个