Memcache架构新思考

标签: memcache 架构 思考 | 发表时间:2013-04-11 15:28 | 作者:
出处:http://www.iteye.com

 

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命令来对内存使用量,踢出率,命中率等进行监控。比如微博早期监控中就包括如图所示的这些内容,



 

这些监控中我们最重视的往往是内存使用量和命中率。但随着前端服务不断增加和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

不记得是不是在Memecache@Facebook提到过,也和淘宝的同行交流过,共同的的经验是:Memcache优化的重点和难点在客户端。这个展开起来很大,概况讲有2个重点:(1)TCP连接池(2)基于NIO的multiget;可以参考我的另一篇文章:通过NIO实现Memcached multi get (http://maoyidao.iteye.com/blog/1739282)

 

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

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

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

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



 另外一个好处是,新加入的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使用情况。我找了一台线上服务,情况如下:



 

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



 

再看看线上服务的版本:

[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。

 

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [memcache 架构 思考] 推荐:

Memcache架构新思考

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

Nosql Redis ttserver Flare memcache比较

- - 小彰
随着互联网web2.0网站的兴起,非关系型的数据库现在成了一个极其热门的新领域,非关系数据库产品的发展非常迅速. 而传统的关系数据库在应付 web2.0网站,特别是超大规模和高并发的SNS类型的web2.0纯动态网站已经显得力不从心,暴露了很多难以克服的问题,例如:. 1、High performance - 对数据库高并发读写的需求.

mctop: 监视 Memcache 流量

- - LinuxTOY
mctop 与 top 相似,主要用于监视 Memcache 的流量,包括 key 的调用次数、对象存储大小、每秒的请求数、以及消耗的网络带宽等. mctop 的源代码可从 GitHub 获取. 收藏到 del.icio.us |.

深入理解Memcache原理

- - CSDN博客研发管理推荐文章
1.为什么要使用memcache.  由于网站的高并发读写需求,传统的关系型数据库开始出现瓶颈,例如:. 1)对数据库的高并发读写:. 关系型数据库本身就是个庞然大物,处理过程非常耗时(如解析SQL语句,事务处理等). 如果对关系型数据库进行高并发读写(每秒上万次的访问),那么它是无法承受的. 对于大型的SNS网站,每天有上千万次的苏剧产生(如twitter, 新浪微博).

Memcache工作原理总结

- - Java - 编程语言 - ITeye博客
<!--[if !supportLists]-->1.  <!--[endif]-->分片原理. 咱们废话话不多说了,直接看Memcache的原理. 首先memcache解决的最大的一个问题就是内存多次读取的内存碎片问题. 内存碎片分为内存内部碎片和内存外部碎片. 一般是指在外部碎片中出现了不连续的细小内存片段,不能够被进程利用.

对组件化架构的再思考

- - 人月神话的BLOG
原来架构设计比较多关注的是横向的分层,即数据层,逻辑层和UI层. 而组件化架构必须同时关注纵向的隔离和解耦. 在分层和分模块后,每一个业务组件由三层各自存在的部署包组成,包本身是一个包含了技术组件和服务组件的一个结合体. 由数据层,逻辑层,界面层三层的三个业务包可以构成一个完整的具备独立功能的业务组件.

对数据库架构的再思考

- - 人月神话的BLOG
前面在谈PaaS的时候曾经谈到过共享数据库,私有数据库的问题,在这里再谈谈在多业务系统建设过程中的数据架构模式问题. 首先来看下传统的数据交换解决方案如下图:. 业务场景为单独构建的四个业务系统,在四个业务系统中SID数据为需要跨四个应用交互和共享的数据. 传统的做法则是对四个应用存在的SID库数据进行数据集成和交换,则后续的每一个业务系统中都有全部的共享基础数据,任何一个应用的SID库数据需要通过数据交换和集成同步四份.

[Cacti] memcache安装运行、cacti监控memcache实战

- - CSDN博客系统运维推荐文章
Memcache是danga.com的一个项目,最早是为 LiveJournal 服务的,目前全世界不少人使用这个缓存项目来构建自己大负载的网站,来分担数据库的压力. Memcache官方网站:http://memcached.org/. 下载地址:  http://www.memcached.org/downloads,我们线上使用的比较稳定的版本是1.4.15,如果官网找不到以前的版本了,可以去我的csdn资源里面下载此版本,下载地址:.

深入研究memcache 特性和限制

- - 开源软件 - ITeye博客
转自 http://hi.baidu.com/jqxw4444/item/59c33ea3656ede3e020a4d1c. 在 Memcached中可以保存的item数据量是没有限制的,只要内存足够. Memcached单进程最大使用内存为2G,要使用更多内存,可以分多个端口开启多个Memcached进程,最大30天的数据过期时间,设置为永久的也会在这个时间过期.

[转]Memcache内存分配策略

- - 企业架构 - ITeye博客
一、Memcache内存分配机制.         关于这个机制网上有很多解释的,我个人的总结如下. Memcached的内存分配以page为单位,默认情况下一个page是1M,可以通过-I参数在启动时指定. 如果需要申请内存时,memcached会划分出一个新的page并分配给需要的slab区域.