抛弃DRAM、拥抱闪存，Facebook重做Memcached-CSDN.NET
抛弃DRAM、拥抱闪存，Facebook重做Memcached
发表于2013-03-07 10:44| 2929次阅读| 来源Facebook| 9 条评论| 作者Facebook
FacebookMemcachedMcDipper闪存
摘要：社交巨头Facebook的“冷存储”战略又向前迈进了一大步，前进的指导方针仍然为闪存。“挨刀”的则是Facebook“老臣”Memcached，不过这次不再是以往几倍几倍的提升速率，而是直接将其炼化为闪存版。好吧，下面来初窥一下Facebook的新键值缓存系统McDipper。
上回说到社交巨头Facebook苦衷，因其不能像一般企业或机构将“冷数据刻录成光盘”，不得不向一些硬件供应商寻求廉价闪存去存储这些不被频繁访问的数据。如今Facebook为了进一步的缩减成本，更是重写了Memcached，使其能够匹配Facebook的“冷存储”战略；新的分布式缓存系统被命名为McDipper，对比昂贵的DRAM，新系统基于价格低廉的闪存。那么了解McDipper的同时，首先必须了解Memcached在Facebook的“非人经历”：
Memcached，高性能的分布式内存对象缓存系统，用于动态Web应用以减轻服务器的负载。通过在内存中缓存数据和对象来减少数据的查询次数，从而达到降低负载并提高吞吐量的双丰收。Memcached使用哈希图来储存键值。Memcached由Danga Interactive开发，而被开源以后就为多家公司所用。然而Memcached到了Facebook的手里明显“凶猛”了很多：每秒处理20万UDPS请求，平均延时只有173微妙（虽然总吞吐量一度达到每秒50万UDP，但是由于延时太高未被采用），对比之前的5万每秒UDP无疑是疯狂的提升。
然而Facebook并没有因为Memcached的“悲惨遭遇”而停止向它动刀，3月5日Facebook在其公司日志上宣布已将其重做为基于闪存的McDipper。
以下为译文：
修改原因和动机
Facebook一直使用Memcached作为其MySQL的缓冲，然而DRAM实在太贵了；为了保留Memcached的高效，Facebook不得不将它转变成闪存版本的McDipper，而闪存也同样具有以下优势：
20倍内存的容量
虽然没有内存高效，但是每秒仍然支持上万的操作
所以为了迎合Facebook的廉价“冷存储”战略，Memcached理所当然的“转世”为McDipper。
McDipper，兼容Memcache协议；它的设计初衷为：更好的利用闪存然后取代Memcached，投入使用已接近一年之久。
McDipper存储层
使用Checksum对每个操作进行验证，从而保护McDipper中的所有数据结构。缓存的替换策略是可配置的，可以选择FIFO（先进先出）或者LRU（最不常使用）两种。取决于的你负载，可以使用Bloom Filter（布隆过滤器）去避免不必要的读操作；对交换计算进行压缩以获取能力上的提升，使用加密防止驱动器丢失或被窃取，通过不同等级的限制对存储利用率进行优化。
重做Memcached
不幸的是，在Memcached中实现get、set和delete这些等价操作并不是想象的那么简单。而当许多连接与Memcache池进行会话时，将产生很多问题，其中大部分是持久化和性能引起的重复问题。需要重点对待的则是值之间的竞争问题。
简而言之，当你向后备存储器中写入新值时，你需要一个让Memcached中旧值无效的方法。其中一个途径就是简单的给Memcached设置新值，然而这种方法在快速做二次修改的时候将会失效，因为第二次新加入的值可能会比之前那个值先到达Memcached实例。基于这个原因，Facebook使用删除失效法，并且在需要的时候等待reader进行重新注入。当然，这种方法仍然存在竞争（虽然几率很小），如下所示：
旧的设置比删除后一步完成，这样仍然会导致错误的值
为解决这一问题，Facebook使用了一个删除延时，包含了一定等待时间的特殊删除操作。Memcached会阻止任何新的值被写入这个key，直到删除作业结束。这意味着旧的设置必须在相应删除作业完成几秒后才可以被提出，这样缓存的整体一致性就会得到保障。
使用删除延时阻止过期设置
为了实现删除延时，你必须先确认无延时存在然后再对值进行写入。如果你只是简单的使用一个查询然后接着设置，在下面的情况发生时你将陷入窘境：延时建立在你查询它是否存在之后，并且在你设置旧的值之前。为了消除这个竞态条件，Facebook实现了另一个方法read-modify-write。这个方法使用了一个泛函谓词（函数指针），将旧值映射到新值上。通过这个基元，Facebook同样还建立了余下的Memcache接口，它们提供了很多的原子操作（increment 、append等等）。
基于它的发展，Facebook给McDipper部署了几个大型的封装、低速请求池，大幅度的减少了一些池中90%左右的服务器数量，而90%请求响应延迟仍然维持在亚毫秒级。
将McDipper应用到Facebook图片基础设施
McDipper在Facebook过去一年内最重要的应用就是服务Facebook的图片基础设施。而在终端用户访问Facebook CDN（内容发布网）以及Haystack（小文件存储软件）时，一般会通过两个McDipper层。通往Facebook面向世界的HTTP负载均衡器的HTTP和HTTPS请求将被转换成memcache请求，然后转发给McDipper。当这些请求丢失，它们就会被转发给Facebook一个图片源的负载均衡器，同样拥有一个类似配置的McDipper实例。如果源缓存同样丢失，请求将会被转发至Haystack系统。
为了优化图片用例，Facebook给McDipper运行的bucket配置很小的体积，并且将这些bucket连接到内存中。所有的图片都被存入闪存，而这些bucket相关哈希元数据都被放入了内存。Memcache协议的使用让Facebook可以通过这个途径快速的利用一些已有的软件（Nginx以及Srcache），同时还能够利用Facebook一些已有的堆栈，让其可以将连接直接转入HTTP负载均衡器。
Facebook CDN可以每秒处理超过150GB（更准确的话，应该是每分钟10TB）的McDipper缓存转发，只是用很小的服务器集群。
关于开源：
在看完McDipper的介绍，相信有很多人与笔者一样在关心Facebook是否会开源McDipper。在其官方页面中同样有网友问及了这个问题，遗憾的是并没有得到Facebook的正面答复。然而据Facebook以往的开源史来看，McDipper的开源还是可以期待的。
原文链接： McDipper: A key-value cache for Flash storage （编译/仲浩 审校/王旭东）
欢迎 @CSDN云计算 微博参与讨论，了解更多云信息。
本文为CSDN编译整理，未经允许不得转载。如需转载请联系market@csdn.net