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



     

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

  • 相关阅读:
    [CF538F]A Heap of Heaps(主席树)
    [BZOJ1901][luogu2617]Dynamic Rankings(树状数组+主席树)
    [BZOJ3932][CQOI2015]任务查询系统(差分+主席树)
    [BZOJ2588]Count on a tree(LCA+主席树)
    [BZOJ2733][HNOI2012] 永无乡(线段树合并)
    [BZOJ1604][Usaco2008 Open]Cow Neighborhoods 奶牛的邻居 (Treap+单调队列)
    【贪心】POJ2376-Cleaning Shifts
    【穷竭】POJ3187-Backward Digit Sums
    【枚举+贪心】POJ2718-Smallest Difference
    【BFS】POJ3669-Meteor Shower
  • 原文地址:https://www.cnblogs.com/isoftware/p/3728789.html
Copyright © 2011-2022 走看看