Facebook如何使用Memcached每秒处理数十亿请求
内容提要
Dropbox开发了zxcvbn，一个计算密码强度的开源库。Facebook通过增强开源版本的Memcached构建了一个分布式键值存储系统。Facebook的架构包括区域、前端集群和存储集群。他们通过使用并行请求和批处理以及使用UDP进行获取请求来降低延迟。他们通过使用租约来防止过期数据和群集效应来减少负载。他们通过将请求转发到其他集群和使用备用机器来处理故障。他们在集群和区域内部以及跨区域管理失效。他们在不同区域之间保持Memcache和持久存储的一致性。他们通过自动哈希表扩展、多线程服务器架构、专用UDP端口和自适应分配器来优化单个Memcache服务器。
延伸解读
租约机制：如何将数据库峰值查询降低92%
Facebook通过租约机制解决了缓存中的两个关键问题：过期数据和群集效应。当缓存未命中时，Memcache向客户端发放一个与特定键绑定的64位令牌，客户端必须凭此令牌才能设置缓存值。如果数据在设置前已被无效化，Memcache会拒绝该请求，从而防止过期数据被写入。对于群集效应，Memcache限制令牌的发放速率（例如每5秒一次），其他请求会收到等待重试的响应，避免大量请求同时冲击数据库。这一机制将数据库的峰值查询率从每秒17,000次降低到1,300次，显著减轻了后端负载。
Gutter机器：小规模故障的应急方案
在Facebook的Memcache集群中，当少量主机因网络问题不可用时，传统的重新哈希方法可能导致高流量键集中到少数服务器，引发级联故障。为此，Facebook在每个集群中预留约1%的Memcache服务器作为Gutter机器。当客户端无法从原服务器获得响应时，会向Gutter池发送请求。如果Gutter池也未命中，客户端会查询数据库并将结果存入Gutter池，以便后续请求可以快速获取。Gutter条目会快速过期，无需显式无效化。虽然可能返回稍旧的数据，但这一权衡保护了后端数据库，确保了系统可用性。
跨区域一致性：远程标记如何避免脏读
在Facebook的多区域架构中，主区域处理写操作，次要区域提供只读副本。当用户在次要区域发起写请求时，写操作会转发到主区域，但复制延迟可能导致次要区域的缓存中存入旧数据。为了解决这个问题，Facebook引入了远程标记机制。当客户端在次要区域更新数据时，会为该键设置一个远程标记，并删除本地Memcache中的对应数据。后续读请求如果发现缓存未命中且存在远程标记，就会直接查询主区域，而不是本地副本。这虽然增加了延迟，但显著降低了读取到过期数据的概率，体现了Facebook在延迟与一致性之间的权衡。
Q&A
Facebook是如何增强Memcached以处理大量请求的？
Facebook通过构建分布式键值存储系统Memcache，增强了Memcached，支持并行请求和批处理来降低延迟。
Memcache在Facebook架构中扮演什么角色？
Memcache作为查询缓存和通用缓存，帮助减少数据库负载并提高数据访问速度。
Facebook如何管理Memcache中的数据一致性？
Facebook通过在不同区域之间保持Memcache和持久存储的一致性，使用远程标记机制来处理数据更新。
Facebook是如何减少Memcache的延迟的？
Facebook通过使用并行请求、批处理和UDP协议来优化网络通信，从而减少Memcache的延迟。
在Memcache中，Facebook如何处理故障？
Facebook通过将请求转发到其他集群和使用Gutter机器来处理小规模故障，确保系统稳定性。
Facebook在Memcache服务器上进行了哪些优化？
Facebook实施了自动哈希表扩展、多线程服务器架构和自适应分配器等优化，以提高Memcache服务器的性能。
