Scaling Memcache at Facebook 阅读笔记

这篇笔记是对于https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update.pdf

这篇文档的阅读记录，文中按照“延迟和负载” “区域内机制” “区域间机制”等三个方面对于Facebook的缓存系统进行了一个介绍，但是内容的排布让人难以一下理解其系统的原本面貌，在此做读书笔记，按照自己的理解对于文中的内容和机制进行整理，以期一览其大概

 

总览

上图是我在读了文章之后对于整个缓存系统的理解，其中每个标号为后续会讨论到的步骤：

1. FaceBook的基本架构，Front-End集群
2. 在同一个Region中的数据分布
3. 在web server数据存取的具体操作
4. mcrouter的工作模式
5. Memcache  pool是如何组织的，怎么分
6. 处理在缓存查询期间发生的错误的问题
7. region之间的memcached server share的作用
8. 冷集群启动的热集群依附
9. 读写本地DB的时候是如何使得缓存值更新或者失效的
10. 按照区域划分的时候写的是从库怎么办 remote marker机制的作用

 

FaceBook web系统的基本架构

   首先在第一个部分描述一个场景前提，FaceBook这个项目其实和微博或者是朋友圈的项目有非常大的类似之处，就是读请求远远大于产生的写请求，并且写请求的生效实时性并不是要求很高，即使发布一个心情或者消息在几秒之后才能生效也是一个在容忍范围内的故事。

    作为FaceBook这么打体量的一个全球性提供服务的公司来说，必然会在世界各地都部署足够的服务，以便于用户就近访问数据，所以整个项目的架构基础就是按照区域进行部署web server

    在按照区域进行web server部署的这么一个大前提下，为了能够让web server提供足够快的服务，自然而然缓存和DB数据也都是要跟着web server进行全球部署，所以在整个FaceBook声称的区域Region中包含以下三个基本内容：

1. Web server (web 服务)
2. Memche (缓存服务)
3. DB (数据库服务)

   其中，一部分的web server和一部分的memche则组成一个可能以数据中心也可能是机房为单位的这么一个Front-End Cluster面向用户提供服务，而多个同一区域的Front-END cluster访问同一组的DB存储集群服务

 

Region中的数据分布

     在图中可以看到，数据被存储在多个DB中，并且有多个memche进行缓存，所以其中的数据必然是按照一定的规则进行了分布式的存储，不然每个一个服务能够单独承载这个级别的数据。

     而其数据分布存储的规则则是由提供给web server使用的client依赖mcrouter，在client中提供数据分片，请求合并，容错超时控制等等功能

     但是，由于缓存数据往往存在热点的问题，并且存在一部分冷数据的问题，所以在缓存中，其数据并非像传统的分库分表那样。在缓存中部分热数据为了降低负载，会将负载分发到更多机器上，而部分冷数据可能由于数据使用量过小，可以让多个同一Region内的Front-Cluster来分享同一个memche server

 

Web server的数据存取方式

基础对于web server的大概缓存使用方式和其他地方的并无差别，基础逻辑如下图