Memcache架构新思考

2011年初Marc Kwiatkowski通过Memecache@Facebook介绍了Facebook的Memcache架构,现在重新审视这个架构,仍有很多方面在业界保持先进性。作为weibo内部数据处理量最大,对数据延迟最敏感的部门,基于本厂2年多来对mc的使用心得,我在本文总结对MC架构的一些新思考。

1. Memcache使用中的雷区

通常你可能考虑不到,但又隐藏在某处等着你踩的称之为“雷”。

带宽和连接数

Memcache具有很高吞吐能力,Memecache@Facebook中介绍Memcache支持8万/s读和2万/s写,在weibo内部我们通常认为单个Memcache实例支持7w/s读,2w/s写是安全的。和Facebook一样,为了充分榨取服务器性能,我们会在一台物理机上部署多个Memcache。为了确保Memcache的正常工作,我们通常会通过定期执行MC stats命令来对内存使用量,踢出率,命中率等进行监控。比如微博早期监控中就包括如图所示的这些内容,


Memcache架构新思考
 

这些监控中我们最重视的往往是内存使用量和命中率。但随着前端服务不断增加和cache层不断扩容,单台缓存物理机上的连接数,带宽都成为新的瓶颈。因此必须重视对带宽和连接数的监控。Memecache@Facebook中介绍单台MC服务器可支撑10w连接。

Hot Key

Hot Key通常不常见,但Weibo和Facebook都遇到这类问题,简单的讲就是在大并发下,有大量的请求到同一个在MC中不存在的资源,然后全部read through到后端数据库,把数据库读跨。具体方法请见TimYang的博客:http://timyang.net/programming/memcache-mutex/,同时后面的讨论也很精彩。不过我查阅大量微博代码却没有发现有使用MC mutex,也就是说Hot Key是个不常见的问题,一个不容易踩到的雷。

Memcache Client

2. Memcache集群是否支持线性扩容?

扩容问题之一:如果不降低命中率?

扩容Memcache不降低命中率,好像在高速路上给汽车换轮胎。

我们通常从课本上学到的是,前端采用一致性Hash,逻辑节点达2^32个,物理节点扩容也不会导致大量cache命中移动。一致性Hash足以应对大多数场景,但在微博业务中,每秒超过十几万次读,及时下降1%的命中率也会直接读跨数据库,因此我们的要求是扩容不能降低命中率。为达到该目的,我们把水平扩展,变为垂直扩展,即通过多层Cache解决扩容而同时不降低命中率的问题。


Memcache架构新思考
 另外一个好处是,新加入的cache层无需预热,当线上服务出现意外高峰时,可以立刻投入使用。

扩容问题之二:Memcache集群具备水平扩展性吗?

随着缓存层的增长,数据被分散到更多缓存服务器上,获取相同信息需要发送的网络包的数量也在不断增长。比如,只有一台缓存服务器时,由于操作系统网络层发送缓冲区的设计,get 100个key的数据可以在一个IP packet中传输,结果可以也可以在一个IP packet中获取。但当有100台缓存服务器时,获取100个key的数据就有需要向100台服务器发送100个IP packet(假设100个数据均匀的分布在100台物理机上),相应的内核中断也显著增加。

因此,我不认为Memcache集群在这个概念下具备水平扩展能力。但通常我们通过划分不同数据大小的缓存池控制Memcache集群的大小,而且随着96G或以上大内存服务器的广泛使用。即便在微博这个场景下,12台服务器一组的缓存就已经非常大规模的了。

3. Memcache其实还能更快?

如果你追求极致的Memcache访问速度,可以登录上你的Memcache服务器,检查一下CPU使用情况。我找了一台线上服务,情况如下:


Memcache架构新思考
 

显然CPU7的系统使用率比其他CPU要高。检查一下软中断:


Memcache架构新思考
 

再看看线上服务的版本:

[jichao1@yf179 ~]$ uname -a

Linux yf179 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

在kernel-2.6.18-194.3.1.el 版本以下的Redhat以及CentOS 操作系统,使用Broadcom 5709网卡芯片的服务器存在cpu软中断不均衡,只有1个cpu处理软中断。

解决方法可以是升级内核,不过也有朋友说没用,需要通过VIP绑定2块网卡的方式解决,具体方案见:http://hi.baidu.com/higkoo/item/42ba6c353bc8aed76d15e9c3

通过对比内核支持4个队列的服务器(最多只能利用到4核,无法在硬件驱动层直接配置成更多队列),只分配一个CPU的Memcache服务器在大压力下可能会慢1~2ms。

相关推荐