谈微博Cache设计
杨为华：今天主要给大家介绍一下微薄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，反映给用户，整个流程跟这个图上原理来说区别不大。