Memcache论文总结——Lec16

一、相关名词

1.mcrouter层

FACEBOOK提供了一个mcrouter层，CLIENT对所有请求构建一个DAG，找到可以合并发送的请求发送给mcrouter，让他来分发出去。
降低数据包率：如果直接将失效缓存消息发送会浪费网络资源，因此需要将缓存失效消息批量发送给每个前端集群中的mcrouter，再由mcrouter转发给集群内的服务器。
是memcache 客户端（sdk 与 proxy）的一部分，代理proxy被称为 mcrouter。

2.GUTTER SERVER

他们是一组IDLE的SERVER，用户使用他们只当MC SERVER挂了的时候。
系统设置了少量称为Gutter的机器来暂时管理不可用机器的键范围，Gutter中的数据有效期很短，这样避免了需要使缓存失效的操作。

3.mcsqueal

存储集群保存着最新数据，用户请求将数据副本写入到前端服务器。存储集群负责发送缓存失效命令，来保持数据的一致性。对数据产生修改的SQL会附上需要失效的mamcache键，应用更改之后由mcsqueal将缓存失效消息发送给各个前端集群中的服务器。
利用 DB 数据的更新日志来保证数据在不同集群间的最终一致性。

squeal/skwiːl/告密，尖叫声

4.remote mark

FB解决REGION间的主从不一致，通过"remote mark"
C1 DELETE()的时候，如果是主， 使用mcsqueal传输失效消息可以避免失效信息先于数据更新到达。（因为mcsqueal 这个daemon是监听DB的COMMIT消息）
如果是非主，当Web务器更新键值k时：
在从region , delete()时，这个K上写一个"remote mark"
如果C1 get()的时候，发现了这个标记，就去master那读，而不是自己的LOCAL DB。
随后去主region进行UPDATE，然后复制数据到从DB，这个时候这个标记会被清除。

二、当流量增长了如何SCALE 你的网站？

1.在最开始的时候我们搭建一个站点，可能就一台机器里面包含了WEB SERVER，Application和DB（如MySQL）。 DB就把数据存在硬盘里。application 去查询 db随后渲染HTML。当流量开始增长，你的PHP Application要消耗更多CPU，单机无法承受，这通常这就是他们所遇到的第一个性能瓶颈。所以，你所需要做的就是为你的PHP脚本提供更多的服务器资源。

2.我们转向了第二种网站架构—— 多个WEB SERVER， 一个共享的数据库。
用户大量增多，需要更多的CPU处理能力来执行PHP脚本。所以运行了一堆前端服务器（下图中的FE）,它们只负责运行和用户浏览器进行通信的web服务器。这上面运行着Apacheweb服务器以及PHP脚本，所有这些前端服务器都需要看到相同的后端数据。为了做到这点，这里你可以放一个数据库服务器（下图最右侧的MySQL）。流量增长，我们只需要加更多WEB SERVER直到DB成为瓶颈。
当使用一个服务器来运行MySQL时，它用来处理所有来自前端服务器对数据库的查询，更新，读取以及写入请求。如果使用两个数据库服务器，并将你的数据以某种方式分散到多个数据库服务器中时，情况就会变得更为复杂。你就需要关心是否要使用分布式事务，或者该PHP脚本应该通过哪种方式来确定它要和哪个数据库服务器进行通信。

3.大型网站的一种标准演变，下面要转向web架构3——水平扩容
数据根据SHARD KEY散落在不同的DB上。 APP 根据SHARD KEY去查询对应的DB（如下图第一个数据库服务器上保存的是key从a到g的相关数据,第二个数据库服务器上保存的是key从g到q的相关数据,以此类推）。 只要没有单个KEY是超级火爆的，负载就会被均匀的分散。

但是数据分片带来了额外开销：①需要对前端服务器上的软件进行修改让PHP代码知道数据分片相关的信息。②对于事务会需要用到两阶段提交或者一些其他分布式事务方案，速度很慢。
这种方案，成本高，速度慢，还会有热点问题。所以我们无须花大量的钱来添加另一台运行着MySQL的数据库服务器，可以在同一台服务器上面运行缓存memcached。在相同的硬件上，使用缓存每秒读取的数据量要比使用数据库多得多。
总结：为了更好的解决流量增长时的网络架构面对的db访问瓶颈，出现了memcached.
4.Facebook的架构
现在我们的架构变成很多WEB SERVER， 很多CACHE SERVER提供读服务，还有很多DB支持写。
在前端服务器和数据库服务器之间有一个缓存层memcached。当前端服务器需要去读取一些数据，它会往其中一个memcache服务器发送一个携带某个key的get请求。memcache服务器会去检查它内存中的一张表（大型hash table）中是否有这个key，如果有的话,它就会将对应的数据返回给前端服务器。
如果并未命中memcache服务器中的缓存，那么前端服务器就得将请求重新发送给相关的数据库服务器。为了之后的请求，前端服务器会发送一个put请求并携带它从数据库中所拿到的数据给memcache服务器。
（注：读——memcache, 写——数据库）

