memcache@facebook

memcache@facebook演讲者是 Marc，FB资深架构师，这个PPT讨论了FB如何通过memcache来进行scale来承载高流量。这篇PPT相当有水准，很多思路值得学习借鉴。 由于未参加Qconf，只是从ppt中分析揣摩，难免有不准确的地方还望指正。

Facebook的规模是400m活跃用户

• 每天有超过60million的status updates，平均每秒694次。
• 每月有超过3billion张照片的上传，平均每秒上传23张。
• 每周有超过5billion的内容碎片信息(web links, news stories,blog posts, notes, photo albums, etc.)的分享，平均每秒8k次
• 网站上平均每个用户有130个好友
• 50billion的好友关系图谱数据
  

Infrastructure

• 成千上万的服务器分别部署于美国东西海岸的多个机房(包括Web servers、DB servers、Memcache Servers、Other services)
  

Memcache的状况
所有memcached服务器每秒承担400m次gets请求和28m次sets请求
cache了超过2T的items，超过200T bytes
网路I/O:receive 60GB/s transmit 120GB/s

单台memcached服务器每秒承担80k gets和2k sets
存放200M的items
网络I/O:receive 9.7MB/s, transmit 19MB/s。

Memcache Rules of the Game

• 从 memcache 获取对象
• 如果 miss ，就直接从数据库获取并且将对象 set 到 memcache 中
• 更新数据库中的一条记录，直接从缓存中删除这个对象
• 在 memcache 中存放的对象都是比较简单的对象，没有派生继承之类的对象
• 每一个 memcache 对象直接与数据库中的数据进行映射。也即是说，FB他们绝大多数场景下都是把数据库当做Key/Value Store在使用。
  

Pools and Threads
不同的对象有着不同大小和不同的访问模式。 facebook 建立了 memcache 池 ( 本人认为用 region 这种说法可能更为贴切 ) ，以此来分隔不同类型的对象以提升缓存性能和内存利用率。

Phatty Phatty Multiget (notes)

• PHP runtime 是单线程和同步的。
• 要想性能变得更好，得要让数据支持并行读取，这是必须得要让 memcache 以并行的方式获取请求。
• 当初 facebook 只是在 PHP 上使用 polling I/O 的方式。
• 之后他们写了一个 PHP 的 C 扩展，使其支持真正的异步 I/O 。
• 上面的这两个做法所带来的结果是通过并行机制来降低延迟。
  

Pools and Threads (notes)

• 隐私对象虽小，但命中率很差
• 用户 个人信息 较大，而且具有良好的命中率
• facebook 他们将不同的类的对象分散到不同的 memcache 服务器的不同的池中。
• memcache 原本就是一个经典的单线程 的UNIX 守护进程
• 为了 让memcache更好的榨取服务器 的效能 ，在 memcache 服务器上开了 4 个 memcache 实例 ，每个实例占用 1/4 的内存。
• 但也带来了另外的麻烦，比如每个连接数增长了 4 倍
• 4 倍的元数据开销
• 采用 多线程服务
  

Connections and Congestion (notes)

• 当增加 web 服务器 ，与memcache box的连接也会增长。
  • 每个网络服务器运行50-100 PHP 进程。
  • 每个 memcache box 有 超过 100 万 + TCP 连接。
  • UDP 可以减少连接的数量。
  • 当添加用户和功能， 也就意味着每一次的 memcache 的 multiget 操作所传入的 keys 也在不断的增加。
  • 受欢迎的名人和 团体。
  • 开放 平台和FBML 。
• 上面这一系列的场景都会导致 拥塞。
  

Serialization and Compression

• 1 千个 PHP 序列化的对象
• 修改为他们自己设计的序列化
• 基于 thrift 的格式来进行序列化
• 性能提升 3 倍
• 与先前的内存占用相比，变小了 30%
• 采用 gzcompress 来序列化字符串
  
  

Multiple Datacenters (notes)

• 早些时候FB是两个数据中心。其中一个中心提供对外服务，另外一个中心并不对外服务，只做灾备。说白了还是一个单数据中心的架构
• 事实上，随着FB的快速成长， 单数据中心无法再满足业务的需求。
  • 但即便是这样 FB仍然还是采用了单Master的数据库层次结构。更多是借助于缓存以及对数据库的Sharding来分摊压力。
  • 对于memcache还是记住那个游戏规则，数据一旦更新，删除所有层级与之相关的缓存。
  • 同时FB通过自行研发的mcproxy来复制多套缓存，以此来抵挡更多的读操作。
    

Multiple Regions (notes)

• 早期系统只部署在美国西海岸， 由于FB是面向全球的， 这就导致了美国东海岸和欧洲用户的延迟非常严重
• 因此，FB在 Ashburn VA 部署了slave数据库
• slave 库通过追踪 master 库的 binlog 来进行同步
• 数据同步的过程中肯定会有延迟，同时也会引入一些资源竞争的情况
• 为解决这个问题，FB仍然是通过mcproxy来解决这个问题
• 解决的思路是，在进行 mysql 更新和插入的操作中加入了 对memcache进行 删除的程序逻辑
• 在东海岸也通过 mcproxy 与 slave mysqld进行集成，在其中 加入一个线程来进行同步后的缓存删除清理工作
  

