Scaling Memcache at Facebook读后感

       这篇文章主要介绍了facebook如何在他们的系统中使用memcached。facebook搭建了世界上最大的memcached集群，用于支撑其每秒数十亿的请求，存储数万亿的键值对。尤其是在如何增强系统的可扩展性方面。

      社交网络有如下几个特点：（1）实时性（2）即使整合多方面的信息（3）访问和更新受欢迎的共享资源（4）可扩展性。

      性能，效率，容错性，一致性和可扩展等特性在特定规模下实现难度是不一样的。

     整个系统的设计是基于两个前提的。（1）读的频率远高于写（2）后端存储数据的多样新，包括数据库，hdfs以及后端服务。正是因为1所以缓存才是有意义的，2使得我们需要一个更灵活的缓存策略。

                                                                   图1

     我们依靠memcached来减轻数据库读的压力，读请求的流程：先读缓存，缓存不存在在读数据库，然后将结果放到缓存里面。写请求先写数据库，然后将删除缓存里面的旧数据。将缓存层从持久层独立出来可以方便在负载变化的时候系统各层之间的动态调整。如图1。

     memcached只是一个运行在单个机器上面的内存哈希表，不需要机器之间的协作。facebook开发了一整套从配置，整合再到路由，使得memcached适配分布式系统。

                         图2

       一个集群的时候，读压力和频繁的缓存失效是主要的关注点。多个集群的时候数据副本是关注点。图2是facebook最终的系统架构图，将多个地理位置相近的组成一个region,另外指派了主region用于更新非主region的数据。

       将读取老数据的可能性和请求的响应概率作为一个可调的参数。在读取一部分老数据和减轻后端压力之间作一个balance。

      延迟和负载

       1、延迟

        存储的值在memcache中通过一致性hash分布，因此一个请求可能需要web service和许多的memcached server交互，尽管每个之间的交互时间可能很短。某个节点可能会成为瓶颈，可以通过数据副本来缓解瓶颈，但是着会导致内存不够用。

       降低延迟主要依靠memcached的客户端，即web server。客户端维护者可用的memcached列表，可以通过额外的配置管理系统实现。

      通过DAG(有向无环图)展示数据之间的依赖，从而最大化可以并发获取的数据量。

      我们将复杂性放在无状态的客户端而不是服务端。使得服务端更加关注于性能。同时客户端的无状态能加快软件的迭代，减轻部署复杂性。客户端通过独立的mcrouter路由将请求发到服务端。

       get请求使用UDP,set 和delete使用TCP,UDP的无连接减少网络开销，客户端将在网络中被丢弃的和乱序的封包都认为是错误，没有任何的恢复机制。客户端将get错误当作是cache miss,但是web server在查询了数据后跳过将数据缓存到memcache中，这个主要是出于避免额外的开销，在一个可能出现高负载的网络或者是服务器。

         2、拥塞控制

        类似于TCP的拥塞控制，维护一个滑动窗口，随着请求的响应而增加。这个窗口是针对访问同一个memcached服务端的所有请求，tcp只能针对单个流。

        当窗口值过低值，client需要更多组的请求，会增加请求时间，端口过大会导致client出现错误的几率增大。