分布式系统, 转载

杨卫华:谈微博Cache设计(zz)

2011年4月28日 阅读(511)

  继成功举办首期TUP活动后,日前在北京丽亭华苑酒店鸿运二厅,由CSDN和《程序员》杂志联合策划组织的TUP第二次活动如期而至,本次活动以Web 2.0技术为主题,聚焦当下火热的社交网、微博架构与实时搜索领域。就相关领域及产品研发背后的技术、产品设计及用户体验话题为与会者提供全开放式的交流平台。即使是付费沙龙,参会报名人数仍在不断上升,本次活动有超过300人来到现场。

  继成功举办首期TUP活动后,日前在北京丽亭华苑酒店鸿运二厅,由CSDN和《程序员》杂志联合策划组织的TUP第二次活动如期而至,本次活动以Web 2.0技术为主题,聚焦当下火热的社交网、微博架构与实时搜索领域。就相关领域及产品研发背后的技术、产品设计及用户体验话题为与会者提供全开放式的交流平台。即使是付费沙龙,参会报名人数仍在不断上升,本次活动有超过300人来到现场。

  以下是新浪微博技术经理杨卫华的演讲内容:

  杨为华:今天主要给大家介绍一下微薄cache设计,在我们业界有一个趋势就是平台和应用。以前Web1.0发展到Web2.0,有一种更进一步趋势就是转变成平台和应用。很多应用不是单纯一个Web应用,国内已经有不少公司做这个方向,做Web2.0或者cache,刚开始都是自己模式,希望能够把这个行业一些人聚合起来大家一起交流,大家犯过的一些错误可以避免,让我们做事情更有效率。

  最早我们新浪曾经有一个DB产品,刚开始做通过我们社区介绍,慢慢让大家知道DB在一些方面用起来更适合大家的地方,后来比如说我们去年发展一种分布式的,现在随着社区大家互相介绍,如果有人单独讲一个DB会觉得很不好意思。微博最早我们只能看国外的,慢慢有不少公司做这个,刚开始我们介绍一些基本技术,比如说微博的东西可以用推和拉做,等到以后经过我们把这个话题讲到以后,有人再讲微博技术光讲推和拉觉得不好意思,要进行一些更深入的话题,慢慢我们就在这个过程当中。今天讲一下cache的设计,我讲过一次微薄扩展设计,那是一个基本话题,刚才也讲了一个架构讲得比上次更深刻,光讲一个推是不够的,我今天演讲主要从是cache进一步补充一下,一部分是Feed架构简介,第二是cache的设计。

  微博技术核心主要三个,一条微博有很多关注的人,分别将你发表的微博分发到你所有关注的人,聚合就是打开微博首页这里看到我关注人的信息,以及这个微博信息的展现,微博在技术上也称之为status或者Feed,下面图就是一个典型的Feed。

  Feed架构刚才是两种设计模式推或者拉,还有第三种方式叫做复合型。做到一定程度单纯推或者拉是不够的。推的话如果把Feed比喻成邮件,推就是inbo不惜是收到的微博,OUTPOX是已发表的微博,发表到所有的粉丝,查看就是直接访问到。PUSH优点就是实现简单,通常做一个种型是首选方案,缺点就是分发量。PULL发表是在自己的outbox,查看是所有关注对象的inbox。优点节约存储,缺点是计算大量,峰值问题。当前访问量比较大是不是计算得过来,服务器是不是够用,假如说你的服务器是按照你峰值规划你的服务器,在平时时候是非常多的空闲,这个是不合理,不管推和拉都有一些共同的难题比如说峰值的挑战,比如说世界杯活动在新浪微博每秒钟发表量达到2500条,我们可以使用异步处理2500个峰值,处理速度慢一点,你关注人不能马上看到,峰值过后保证系统不会被峰值压跨,下面就是cache,现在有一句话对于这种real—time就是说:传统硬盘已经不够用,很多东西要分放在硬盘里面才能满足需求。因此cache设计决定了一个微博系统的优劣。

  里面是一种复合型,不是一个简单的推或者拉的类型,因为就是说像我们新浪微博到这个级别要做很多优化,从模型上就是一个推或者拉的模型,我们按照它的关系来说,把cache分成需要四种存储的东西,这两个里面跟索引比较类似,第三就是列表和客户自己资料。

  看一下第一部分就是inbox微博首页开始ID列表,完全是内存里面,但是有一个缺点,我们要添加元素需要先AET再SET;第二部分outbox发出微博有存储最新ID在于聚合。为了高效,我们通常分两部分,第一就是说最新的一个ID列表比如说我们有100条内容,这个用户很久没有来,这个是空要过来取就要从我工作列表用ID地址聚合起来;第三部分是关注列表,这些都是纯ID,然后following,following加载开销比较大,上百万粉丝,越大的集合越容易变更,改变则需要deleteall减少使用followinglist场景;第四部分contetcache微博内容体里面有一个很重要的内容,热内容。这个用户有200万粉丝,这个内容是热内容,在线粉丝也非常多,多分防止单点访问瓶颈,最终格式预生成,apenAPI需要返回xml,json格式。

  刚才说了介绍cache的架构,现在介绍cache的第二个方面就是使用流程。有一个典型的场景,比如说发表我们cache怎么操作,首页展现怎么操作。发表需要改变三个内容,首先我们要声称contentcache,对于常规contentcache我们也要做复制,如果对方粉丝在线会在inbox数值ID变更。

  第三方面修改outbox,根据粉丝列表修改inbox数据列表,然后首页Feed操作流程。左边有两个:inbox,outbox。两个是可选的,如果inbox没有我们有一个树型计算,我们会根据ID列表聚合起来反馈给I用户。

  获取首页Feed的流程,首先间看inbocache是否可用,获取关注列表,聚合内容从following关系,根据idlist返回最终Feed聚合内容。最常用两个流程就是这样。

  下面介绍微博cache经验谈,首先说流量。打开首页,这个时候打一个I来说,比如说contentcache为例,比如multigntn条Feed,cache大小等于N,并发清且如1000次/秒,总流量等于50,20K。假如我们机房里面有1万并发需要800MBPS贷款,如果不改变价格这个流量是实现不了。再一个1G内网我们做了很多压力测试,一般环境跑三四百兆已经不错了,你网内不光是访问cache开销,还有很多其他流量,因此我们需要优化带宽访问,我们可以把热门数据加载到localcache,要用压缩算法,可以做复制,有的时候将一个内部cache分组,不同的服务器组,访问不同的cache减少内网通信的开销。第一个问题就是带宽的问题,其中内销cache开销访问量大第一会碰到瓶颈。第二问题就是hotKeys,我们要访问姚晨的微博,我们要建设一个Ilocolcache,删除时间要把所有的都删除。

  cache规划方面一些问题,将不同业务,不同长度KEY存储到不同的MEMcache,不同的业务有不同的生命周期,LRUcache小量,memorystorage大部分,更高效的内存利用。

  mutex,什么情况会出现这个问题,比如说一个很热的内容,cache里面没有了,因为memcache不是很可靠的东西,你放在里面可能会消失,经常出现这样的情况:一个很热的cache没有了,因为我们系统有很多并发很热数据没有了,非常多的并发如果我们没有一个很好的策略,比如说几十个,几百个加一个内容这会是一个悲剧。我们给每个KEY加载MUTEX,这个并发连接取数据库,然后把mutex删除成规,这个时候我只需要一个连接,数据库加载到BD里面有可以了。

  因为前面已经介绍很多内容,我今天介绍一个很简单的东西就是想关注更多微博平台的技术,有三个方向一个就是S2技术沙龙,每个月举行一次,另外就是说对很多讲师光做讲座不过瘾,讲座只是传授别人东西,没有能够交流,所以我们对一线架构师有一个自己线下交流,我们讨论一些实际中遇到的问题,对这些架构师有帮助提高,交流一下自己正在做,或者有一些东西还不成熟,不适合拿出来讲的东西,可以线下交流。另外我们有各新浪微博开发大会,会介绍更多微博平台架构分享的东西。

  S2技术沙龙介绍了希望关注分享Web2.0技术,下面有一个它的网址,另外就是说介绍一下即将举行一个新浪微博开发者大会,主要除了宣传作用,希望更多分享新浪微博技术,比如说这个平台需要架构与存储,可能到时候讲比今天更深入一些,会讲一些sinaappengine技术,数据挖掘,合作与商业模式,开发者与平台。目前有一个开发平台的网站。

  今天介绍比较简单主要是这样看看有什么可以提问。

  提问:我想问一下新浪微博设计之初有没有考虑过安全的问题,图片存储等等,这种方面的问题这个微博设计之初考虑很多安全方面工作,我想了解一下这方面有什么看法和见解。

  杨为华:我们也在解决两个方面,一个用低质量内容,有一些搜索用户可能做了一些不好的东西,故意出现一些关键字让自己搜索排名更靠前,有一些用户发广告,对于传统广告我们有一些技术,新浪博客有一些技术,通过一些词语热度可以判断一些内容是不是广告内容。实时搜索我们也正在做,这方面我们也刚开始起步。

  提问:我之前是跟腾讯微博有相关的,但是我已经不在腾讯了。

  杨为华:没关系,腾讯微博也可以一起探讨。

  提问:我想问一个比较细节的问题,你说到为了节省内部带宽的问题会使用到logcache,这个部署你们是跟Web2.0服务器放在一起还是什么?

  杨为华:每个前端布置一个cache,另外还有一些APC那种基础非cache的技术,或者其他内存数据共享这种,非标准的方式都可以做,cache是一个很泛的观念。

  提问:获取cache会用MUTEX的技术。这个环节具体是什么?这个环节是在哪个环节做的?

  杨为华:写到一个典型的场景,热点内容有很多人同时访问这个网站,这个cache量没有了,如果不做任何保护实际上数据库访问压力很大,还有其他场景,还没有复制过来数据就过来了,很多人认为cache没有加载访问数据库也是比较悲剧。

  提问:这些东西是在应用这个层次做还是类似也有一个cache上面做?

  杨为华:我们是应用做的。

  提问:我请问一下您微博系统使用cacheDV。

  杨为华:计数方面用了。

  提问:你有一个推模式,你用复合模式,你们简单介绍一下你们怎么用这个复合模式,对微博每个人都会有一些好友有会跟随一些人,能不能讲一下对于个人主界面缩影算法,我看到我的界面怎么知道哪些人在前面,哪些人在后面?能说一下你们的算法,每个人登陆进去有一个我的主界面,我有一些好友,也是一些人的粉丝,你们怎么做排序?

  杨为华:我们就是时间排序,最简单的方法,我们没有找到更好的算法之前。

  提问:不是根据一些热点?

  杨为华:我们也考虑过那个方向,但是我们认为挑战性非常大,你认为好的方法用户不一定认可,这个挑战很大。你用算法做一些东西,但是用户认为不重要的东西,如果用户没有展示,用户可能也会有其他看法。为什么用复合模式,我们也不知道为什么叫复合模式,我们根据实时运行情况,发现哪里有瓶颈我们会想到更好的方法解决。这个瓶颈,能不能给在线用户加一个什么东西,减少系统压力,不影响原来的价值,主要处于每个性能模块的角度考虑的。

  提问:你能不能说一下一个用户登陆以后你们做了一些什么步骤,我估计有些是用推的,有些是用拉,各个平台设计微博不一样,有的速度很快,有的会有延迟,你能介绍你们用户交流流程吗?

  杨为华:这个图可以看到,最前面还有别的cache,用刚才方式我们看有没有命中,如果没有通过OTUBOX关注列表进行计算,然后把结果合并起来,在上面有一些配件成了cache,反映给用户,整个流程跟这个图上原理来说区别不大。

You Might Also Like