中国首届微博开发者大会在北京举行，这是国内微博行业的首场技术盛宴。作为国内微博市场的绝对领军者，新浪微博将在此次大会上公布一系列针对开发者的扶持政策，以期与第三方开发者联手推动微博行业的整体发展。图为微博平台首席架构师杨卫华演讲。
以下为演讲实录：
大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。最晚的一次，是12点多收到一个邮件说想了解一下微博底层是怎么构架的。很多技术人员对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家对微博的底层技术有更好的了解。另外不管是做客户端、1.0、2.0、论坛、博客都要考虑架构的问题，架构实际上是有一些共性的。今天我通过讲解微博里面的一些架构，分析一下架构里面哪些共性大家可以参考。
首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。第一版就是是非常快的，我们可以非常快的实现我们的模块。我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。
第一版本的技术细节，典型的LAMP架构，是使用Myisam搜索引擎，它的优点就是速度非常快。另外一个是MPSS，就是多个端口可以布置在服务器上。为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由三种部署方式。我们可以把三个单元部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。这个解决了两个问题，一个是负载均衡，因为每一个单元都有多个结点处理，另外一个是可以防止单点故障。如果我们按照模式一来做的话，任何一个结点有故障就会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。
我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。我们就考虑这个系统怎么改进。
首先是推模式，这肯定是延迟的首要原因，我们要把这个问题解决掉。其次我们的用户越来越多，这个数据库表从一百万到一亿，数据规模不一样处理方式是有差别的。我们第一版单库单表的模式，当用户数量增多的时候，它不能满足就需要进行拆分。
第二个是锁表的问题，我们考虑的是更改引擎。另外一个是发表过慢，我们考虑的是异步模式。
第二版我们进行了模块化，我们首先做了一个层，做了拆分，最右边的发表做了异步模式。第二个服务层，我们把微博基础的单元设计成服务层一个一个模块，最大是对推模式进行了改进。
首先看一下投递模式的优化，首先我们要思考推模式，如果我们做一下改进把用户分成有效和无效的用户。我们一个用户比如说有一百个粉丝，我发一条微博的时候不需要推给一百个粉丝，因为可能有50个粉丝不会马上来看，这样同步推送给他们，相当于做无用功。我们把用户分成有效和无效之后，我们把他们做一下区分，比如说当天登陆过的人我们分成有效用户的话，只需要发送给当天登陆过的粉丝，这样压力马上就减轻了，另外投递的延迟也减小了。
我们再看数据的拆分，数据拆分有很多方式，很多互联网产品最常用的方法，比如说如可以按照用户的UID来拆分。但是微博用户的一个特点就是说大家访问的都是最近的服务器，所以我们考虑
微博的数据我们按照时间拆分，比如说一个月发一张表，这样就解决了我们不同时间的惟度可以有不同的拆分方式。第二个考虑就是要把内容和索引分开存放。假如说一条微博发表的地址是索引数据，内容是内容数据。假如说我们分开的话，内容就简单的变成了一种
key-value的方式，key-value是最容易扩展的一种数据。比如说一个用户发表了一千条微博，这一千条微博我们接口前端要分页放，比如说用户需要访问第五页，那我们需要迅速定位到这个记录。假如说我们把这个索引拆分成一个月一张表，我们记录上很难判断第五页在哪张表里，我们需要索引所有的表。如果这个地方不能拆分，那我们系统上就会有一个非常大的瓶颈。最后我们想了一个方法，就是说索引上做了一个二次索引，改变我们还是按照时间拆分，但是我们把每个月记录的偏移记下来，就是一个月这个用户发表了多少条，ID是哪里，就是按照这些数据迅速把记录找出来。
异步处理，发表是一个非常繁重的操作，它要入库、统计索引、进入后台，如果我们要把所有的索引都做完用户需要前端等待很长的时间，如果有一个环节失败的话，用户得到的提示是发表失败，但是入库已经成功。所以我们做了一个异步操作，就是发表成功我们就提示成功，然后我们在后台慢慢的消息队列慢慢的做完。另外新浪发表了一个很重要的产品叫做MemcacheQ，我们去年做了一个对大规模部署非常有利的指令，就是statsqueue，适合大规模运维。
第二版我们做了这些改进之后，微博的用户和访问量并没有停止，还有很多新的问题出现。比如说系统问题，单点故障导致的雪崩，第二个是访问速度问题因为国内网络环境复杂，会有用户反映说在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值，MySql复制延迟、慢查询，另外就是热门事件，比如说世界杯，可能会导致用户每秒发表的内容达到几百条。我们考虑如何改进，首先系统方面循序任意模块失败。另外静态内容，第一步我们用CDN来加速，另外数据的压力以及峰值，
我们需要将数据、功能、部署尽可能的拆分，然后提前进行容量规划。
另一方面我们还有平台化的需求，去年11月我们就说要做开放平台，开放平台的需求是有差异的，Web系统它有用户行为才有请求，但是API系统特别是客户端的应用，只要用户一开机就会有请求，直到他关闭电脑这种请求一直会不间断的过来，另外用户行为很难预测。
系统规模在持续的增大，另外也有平台化的需求，我们新架构应该怎么做才能满足这些需要？我们看一下同行，比如说Google怎么样考虑这个问题的？
Google首席科学家讲过一句话，就是一个大的复杂的系统，应该要分解成很多小的服务。比如说我们在Google.com执行一个搜索查询的话，实际上这个操作会调动内部一百多个服务。因此，我们第三版的考虑就是先有服务才有接口最后才有应用，我们才能把这个系统做大。
现在我们看一下第三版，首先我们把底层的东西分成基础服务，基础服务里面比如说分布式的存储，还有分层，我们做了一些去中心化、自动化的操作。在基础服务之上有平台服务，我们把微博常用的应用做成各种小的服务。然后我们还有应用服务，这个是专门考虑平台各种应用的需求。最上面我们有API，API就是新浪微博各种第三方应用都在上面跑。
平台服务和应用服务是分开的，这样实现了模块隔离，即使应用服务访问量过大的话，平台服务不会首先影响。另外我们把微博的引擎进行了改进，实现了一个分层关系。
用户的关注关系，我们改成一个多惟度的索引结构，性能极大的提高。第四个层面就是计数器的改进，新版我们改成了基于偏移的思路，就是一个用户他原来读的一个ID比如说是10000，系统最系的ID是10002的话，我们和清楚他有两条未读。原来的版本是采用绝对技术的，这个用户有几条未读都是用一个存储结构的话，就容易产生一致性的问题，采用这种偏移的技术基本上不会出错。
另外基础服务DB冷热分离多维度拆分，在微博里面我们是按照时间拆分的，但是一个大型的系统里面有很多业务需要有不同的考虑。比如说私信这个就不能按照时间来拆分，这个按照UID来拆分可能更简单。然后我们突出存储还做了一个去中心化，就是用户上传图片的速度会极大的提高，另外查看其他用户的图片速度也会极大的提高。另外是动态内容支持多IDC同时更新，这个是在国内比较新颖的。
下面给大家介绍一下新浪微博怎么样打造一个高性能架构。到目前为止有五千万用户使用新浪微博，最高发表3000条以上每秒，然后一个明星用户发表的话，会被几百万用户同时读到。
这些问题的本质是我们架构需要考虑高访问量、海量数据的情况下三个问题。易于扩展、低延迟、高可用和异地分布。我们每天有数十亿次外部网页以及API接口的需求，我们知道微博的特点是用户请求是无法cache的。因此面对这个需求我们怎么样扩展？几点思路。第一我们的模块设计上要去状态，我们任意一个单元可以支持任意节点。另外是去中心化，避免单点及瓶颈。另外是可线性扩展。最后一个是减少模块。
我们要做一个高性能的系统，要具备一个低延迟、高实时性，微博要做到高实时性这是核心的价值，实时性的核心就是让数据离CPU最近，避免磁盘的IO。我们看淘宝核心系统专家余锋说过的一句话“
CPU访问L1就像从书桌拿一本书，L2是从书架拿一本书，L3是从客厅桌子上拿一本书，访问主存就像骑车去社区图书馆拿一书”。我们微博如果要做到非常实时的话，我们就需要把数据尽量离CPU节点最近。所以我们看一下cache设计里面怎么达到这个目标。首先INBOX，这个数据我们需要放再一个最快的地方，因为用户随时访问。OutBOX里面的最近发表就是L1cache，还有一个是中期的，这个因为访问少一点，它可以被踢。最后一部分内容体有三部分。L0是本地的，我们需要把一些经常访问的，比如说明星发表微博的内容体本地化，因为它被访问的概率非常大。然后L1里面存放着最近发表的，还有一个是中期的。我们通常用L2就可以了，L1我们可以理解成它就是一个存储。
一个好的架构还需要举行高可用性。我们看一下业界的指标，S3是99.9%，EC2是99.5%，我们另外一个同行Facebook在这方面它是没有承诺的，就是接口可用写。微博平台目前承诺的是99.95%，就是说一天365天故障率应该小于9的小时。这个怎么达到？第一我们要做容量规划，地个是要做好监控以及入口的管理，就是说有些服务如果访问量过了的话，我们要有一个开关可以拦住他。我们通过这个图表可以清楚的看到，比如说我们要做L1的cache，我们剩余空间有多少，比如说80%，就说明这个数据有可能会丢失，有可能会对我们的系统造成影响。
另外一个层面就是接口监控，我们目前有Google维度的接口监控，包括访问错误失败率。然后要做架构，给大家一个很重要的经验分享，就是说监控的指标尽量量化。比如说他延迟30秒是小问题，如果是延迟10分钟我们就要立即采取措施了，就是所有可以量化的指标都要量化。
然后我们看监控怎么样更好的做？我们看亚马逊的VP说过的一句话，就是说监控系统确实特别好，可以立即告诉我们哪里有故障，但是有20%的概率我们人是会出错的。
所以我们一个大型系统就应该要为自动化设计，就是说尽可能的将一些运作自动化。比如说发布安装、服务、启用、停止。我们再看另外一句，Google的工程师是怎么做的。他是这么做的，比如说第一周是处理线上的业务，这一周他处理了很多事情，处理了很多系统的情况，剩下的系统问题是不需要他做的，他只要把这一周碰到的情况用程序的方法来解决，下次再碰到这种情况很简单的一个按钮就可以处理了。我们目前也在向自动化这方面努力，就是我们的工具在持续增加。
另外一个异地分布，在国内网络环境下，比如说IDC灾难，机房检修甚至是机房掉电，我们也碰到过中国最好的机房也会掉电，所以要每个服务单元都能支持多机房部署。另外做多机房部署有一个好处，就是用户的访问速度会提高。多IDC分布静态内容就不说了，基本上大的互联网公司都会做，它非常成熟基本上没有什么问题，比如说图片等等的静态内容。动态内容的CDN分布是业内的难点，国内很少有公司能够做到非常成熟的多机房动态内容发布的成熟方案，它的核心就是分布式存储
。一款理想的分布式存储产品它有哪些需求呢？首先它要支持海量规模、可扩展、高性能、低延迟、高可用。第二个是需要多机房分布，能够满足国内负责的网络环境，还要具备异地容灾能力。第三个就是要调用简单，具备丰富数据库特性。因此分布式存储需要解决一个多对多的数据复制。
如果要做复制无非是三种策略，第一个是Master/Slave，但是它也两个缺点，第一个是Master是中心化的，如果Master在北京那广州访问就非常慢。第二个缺点是有单点风险的，比如说Master在北京，能立即迁到广州吗？这样时间窗口就丢失了，而且需要人工的干预，而且日常广州的用户访问北京的Master是有很大问题的，所以一般来说要做的非常优秀是不会考虑第一种方案的。第二种就是Multi-Master方案，它需要应用避免冲突，就是我们不能多处改变。这个对于微博来说不会特别难，我们的用户通常只会再一个地方发表微博，很难既在广州又在北京发表或者是修改自己的资料，这样的话我们应用上就可以避免这种情况。第三个就是Paxos就是可以达到强一致写，就是一条数据如果成功肯定是多个机房都成功了，这个也显而易见就是延迟性非常大。因此总结一下Multi-Master是最成熟的策略，但是它现在没有成熟的产品，因为确实没有。
我们再来看微博的方案，所以我们自己实现了一个多机房同步的方案。
就是我们前端应用将数据写到数据库，再通过一个消息代理，相当于通过我们自己开发的一个技术，将数据广播到多个机房。这个不但可以做到两个机房，而且可以做到三个、四个。具体的方式就是通过消息广播方式将数据多点分布，就是说我们的数据提交给一个代理，这个代理帮我们把这些数据同步到多个机房，那我们应用不需要关心这个数据是怎么样同步过去的。
用这种消息代理方式有什么好处呢？可以看一下Yahoo是怎么来做的？第一个是数据提供之后没有写到db之后是不会消失的，我只要把数据提交成功就可以了，不需要关心数据怎么到达机房。第二个特点YMB是一款消息代理的产品，但是它唯一神奇的地方是为广域网设计的，它可以把多机房应用归到内部，我们应用不需要关注这个问题。这个原理跟我们目前自己开发的技术相似。
然后我们再看一下目前即将推出的微博平台的新架构。我们知道API大部分的请求都为了获取最新的数据。API请求有一个特点，它大目前调用都是空返回的，比如说一款手机的客户端每隔一分钟它都要调用服务器一下，就是有没有新数据，大目前的调用都是空返回，就是说不管服务器有没有数据都要调用一次。这次询问到下一次询问中间，如果有新的数据来了，你是不会马上知道的。因此我们想API能不能改用推的方式，就是客户端不需要持续的调用，如果有新数据就会推过去。技术特点，显而易见低延迟，就是从发表到接受1秒内完成，实际上可能用不了1秒。然后服务端的连接就是高并发长连接服务，就是多点都连接在我们的服务器上，这个比传统的API要大很多。
我们看一下推送架构怎么从架构底层做到实时性的。
从左上角的一条微博在我们系统发布之后，我们把它放在一个消息队列里面，然后会有一个消息队列的处理程序把它拿过来，处理以后放到db里面。假如说我们不做持久化，因为我们推送数据也不能丢失，我们就要写一个很复杂的程序，将S数据异步去存，这样就会非常复杂，而且系统也会有不稳定的因素。从另外一个角度来说，我们做持久化也是做过测试的。我们推送整个流程可以做到100毫秒和200毫秒之间，就是说我们在这个时间能把数据推送出去。
我们再看一下内部细节，就是我们收到数据之后首先要经过最上面RECEIVER。然后推到我们的引擎里面，这个引擎会做两个事情，首先会把用户的关系拿过来，然后按照用户关系马上推送给他相应的粉丝。所以我们调研方已经在那儿等待了，我们需要有一个唤醒操作，就是说在接口这儿把它唤醒，然后把它发送过去。最后是一个高并发的长连服务器，就是一台服务器支持10万以上的并发连接。最右边中间有一个圆圈叫做StreamBuffer，我们需要StreamBuffer是要保存用户最近的数据。因为用户可能会有断线的，比如说他发送数据的时候断线半分钟，我们需要把这半分钟补给他。这就是我们的推送架构。
下面介绍一下平台安全部分。由于我们的接口是完全开放的，所以我们要防范很多恶意行为，有很多人担心我们接口是开放的，是不是有人通过这个接口发垃圾广告，或者是刷粉丝，我们技术架构怎么来防范这一点呢？这是我们的安全架构，做了三个层面的事情。总上面是我们有一个实时处理，比如说根据频度、内容的相似性来进行判断，判断你发的是不是广告或者是垃圾内容。中间这个是一个处理器，我们会根据一些行为进行判断，比如说如果我们只是实时拦截的话，有些行为很难防止，我们做了个离线纠正的模块，比如说他潜伏的几个月开始发广告了，我们可以事后把这些人清除掉，以保证我们平台的健康。最后是通过监控的维度来保证内容的安全。目前内容安全的架构大概是51的体系，就是说我们的实时拦截可以做到50%的防止，离线分析大概可以做到40%的防止。
微博平台需要为用户提供安全及良好的体验应用，以及为开发者营造一个公平的环境，所以我们的接口需要清晰安全的规则。从一个APP调用我们的接口，需要几个阶层，需要划分不同的业务模块。第二个是安全层。第三个是权限层。这是我们平台安全的两个维度，一个接口安全，一个是内容安全。
我今天讲的是架构方面的问题，在座大部分是开发者，可能大家都在处理不同的架构问题，架构很多地方是相通的。我们需要做一个软件系统需要解决的本质问题是什么？微博第一版解决发布规模问题，第二版是解决数据规模的问题，第三版是解决服务化的问题。将复杂的问题简单化之后，我们才可以设计出一个容易扩展的大规模架构。我今天介绍就这么多，我们微博实际上是很需要各方面的技术人员，大家对我们的架构如果感兴趣的话、对我们的系统感兴趣的话，也希望各方面的人员参与我们微博的团队，随时可以给我微博上发私信。
在2010年的QCon北京大会上，InfoQ的编辑对杨卫华进行了采访，其中谈到了关于新浪微博系统平台应对各种问题的解决方案，以及正在开发中的新浪云。
相关厂商内容
杨卫华，新浪产品部技术经理，目前工作以新浪微博技术平台为主，曾负责过新浪IM等通讯服务端架构设计。对互联网后端技术，分布式，网络编程，XMPP即时通讯等领域感兴趣。曾组织多次广州及珠三角技术沙龙活动。个人blog 为：
InfoQ：大家都知道，在美国有一个非常有名的信息分享平台叫做Twitter，而在中国，我们也有同样的方式，就是现在非常流行的新浪微博，它还有个非常温馨的名字，叫做围脖。而新浪微博的架构就是杨卫华先生主持开发的。
今天我有幸采访到杨卫华先生，让他来给大家谈一谈，在新浪微博的技术架构方面，他们是如何为用户提供更好的性能、更好的服务的。
卫华先生你好，我的第一个问题是，在新浪微博上有很多名人，名人的微博一般都是非常热的，对它们的访问量也特别高，那么对于这些微博，您采用了什么样的方式来支持这种大数据量的访问呢？
杨卫华（以下简称卫华）：对于这个问题，我们做过专门的分析。因为最近新浪微博有名人扎堆的现象，我们根据这个现象，从以下几个角度来进行解决。
首先根据中国的网络现状，比如说网通和电信，之间的网络访问速度会比较慢，我们考虑让用户能够访问就近的服务器，这样使用体验、速度都能达到要求。我们根据新浪以往的经验，在全国部署了大量服务器，这样就为微博提供了硬件上的保证。
第二个方面，在程序优化的方面，在产品上线之前，我们进行了全方面的压力测试，如果系统在某个方面可能会出现瓶颈，比如名人的访问量比较高的话，我们就从那个角度去优化。比如说Cache是否够用，数据库访问是不是瓶颈，这方面我们预先都有对压力的估计，然后会针对那些方面去做优化。
第三个方面，对于那些静态资源，比如图片、视频、JS脚本，我们有专业的CDN来解决的，这样就能够保证全国的用户在访问新浪微博时都能够得到比较好的体验。
InfoQ：现在的服务器大概都架设在哪几个部分？覆盖全国哪几个地区？
卫华：全国基本上大部分省份都有服务器，特别是一些比较核心的节点，比如北京、上海、广州，在这些核心的节点可能部署了更多的服务器，而在其它一些二线城市、其它省份也都有部署的。
InfoQ：您也是为这种大数据量做了充分的准备。最近大家都知道，玉树发生地震，对于这种突发事件，我们也会把微博作为一种信息交流、信息分享的平台，大家的访问也会造成大数据量访问，那么对于这种突发事件，您在技术架构上也做了相应的准备吗？
卫华：对，这种突发事件以及访问峰值，是微博上经常出现的现象。突发事件的访问峰值有两种，一种是可以预测的，比如说我们将来要搞的世界杯，比如春节，大家都相互拜年这种；另外一种是不可预测的，比如地震这种。对可以预测的这种，我们事先会做准备，比如说世界杯，我们要增加相关的服务器来完成。而面对这种不可预测的情况时，我们平时会有个数字，那就是我们平时的平均流量，硬件设备要比它高一定量，这样就能够应对这种峰值的请求。
另外从程序上来说，我们可能有一些专门的机制，比如说用户发表微博，并不是一发表就存到数据库中，简单地理解，他不是这样操作的。业界中微博之类的产品都有一种机制，叫做异步机制，也就是说，在发表的时候，我会把这个信息放到消息队列里面，然后再用另外一个专门的业务处理程序来处理它。当某一时刻发表量非常大，比如说地震了，很多人都会发表，那这个时候系统依然能够有条不紊的来处理这个业务，这样子就能让我们的系统稳定运行，并具有高可用性。
InfoQ：也就是要对整个事务的进行有效的控制？
卫华：对。
InfoQ：大家应该知道，因为有这么多的微博，有那么多名人，而且还有很多平民的、草根的微博，系统的数据量也是非常非常大的，而且还有很多很多的评论，很多很多的留言等等。那么对于这种海量存储，是不是也要做技术架构上的准备？
卫华：对，微博这个产品从技术上来说，有一个很大的特征，就是每天用户发表特别容易，这造成每天新增的数据量都是百万级的、上千万级的这样一个量。这样你经常要面对的一个问题就是增加服务器，因为一般一台mySQL服务器，它可能支撑的规模也就是几千万，或者说复杂一点只有几百万，这样，你可能每天都要增加服务器，从而解决所你面对的这些问题。你要考虑，如果每天要加服务器，你的程序上、访问上会不会有问题，会不会间断。
我们其实有一些优化的方法，比如说我们会考虑热点数据和冷数据，如果经常要访问的这个数据，也就是热数据，而过几天才会访问的就是冷数据，我们会把它们合并，这样就可以按这个时间来分段，也就是把热数据放在一起，冷数据放在一起，这样可以解决这个访问热点的问题。
另外业界还有种思路，刚才说的用MySQL，我们采用Shade的技术会按时间分片，这是一种解决思路；另外还有一种解决思路，业界特别现在国外流行的一种方法，也就是NoSQL的方法。有一种比较好的产品，现在大家比较关注，叫Cassandra，就可以解决这个问题。如果我们每天要加一台服务器的话，那么我们程序、运维这些能不能跟上呢，是否有一种产品可以让你程序不需要做丝毫改动呢？Cassandra这个产品就可以帮你来解决这个问题，你只需要把服务器插进去，那它马上可以使用，那个产品内部就有这样的机制。
InfoQ：那样的话对我们整个产品的维护就比较方便了？
卫华：对，这个可能就是说以后业界发展的一种方向，使用这种分布式的存储来解决这种海量增长的问题。
InfoQ：你觉得NoSQL的数据库和传统的关系型的数据库，那种更适合微博这种形式的网站？
卫华：从长远来说，NoSQL这个更适合一些，特别是分布式的NoSQL，刚才我也讲了，如果能全部下来的话，那可能经常要面对这种扩充的困扰，需要的干扰，可能是说，如果要保证服务不间断，可能就会面临一种很大的挑战，NoSQL，特别是这些分布式的NoSQL产品在内部就解决了这种问题，你不用停机，就可以加服务器，加设备。
InfoQ：这会对我们用户造成很大的方便？
卫华：对。
InfoQ：那么在性能方面，还有一种我们常采用的方式就是Cache的方式，那么在新浪微博系统里面，Cache方式有什么样的特点？
卫华：在像微博这样的Web2.0产品里面，技术界有一种很重要的说法，Cache就是RAM，RAM就是Memory的意思，RAM也就是NewDisk，内存已经成为新的磁盘，代替磁盘的访问了。当我们大量使用Cache的时候，可能会存在很多问题，比如很多那种Web2.0的产品，它在Cache的数量已经不是G的概念了，不是几G、4G、8G的，可能达到一个TB的概念了，一个T相当于1024G，面对这样海量的数据，那我们访问的时候可能就会出现很多新的问题，比如我们的带宽，因为用户请求我的首页的时候，他会获取很多资源，比如有50个人关注你的微博，他需要从Cache里面把这50个人的数据都聚合起来，同时还会有很多人也在访问这个服务器，假如说，有一千个人访问，这一千个人里面，每个人都从五十个里面选，那么这个Cache的带宽将是一个比较大的问题，这是以前那种我们使用Cache时没有遇到过的。然后，为了解决这个带宽的问题，我们可以使用压缩的技术，我们保持Cache里面的数据，经过一种快速的压缩算法，比较传统的我们可以使用GZip，那实际上在这种对时效性要求比较高的技术里面，我们是要求更快速的算法，比如说有一些DOZO算法，它对CPU消耗很小，但它压缩很快，效果也非常好。
另外的一个新问题，单点故障，我们非常依赖那个Cache，假如某个时候它突然崩溃了，那么应用访问可能就会遇到很大的问题，也就是响应速度会出问题，为了解决这个问题，我推荐的做法是，使用一致性的哈希算法，就说送我一个业务，他可以用多个Cache服务器来完成，然后我们使用一致性的哈希算法，当一个Cache崩溃之后，它的请求就可以分散到其它的Cache来完成，总体的那个振荡不会太大，也就是说这个延迟会分散开来，让用户访问页面的时候感觉不到，实际上后台它可能有一台服务器，刚才经历一次Crash，可能造成一次波动，经过我们这样改造之后，用户可能察觉不到这种变化。
InfoQ：用其它的服务器，同时来弥补这个地方的失误？
卫华：对，使用一致性的哈希算法，能够巧妙地达到这个目的。
InfoQ：您刚才提到了NoSQL，另外在最近的业界还有一个流行的词就是Cloud，云计算，我们是不是有计划以后会把微博系统推广到云平台上，或者说采用云计算的方式来处理呢？
卫华：没错，我们微博现在有一部分跟云计算结合比较密切，我们现在微博正打算推出一个开放平台，开放平台什么意思呢？就是说，第三方的开发者可以在我们上面写应用，可以连接到新浪微博，比如说可以获取信息，可以发表微博，而这些应用程序，可以放在我们的开发的另外一个服务上，叫新浪云。这个新浪云有什么好处呢？这些第三方开发的应用，可能他刚开发的时候，请求量不大，但有可能因为这个创意很好，忽然访问量大了。如果你用你自己的解决方案的话，可能就达不到这种要求。比如说最大的问题，可能就是全国访问不畅，或者访问量突然增长了，原来的服务器不够用，你要自己去加硬件，来不及处理。如果你放在那个新浪云上面的话，那我们系统自动会帮你解决这个问题，不管你的一个非常小的程序，比如一天只有几百个访问，还是一个海量的应用，我们都能够放在这个平台里面。在这个云应用里面，你不需要自己操心，系统自动会帮你把这个任务完成。另外它还有一个好处就是，这个云自动实现了全国分布，你只要Host在上面，全国的用户不管从哪里访问，他可以访问一个就近的服务器，这在速度比自己部署都具有很大的优势。
InfoQ：那咱们新浪云现在已经正式推出来，还是正在计划中？
卫华：我们现在还处于测试阶段，我们采用一种邀请式，希望邀请更多的开发者来试用它，我们根据开发者的反馈来改善它，等到一定程度，我们再去大规模地推广。
InfoQ：以后对于大家来维护自己的微博、访问别人微博，是不是也更方便，不一定非要到各种各样的网页上，或者是手机等等，可以在自己开发的程序上就可以做这些事了，对吧？
卫华：对，以后结合这个微博的开放平台，结合新浪云，可以形成一个良好的生态圈，第三方的开发者要有一个很好的环境，给微博增加各种创意，增加各种应用。
InfoQ：这应该是对开发者带来的一个福音。
卫华：对。
InfoQ：感谢杨卫华先生接受我们的采访。谢谢！
