Memcache架构新思考

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

1. Memcache使用中的雷区

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

带宽和连接数

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

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

Hot Key

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

Memcache Client

不记得是不是在[email protected]提到过,也和淘宝的同行交流过,共同的的经验是: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要高。检查一下软中断:

再看看线上服务的版本:

[[email protected] ~]$ 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。

Memcache架构新思考,布布扣,bubuko.com

时间: 2024-10-13 21:49:05

Memcache架构新思考的相关文章

乐享快捷支付背后银行业IT架构新思考

随着社会的不断进步和发展,人们的生活水平越来越高,生活节奏也越来越快.在这个着重强调便捷.效率的时代,以往单纯的营业厅办理银行各类业务,已经不能满足人们日益增长的消费.支付需求,于是我们看到银行业向用户提供网上银行支付.手机银行等便捷的支付手段.作为一名普通消费者,在遇到在线支付.紧急情况时,还是很需要一次快捷而高效的金融服务,在互联网和移动互联网端进行一次完整的网上购物,只需输入登录名和密码,就可以快速完成一次简单交易.在线金融银行支付的出现,很好的弥补了线下银行业的繁琐与不方便. 在这一切便

.Net 平台下的互联网架构新思考

上一篇<互联网应用架构谈>有很多阅读量,但后来实践中发现基于WCF服务层技术用于实现网站访问的效率是有问题的. 我的本意是以WCF中间层解决商业逻辑,供各个平台调用,然而还是带来诸多的麻烦,不是最佳的实践方案. WCF在企业级开发SOA方面是突出的.然而我们做互联网的应用应该是采用WebAPI技术去实现多平台. 为了避免给新人带来误导,这里我就重新写篇博客,发布下我的技术架构吧~~ 确定完技术重构方案后,就得考虑如何去实施了. 原先的站点已经在用了,所以我发布了V1.0版本,确定基线.同时创建

asp.net mvc应用架构的思考--Unity的应用及三层代码

最近要做一个项目,和国外的架构师聊过之后.对方提到了他准备采用asp.net mvc, jquery, Unity 等技术来代替老的技术: 如asp.net web form. 他请我帮他想一些关于架构的东西.一直以来,关于asp.net mvc应用的架构,有一些想法.正好借这个机会写出来.资深的人士可能已经知道了,就当是复习吧.欢迎发表意见.指出不足. Unity的应用 Unity出来已经有几年了.早几年的1.2版就可以实现这里所说的功能.目前最新稳定版是2.1.正在开发的3.0也许会给我们带

永恒之蓝病毒事件所引发的运维安全行业新思考

一.NSA "永恒之蓝" 勒索蠕虫全球爆发 2017年5月12日爆发的 WannaCry勒索病毒肆虐了全球网络系统,引起各国企业和机构极大恐慌.而这次受害最严重的是Windows系统,自然也被锁定为怀疑对象,有人认为正是因为该系统对于漏洞的麻木和疏漏才导致了此次勒索病毒的蔓延.作为受害者的微软却将矛头指向美国国安局(NSA)和永恒之蓝.不法分子利用永恒之蓝漏洞攻击Windows系统,造成系统锁定,从而进行勒索,否则将删除所有信息 就WannaCry勒索病毒呈现的特征而言,面对新时期网络

编码艺术-代码架构的思考

一.前言 从入职到现在已有一年.想想现在与当初自己的期望虽有遗憾但也还是有所进步.我个人对自己的认知是敢于尝试与实践新的技术与新的理论,说大胆也不为过.因此工作中写的代码或多或少也被诟病.被批评.被质疑.但我觉得若人人都循规蹈矩.人人都不去尝试,那么谈何创新.谈何进步呢?终究是需要人去做那一颗划破静夜的流星. 二.背景 最近在对项目的SDK进行升级改造.考虑到要兼容之前用户的调用习惯,所以改造是需要很多讲究的,也引发了对代码架构的思考.在大多数时候我们在完成一个需求的时候,大部分人都是努力去完成

关于分布式架构的思考

1 概述 分布式系统就是利用一组机器来协同工作,并对外提供统一的服务. 分布式架构的核心,在于拆分. 2 分布式数据架构 2.1 垂直拆分 按照业务将数据拆分成不同的库; 如sns网站中日志与照片可以分成两个数据库. 2.2 读写分离 一般是主从架构,主库用于写,从库用于读; 主从之间需要同步机制来保证数据的一致性. 2.3 水平拆分 按照数据的特点将全量的数据拆分成不同的分区,并分布到指定的库中; 如sns网站中的日志/照片等信息是按照userID来组织的,因此可以根据userID将数据拆分到

游戏服务器架构的思考

时间总是在不经意的时候就流走了,突然回想我已经做了四年游戏开发,经历了几个游戏项目,以前项目中的游戏服务器框架都不是我心中理想的框架,虽然不知道是不是我见识还不够.下面记录下我对游戏服务器架构的简单思考.好的游戏框架可以提高开发效率,节省人力成本.首先最简单的服务器框架,那就是只要一个网关和一个游戏服务器.如图: 图中agentserver负责客户端连接,客户端收发数据,将客户端数据转发给服务器,将服务器数据转发给客户端,几乎没有逻辑,这样可以应对大并发io.所以agent可以采用一个epoll

关于多层架构一些思考

1:关于多层架构(N-Tier) 多层架构是一种被行业证明过的软件架构模型,对开发一些解决可扩展性.安全性.容 错性方面的企业级(客户端/服务端)应用程序支持是相当给力.但在.NET世界里,我们有许多工具和产品,却没有指导手册是关于如何设计和实现一个良好的 多层架构模型,比如一些样例版,Demo等等,我们或许多少有听到.看到一些关于多层架构模型的用途和益处,但更多知道的仅仅是如何使用和实现,没有过多 的思考为何我们要这样设计呢?这样设计符合了哪些设计模式呢?遵循哪些设计原则呢?或者了解一点多层的

高性能网站架构的思考 (转)

今天看到了一篇关于网站架构的文章,写的很好,改了改,添加了一些自己的想法: 对于大流量高并发的网站,首先考虑的都是如何用最少的资源处理最多的业务.一般来说,网站架构最初需要考虑三个方面:数据库瓶颈.代码执行效率和服务器端的配置.下面结合项目开发中经验总结一下.        1. 合理设计与使用数据库        对于数据库的瓶颈可以归纳为两点:如何设计高性能的数据库?如何使用设计出来的高性能数据库?        首先,设计数据库之初就应该预估可能产生的数据量和所能承受的压力:该分表的分表,