（1）问题：当读memcache miss时，为什么是前端服务器发送put请求写入memcache，而不是memcache在miss时，转发给db，并将db的响应缓存起来？
不能这样做的原因是，memcache就像是一个完全独立的软件，它对数据库一无所知。虽然我们经常将它和数据库放在一起使用，但我们无法将数据库的知识应用到memcache中。
更深层次的理由是，前端服务器会对从db得到的结果进行某种处理（它可能需要花几步来将结果转换为html，或者，它会从数据库的多行数据中获取结果，并将部分处理过的信息缓存到memcache中，以此来节省下一个要执行相同操作的reader所要花的时间）。所以，memcache并不理解前端服务器想看到哪些缓存数据，以及你是如何从数据库中衍生数据的。这些逻辑都是放在前端服务器中的php代码里的。
所以，从架构上来说，这是一个很不错的想法，但我们不能做这种整合，即让memcache和数据库之间直接进行通信，虽然这会让缓存一致性变得更为简单。
（总结：web服务器可能需要的并不是数据库中的原始数据，而是经过处理的html或整合后的结果，会向memcache中存储处理后的数据，所以不能直接由memcache与数据库交互来保存数据）

（2）问题：look-aside cache和look-through cache间的区别是什么？
look-aside cache的作用是，前端服务器会先查看数据是否存在于缓存中,它会从数据库中获取未缓存的数据。如果使用的是look-through cache，那么就会通过memcache将我的请求转发给数据库，让数据库来处理响应（即memcache与数据库有交互）。
（总结：数据同步时，look-aside cache是以前端服务器为中心，look-through cache是以memcache为中心）
memcache流行的部分原因是，它使用的是look-aside cache，让web服务器作为中间方来对memcache中的数据和数据库中的数据进行操作，即memcache不直接与数据库进行交互，通过web服务器来和数据库进行交互。

三、背景及业务特点

1.读多写少

与大部分互联网公司的读写流量特点类似，FB 的整体业务呈现出明显读多写少的特点，其读请求量比写请求量高出 2 个数量级 (数据来自于https://www.usenix.org/sites/default/files/conference/protected-files/nishtala_nsdi13_slides.pdf、 slides)，因此增加缓存层可以显著提高业务稳定性，保护 DB。

2.FB需求：

Facebook作为社交网络服务基础设施，需要满足：

• 近似实时通信；
• 实时聚合多个来源的内容；
• 读取/更新热点的共享内容；
• 可伸缩以处理billion级用户并发。

为满足以上需求，Facebook从单机(memcached)、集群(cluster)、区域(region)、跨区域(cross-region)这4个方面以bottom up的方式讲述他们是如何scale的。

3.之前情况

在使用缓存层之前，FB 的 Web Server 直接访问数据库，通过 数据分片 和 一主多从 的方式来扛住读写流量：

但随着用户数数量飙升，单纯靠数据库来抗压成本高，效率低。

四、简介

1.Scaling Memcache at Facebook是Facebook团队2013年的一篇论文，讲述Facebook如何使用开源的memcached构建分布式内存KV集群，使用memcache来处理海量的工作量（这里指的memcache和下文的memcacheD，说的都是运行着memcacheD的服务器)。

这篇paper中存在着很多可以借鉴的经验,它里面并没有任何新的概念或者想法或者技术之类的东西,当那些公司试着去构建具备高负载能力的基础架构时，他们就会去使用这篇paper中提到的这些方法。

2.Memcached是一个简单的内存cache组件，支持低延迟低成本的内存访问。

3.Memcached提供的是一个纯内存的哈希表访存服务，支持键值对的存储模式，提供的基本接口为put, get, delete。

五、FaceBook的架构

1.在进入正文之前，需要厘清以下概念（见Figure 2）：

• memcached：开源memcached技术，在文中指运行时的单台实例；
• cluster：指多台memcached组成的最小单位的集群，memcached之间相互不通信，由client端使用consistent hash将数据分布到多台memcached；
• region：多web server集群和多cluster集群组成frontend clusters，共享一个storage cluster组成一个region；
• cross-region：多个region，每个region分布在不同地理位置。只有一个region的storage
  cluster是master角色，其他的是slave角色，从m