Replicated Keys (notes)

• 随着像病毒式的groups和applications的不断演进， 从而使得一部分的数据访问频率极高(ppt中称之为Hot key)。
• 对于这种热门数据，他需要比通常的单台memcache服务器处理更多的gets操作。
• 但是前面提到的memcache的游戏规则，一旦更新，删除所有相关的缓存。
• 意味着有更多的请求会打到数据库。同时也意味着这台数据库会执行更多的查询。
• 最终会导致数据库被打死，从而使得与之相关的 groups和applications完全当掉。
• 解决的思路是创建Key别名，并将此分发到不同的服务器上 ，用更多的服务器来分摊请求的压力。
• 再将热门的 keys 分发到所有的 web 服务器上，并存为localcache。
• 每一个 web 服务器 也都 匹配一个 gets 的别名
• get key:xxx => get key:xxx#N .（没看太懂，以我自己的理解，是不是 key:xxx#N就是key:xxx的副本，key:xxx#N表示本地缓存，key:xxx表示在memcache中的缓存，数据也都是一致的，我估计FB有一个缓存层在统管localcache、memcache等各种类型的cache）
• 遇到更新操作的时候，每个web服务器删除所有的别名缓存以及原有memcache中的缓存。

(最后这两条纯属YY，可能有不正确的地方。)


New Rule

• 如果键是热门数据，那么就采用别名的机制来进行读取
• 在更新的时候删除所有的别名缓存
  

Mirrored Pools (notes)

• 随着FB的memcache层的成长，keys/packet的比率也在逐渐下降。
  • 先前从1个服务器获取100个keys，只需要发送一个 packet （ 100 keys/ 1 server = 1 packet ）
  • 随着memcache层的增大,100个服务器，那么获取100个keys最糟糕的情况是需要发送100个 packet （ 100 keys/ 100 server = 100 packets ）
  • 这网络开销多了去了
  • memcache 服务器每次请求的内核中断也多了去了

(看不懂了，直接上原文了%>_<%)

• Confirmed Info - critical account meta-data
  • Have you confirmed your account?
  • Are you a minor?
  • Pulled from large user-profile objects
  • Since we just need a few bytes of data for many users
    

前面有个动画，看不了，省略号.......
Hot Misses (notes)

• 再回忆一下缓存的游戏规则
• 更新就删除
• miss了就查库，然后再set到缓存
• 当这个对象是非常poplar的，查询的也会变得频繁，甚至会打死数据库
• 流量控制！
  

可以通过下面这个Rule来做到流量控制
Memcache Rules of the Game (再给Memcache Rule of the Game添点料)

• 针对于那些热门数据, 一旦miss在进行db查询前抢先加入一个互斥锁。
• 在memcache上针对于这个对象通过add协议加入一个互斥标记。
• 比如这个对象通过key:xxx来获取，如果miss，那么就add一个key:xxx#mutex的缓存(key:xxx => key:xxx#mutex)
• 如果add成功就执行query操作
• 如果add失败(因为mutex缓存已经存在) 回退并重试
• query操作执行成功后删除mutex缓存
  

Hot Deletes (notes)

• FB也尚未走出困境
• 在频繁更新对象的场景下，Cache mutex这招也不管用了。
• 就像viral groups and applications中的membership列表、walls
• 每个进程刚刚才创立一个互斥对象，发现马上这个对象又立即被删除了。
• ...又搞了一次
• ...又搞了一次
• ...虚脱了！
  

Rules of the Game: Caching Intent
翻译出来总觉得别扭 ，直接看英文吧！

• Each memcache server is in the perfect position to detect and mitigate contention
  • Record misses
  • Record deletes
  • Serve stale data
  • Serve lease-ids
• Don’t allow updates without a valid lease id
  

Shaping Memcache Traffic

• mcproxy 好比是路由器
  • 通过mcproxy进行接入控制
  • 通过mcproxy来解决 跨数据中心的传输互联问题
    

Cache Hierarchies

• 通过mcproxy 来对冷集群进行预热以便让缓存充满后再切换到这堆集群上。
• 对没有缓存的集群进行代理(Proxies for Cacheless Clusters)

对mcproxy感兴趣的童鞋可以去看看moxi。与memcache proxy特性比较类似。
moxi => memcache proxy

Big Low Latency Clusters

• Bigger Clusters are Better
• Low Latency is Better
• L 2.5
• UDP
• Proxy Facebook Architecture
  

Why Memcache Works

• 一句话，通过拆分降低延迟，也会带来更好的用户体验
• 充分利用memcache中提供的一些健壮的原语
• 做好key与server的映射规划，不同的类型的对象分别存放到不同的缓存服务器上(key-to-server mapping)
• 尽可能用并行的方式来获取数据(parallel I/O)
• 流量控制(flow-control)
• 传输设施的构筑，引入mcproxy类似的解决方案来解决一系列的跨机房跨地域的问题。(traffic shaping)
• scaling问题所涵盖的领域太广，具体场景具体分析，不排除会使用一些特设或临时的(Ad-hoc)解决方案