微博架构ppt

新浪微博技术

中国首届微博开发者大会在北京举行，这是国内微博行业的首场技术盛宴。作为国内微博市场的绝对领军者，新浪微博将在此次大会上公布一系列针对开发者的扶持政策，以期与第三方开发者联手推动微博行业的整体发展。图为微博平台首席架构师杨卫华演讲。以下为演讲实录：大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。最晚的一次，是12点多收到一个邮件说想了解一下微博底层是怎么构架的。很多技术人员对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家对微博的底层技术有更好的了解。另外不管是做客户端、1.0、2.0、论坛、博客都要考虑架构的问题，架构实际上是有一些共性的。今天我通过讲解微博里面的一些架构，分析一下架构里面哪些共性大家可以参考。首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。第一版是非常快的，我们可以非常快的实现我们的模块。我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。第一版本的技术细节，典型的LAMP(Linux-Apache-MySQL-PHP)架构，是使用Myisam搜索引擎，它的优点就是速度非常快。另外一个是MPSS，就是多个端口可以布置在服务器上。为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由三种部署方式。我们可以把三个单元部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。这个解决了两个问题，一个是负载均衡，因为每一个单元都有多个结点处理，另外一个是可以防止单点故障。如果我们按照模式一来做的话，任何一个结点有故障就会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。我们就考虑这个系统怎么改进。首先是推模式，这肯定是延迟的首要原因，我们要把这个问题解决掉。其次我们的用户越来越多，这个数据库表从一百万到一亿，数据规模不一样处理方式是有差别的。我们第一版单库单表的模式，当用户数量增多的时候，它不能满足就需要进行拆分。第二个是锁表的问题，我们考虑的是更改引擎。另外一个是发表过慢，我们考虑的是异步模式。第二版我们进行了模块化，我们首先做了一个层，做了拆分，最右边的发表做了异步模式。第二个服务层，我们把微博基础的单元设计成服务层一个一个模块，最大是对推模式进行了改进。首先看一下投递模式的优化，首先我们要思考推模式，如果我们做一下改进把用户分成有效和无效的用户。我们一个用户比如说有一百个粉丝，我发一条微博的时候不需要推给一百个粉丝，因为可能有50个粉丝不会马上来看，这样同步推送给他们，相当于做无用功。我们把用户分成有效和无效之后，我们把他们做一下区分，比如说当天登陆过的人我们分成有效用户的话，只需要发送给当天登陆过的粉丝，这样压力马上就减轻了，另外投递的延迟也减小了。

新浪微博技术架构

首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。第一版就是是非常快的，我们可以非常快的实现我们的模块。我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。第一颁的技术细节，典型的LAMP架构，是使用Myisam搜索引擎，它的优点就是速度非常快。另外一个是MPSS，就是多个端口可以布置在服务器上。为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由三种部署方式。我们可以把三个单元部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。这个解决了两个问题，一个是负载均衡，因为每一个单元都有多个结点处理，另外一个是可以防止单点故障。如果我们按照模式一来做的话，任何一个结点有故障就会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。我们就考虑这个系统怎么改进。首先是推模式，这肯定是延迟的首要原因，我们要把这个问题解决掉。其次我们的用户越来越多，这个数据库表从一百万到一亿，数据规模不一样处理方式是有差别的。我们第一版单库单表的模式，当用户数量增多的时候，它不能满足就需要进行拆分。第二个是锁表的问题，我们考虑的是更改引擎。另外一个是发表过慢，我们考虑的是异步模式。第二版我们进行了模块化，我们首先做了一个层，做了拆分，最右边的发表做了异步模式。第二个服务层，我们把微博基础的单元设计成服务层一个一个模块，最大是对推模式进行了改进。首先看一下投递模式的优化，首先我们要思考推模式，如果我们做一下改进把用户分成有效和无效的用户。我们一个用户比如说有一百个粉丝，我发一条微博的时候不需要推给一百个粉丝，因为可能有50个粉丝不会马上来看，这样同步推送给他们，相当于做无用功。我们把用户分成有效和无效之后，我们把他们做一下区分，比如说当天登陆过的人我们分成有效用户的话，只需要发送给当天登陆过的粉丝，这样压力马上就减轻了，另外投递的延迟也减小了。我们再看数据的拆分，数据拆分有很多方式，很多互联网产品最常用的方法，比如说如可以按照用户的UID来拆分。但是微博用户的一个特点就是说大家访问的都是最近的服务器，所以我们考虑微博的数据我们按照时间拆分，比如说一个月发一张表，这样就解决了我们不同时间的惟度可以有不同的拆分方式。第二个考虑就是要把内容和索引分开存放。假如说一条微博发表的地址是索引数据，内容是内容数据。假如说我们分开的话，内容就简单的变成了一种key-value的方式，key-value是最容易扩展的一种数据。比如说一个用户发表了一千条微博，这一千条微博我们接口前端要分页放，比如说用户需要访问第五页，那我们需要迅速定位到这个记录。假如说我们把这个索引拆分成一个月一张表，我们记录上很难判断第五页在哪张表里，我们需要索引所有的表。如果这个地方不能拆分，那我们系统上就会有一个非常大的瓶颈。最后我们想了一个方法，就是说索引上做了一个二次索引，改变我们还是按照时间拆分，但是我们把每个月记录的偏移记下来，就是一个月这个用户发表了多少条，ID是哪里，就是按照这些数据迅速把记录找出来。异步处理，发表是一个非常繁重的操作，它要入库、统计索引、进入后台，如果我们要把所有的索引都做完用户需要前端等待很长的时间，如果有一个环节失败的话，用户得到的提示是发表失败，但是入库已经成功。所以我们做了一个异步操作，就是发表成功我们就提示成功，然后我们在后台慢慢的消息队列慢慢的做完。另外新浪发表了一个很重要的产品叫做MemcacheQ，我们去年做了一个对大规模部署非常有利的指令，就是stats queue，适合大规模运维。第二版我们做了这些改进之后，微博的用户和访问量并没有停止，还有很多新的问题出现。比如说系统问题，单点故障导致的雪崩，第二个是访问速度问题因为国内网络环境复杂，会有用户反映说在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值，MySql复制延迟、慢查询，另外就是热门事件，比如说世界杯，可能会导致用户每秒发表的内容达到几百条。我们考虑如何改进，首先系统方面循序任意模块失败。另外静态内容，第一步我们用CDN来加速，另外数据的压力以及峰值，我们需要将数据、功能、部署尽可能的拆分，然后提前进行容量规划。另一方面我们还有平台化的需求，去年11月我们就说要做开放平台，开放平台的需求是有差异的，Web系统它有用户行为才有请求，但是API系统特别是客户端的应用，只要用户一开机就会有请求，直到他关闭电脑这种请求一直会不间断的过来，另外用户行为很难预测。系统规模在持续的增大，另外也有平台化的需求，我们新架构应该怎么做才能满足这些需要？我们看一下同行，比如说Google怎么样考虑这个问题的？Google首席科学家讲过一句话，就是一个大的复杂的系统，应该要分解成很多小的服务。比如说我们在https://www.360docs.net/doc/2310158160.html,执行一个搜索查询的话，实际上这个操作会调动内部一百多个服务。因此，我们第三版的考虑就是先有服务才有接口最后才有应用，我们才能把这个系统做大。

新浪微博框架

大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。最晚的一次，是12点多收到一个邮件说想了解一下微博底层是怎么构架的。很多技术人员对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家对微博的底层技术有更好的了解。另外不管是做客户端、1.0、2.0、论坛、博客都要考虑架构的问题，架构实际上是有一些共性的。今天我通过讲解微博里面的一些架构，分析一下架构里面哪些共性大家可以参考。首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。第一版就是是非常快的，我们可以非常快的实现我们的模块。我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。第一颁的技术细节，典型的LAMP架构，是使用Myisam搜索引擎，它的优点就是速度非常快。另外一个是MPSS，就是多个端口可以布置在服务器上。为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由三种部署方式。我们可以把三个单元部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。这个解决了两个问题，一个是负载均衡，因为每一个单元都有多个结点处理，另外一个是可以防止单点故障。如果我们按照模式一来做的话，任何一个结点有故障就

会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。我们就考虑这个系统怎么改进。首先是推模式，这肯定是延迟的首要原因，我们要把这个问题解决掉。其次我们的用户越来越多，这个数据库表从一百万到一亿，数据规模不一样处理方式是有差别的。我们第一版单库单表的模式，当用户数量增多的时候，它不能满足就需要进行拆分。第二个是锁表的问题，我们考虑的是更改引擎。另外一个是发表过慢，我们考虑的是异步模式。第二版我们进行了模块化，我们首先做了一个层，做了拆分，最右边的发表做了异步模式。第二个服务层，我们把微博基础的单元设计成服务层一个一个模块，最大是对推模式进行了改进。首先看一下投递模式的优化，首先我们要思考推模式，如果我们做一下改进把用户分成有效和无效的用户。我们一个用户比如说有一百个粉丝，我发一条微博的时候不需要推给一百个粉丝，因为可能有50个粉丝不会马上来看，这样同步推送给他们，相当于做无用功。我们把用户分成有效和无效之后，我们把他们做一下区分，比如说当天登陆过的人我们分成有效用户的话，只需要发送给当天登陆过的粉丝，这样压力马上就减轻了，另外投递的延迟也减小了。

亿级用户下的新浪微博平台架构

亿级用户下的新浪微博平台架构架构之路（系列三）卫向军新浪微博引言新浪微博在2014年3月公布的月活跃用户（MAU）已经达到1.43亿，2014年新年第一分钟发送的微博达808298条，如此巨大的用户规模和业务量，需要高可用（HA）、高并发访问、低延时的强大后台系统支撑。微博平台第一代架构为LAMP架构，数据库使用的MyIsam，后台用的php，缓存为Memcache。随着应用规模的增长，衍生出的第二代架构对业务功能模块化、服务化、组件化，后台系统从php替换为Java，逐渐形成面向服务的SOA 架构，在很长一段时间支撑微博平台业务发展。在此基础上又经过长时间的重构、线上运行、思索与沉淀，平台形成了第三代架构体系。我们先看一张微博的核心业务图（如下），是不是非常复杂，但这已经是一个简化的不能再简化的业务图啦，第三代技术体系就是为了保障在微博核心业务上快速、高效、可靠的发布新产品新功能。第三代技术体系微博平台的第三代技术体系，使用正交分解法建立模型，在水平方向，采用典型的三级分层

模型，即接口层、服务层与资源层，在垂直方向，进一步细分为业务架构、技术架构、监控平台与服务治理平台，接着看一下平台的整体架构图。如上图所示，正交分解法将整个图分解为3*4=12个区域，每一个区域代表一个水平维度与一个垂直维度的交点，相应的定义这个区域的核心功能点，比如区域5主要完成服务层的技术架构，下面详细介绍水平方向与垂直方向的设计原则，尤其重点介绍4、5、6中的技术组件及其在整个架构体系中的作用。水平分层水平维度的划分，在大中型互联网后台业务系统的设计中非常基础，在平台的每一代技术体系中都有体现，这里还是简单介绍一下，为后续垂直维度的延伸讲解做铺垫：接口层主要实现与Web页面、移动客户端的接口交互，定义统一的接口规范，平台最核心的三个接口服务分别是内容（Feed）服务、用户关系服务以及通讯服务（单发私信、群发、群聊）。服务层主要把核心业务模块化、服务化，这里又分为两类服务，一类为原子服务，定义是不依赖任何其他服务的服务模块，比如常用的短链服务、发号器服务都属于这一类，图中使用泳道隔离，表示它们的独立性，另外一类为组合服务，通过各种原子服务和业务逻辑的组合，完成的Composite服务，比如Feed服务、通讯服务除了本身的业务逻辑，还依赖于短链、用户、以及发号器服务。资源层主要数据模型的存储，包含通用的缓存资源Redis和MC，以及持久化数据库存储MySQL、HBase，或者分布式文件系统TFS以及Sina S3服务。水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。

普通微博系统结构

普通微博系统结构 wudi1975@https://www.360docs.net/doc/2310158160.html, 2012.2.1 1.系统概述（此处删除数百字）Balabala讲了一通项目背景，删之毫无鸭梨。 2.系统压力分析和估算微博这种系统特点非常鲜明，那就是非常多的人，非常频繁地使用非常少量的核心功能：发微博、查微博、评论微博、被通知有新微博（被@或者关注引导）。微博的事务性要求非常低，但并发量和数据量极大。 2.1写并发（此处删除数百字）简要估算了一下微博系统的承受压力的目标，结果为：系统长期支持一千的并发，短时间可以支持一万的并发，那么平均每秒产生的数据就是几兆。 2.2读并发参考新浪微博等需要支持大并发、大压力问题的系统解决方案，一开始就采取了把读、写分开的方式来处理数据压力问题，写的压力从业务角度而言比较纯粹，读的压力则比较复杂，涉及的数据量也更大，但是解决的手段也多，下文再详细分析。 3.基本结构新浪微博压力比本系统大，而且其架构已经证明了事实可行，所以，本系统尽可能参考新浪微博的架构。 3.1基本B/S系统三层架构

用户A 浏览器用户B 浏览器用户X 浏览器 ……… 客户界面数据库数据持久化 WEB 服务器业务1业务2业务3 ……… HTTP socket <图2.1> 3.1.1简述如上图2.1所示，这是一个最基本的三层架构的B/S系统。用户通过浏览器访问web站点来进行业务操作，浏览器可以是：IE、google chrome、fireFox 等。被访问的web站点可以是任何形式：php、java、.net等等。客户浏览器与web站点之间的通信是采用http协议(有安全性要求则采用https协议)来实现，这个通信是在广域网进行。 Web站点往往会采用一个MVC框架来组织业务实现，在此，MVC不是重点不再赘述。 Web站点的数据持久化功能会采用一个数据库管理系统来辅助实现，web站点的各种业务模块会通过socket（TCPIP协议的一个实现）工具来实现与数据库的通信。这个通信是在局域网进行。 3.1.2系统瓶颈 B/S系统的瓶颈会出现在以下几个方面： A.用户并发请求太大，导致web服务器无法及时处理完所有请求 B.用户请求的数据量太大，导致web服务器的上行带宽被耗尽 C.业务计算量太大，web服务器cpu被耗尽 D.业务计算产生的中间数据太多，web服务器内存耗尽，cpu时间被消耗在处理缺页中断

新浪微博信息系统分析

蔡航首页功能模块结构功能技术支持; 微博信息系统包括：前台信息显示系统、后台信息管理系统。前者是面向公众的一个窗口，通过前台信息的显示系统方便访问者浏览日志、评论和留言；后者是后台信息管理系统，方便用户发表日志，回复评论和留言、管理日志、评论、及个人信息。人机交互:（以发布微博功能为例）：在对话栏键入内容（可插入表情、图片、视频、音乐）点击发布发布成功首页显示自己的微博（以浏览全部微博为例）：点击图片图片放大点击视频弹出视频框点击评论弹出评论对话框键入评论点击确定发布成功李凯政广场功能模块结构功能图

技术支持：以名人堂为例。经过对微博用户的身份认证，对他们数据归纳处理，细分成娱乐、时尚、生活、体育等不同的圈子，而在娱乐圈下又细分出音乐人、演员、导演等。而微博达人中，以用户的微博的数量、频率和受关注度等数据为依据，需要数据库做支持。人机交互：仅以风云榜为例，点击风云榜风云人气榜草根人气榜用户1 点击关注确定用户 2 取消干广昊微群功能板块结构功能图技术支持：微群主页首先提供搜索微群功能，帮助用户查找加入微群，同时用户自身可以创建微群。加入微群后，用户可以在所在微群中发表微博、讨论话题。消息中心帮助用户管理评论，方便查找和查看。人机交互：（以加入微群为例）在“找微群”中输入关键词 → 点击加入→ 查看群内微博或话题→ 点击发表评论 → 输入内容 → 点击发表→ 发表成功 → 跳回原始页连升应用功能模块

技术支持：用户可以通过“应用”快速找到自己想了解或者去使用的应用方面的功能，实现一个不用查找快速进入各种应用的功能，节省了大量时间和精力。新浪微博网站的管理者，通过每个应用的访问量，适时调整在“应用”这一栏里最直观显示的应用功能，把那些人气较少的放到“更多应用”里，这样来方便用户找到自己喜爱的“应用”。实现这样一个信息的互补。管理员---对每个“应用”里应用功能的统计整理，找到人气最高的几个应用，最直观摆放在“应用”栏下。用户---快速使用“应用”里的一些功能，快速进入页面的切换。人机交互：以相册为例，应用的功能对话框，点击相册，弹出“我的相册”、“相册首页”“我的收藏”等对话框，点击“我的相册”，弹出微博相片，浏览相册。姜龙游戏功能模块游戏介绍：是基于在线服务的一类游戏集合平台。结构功能图技术支持：游戏以小游戏为主。采用开放式的平台运作，即不仅向广大微博开放（前提是注册了微博）各款游戏，而且其对游戏开发者也采用开放的态度，即第三方游戏开发商及其开发的游戏符合相关标准即刻将其开发的游戏上线到微博中运营。游戏的种类有个人性的也有网络互动性的，比如植物大战僵尸和微城市。人机交互：用户在不同的游戏中可以得到不同的升级和肯定方式，其决定于开发商的游戏设置。李康奇找人功能模块结构功能图

从新浪微博看海量数据存储

从新浪微博看海量数据存储 2014-01-05 20:13:34| 分类：实验报告 | 标签：海量存储|举报|字号订阅从新浪微博看海量数据存储一、新浪微博简介及特点（一）新浪微博简介新浪微博是一个由新浪网推出，提供微型博客服务的类Twitter网站。用户可以通过网页、WAP页面、手机客户端、手机短信、彩信发布消息或上传图片。新浪可以把微博理解为“微型博客”或者“一句话博客”。用户可以将看到的、听到的、想到的事情写成一句话，或发一张图片，通过电脑或者手机随时随地分享给朋友，一起分享、讨论；还可以关注朋友，即时看到朋友们发布的信息。（二）新浪微博的特点 1.操作简单，信息发布门槛极低 140个字发布信息，在文字的基础上可以同时上传图片，视频等连接。内容不限制，所见所闻，所思所想，生活琐碎和宏大主题均可发布。 2.平台广泛，随时随地传播信息除了电脑以外，手机的在线发布，使得使用广泛。支持手机等平台，通过手机发布，实现了全息发布方式，真正实现了随时随地发布和接收信息。 3.传播速度快，传播方式呈裂变利用各种转发，名人推荐，媒体合作等，以不同的话题和主题，博得潜在消费人群的关注。新浪微博的传播路径：一个是“粉丝路径”。 A 发布信息后，A 的所有粉丝，都可以实时接收信息；另一个是“转发路径”。如果甲觉得A 的某条微博不错，他可以“一键”转发，这条信息立即同步到甲的微博里，同时，甲的所有粉丝，又都可以实时接收信息，然后以此类推，实现“病毒式”传播。 4. 信息交互简便快捷

除了上面所述的关注和转发功能，新浪微博还有“评论功能”、“回复功能”、“私信功能”，同时每次信息交互产生后给予用户新消息的提示，达到实时交互。这些功能为用户之间的信息交互提供了保证。作为互联网3.0时代的产品，我认为其特点的核心为“微·快”。相比1.0和2.0时代下的网站和博客论坛，微博的发布对用户要求大大降低（无论是所需技术还是时间），发布信息微小符合快速阅读下的“快餐文化”。同时“快”还体现其传播速度之快，常常短时间引发巨大的讨论。二、新浪微博数据库新浪微博的特点决定了其使用的数据库，而且不断增加的用户数和访问量也导致其架构和数据库上的改变。（一）MySQL数据库新浪微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。最开始采用的是推的消息模式。新浪微博首席架构师杨卫华是这么描述的“假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。”第一版的技术细节，典型的LAMP架构（Linux作为操作系统，Apache 和Nginx作为Web服务器，MySQL作为数据库，PHP/Perl/Python作为服务器端脚本解释器），是使用Myisam搜索引擎，它的优点就是速度非常快。后来随着用户越来越多，访问量剧增。每时每刻都有大量的信息被发布，最初的架构就有延迟的问题，而用户需要的是根据关注关系实时投递。后来就有了分片（分库分表）、拆分、异步处理和分布式系统。 1.sharding（分片） Sharding（分片）只用于数据量大同时有性能瓶颈的库，大部分库不进行sharding处理。对于数据量比较大的库，在一开始就考虑sharding策略，例如索引数据和内容数据分开设计，每类数据库根据业务逻辑选择恰当的partitioning key，拆分成一定数量的表。（见图一）然后随着压力的增加进行垂直拆分，垂直拆分后的库再遇到性能瓶颈时首先考虑用硬件来解决。当硬件解决不了时才开始考虑水平拆分。在选择sharding方案时仔细考虑业务逻辑。对于读密集型应用，基本上通过增加slave来解决，对于写密集型应用才进行垂直和水平拆分工作。（图二）

新浪微博架构猜想

新浪微博架构猜想定时轮询服务端，获得几分钟之后：采用Jsonp的方式 STK_*****这些js中的callback的方法是动态生成的

进入页面：直接获得html代码，应该是采用了全页面缓存这里面缓存的是页面的feed，不缓存好友数，头像这些，这些还是通过XHR来获得的动态页面部分静态化点击微博：出现的也是通过content cache过的这里面没有显示粉丝数，关注数，以及每个feed的评论、转载数，根据新浪微博架构的描述，这些是动态变化的，如果这个也缓存，用户体验以及准确度都达不到要求，老是变动会失去缓存的意义，所以，这些是通过XHR去服务端请求的，如下图：

点击粉丝：点击关注采用的技术和点击微博一样，全页面缓存 PS：为什么新浪微博更新（新发表，评论，好友数等），需要手工去点击？因为新浪微博采用了全页面缓存的方式，点击的动作刚好触发去做整个页面缓存。评论：直接返回的是评论内容的HTML，避免页面渲染轮询feed

轮询回来的结果通过STK这个方法，来判断是否有更新，如果都为0，则不更新，否则提示有新的更新，然后让用户点击。返回的是是否有新的评论，新的feed数，可见服务端肯定保存了我当前获得的那条最新记录数，应该是放在vector cache（feed id list）中，架构： To Push or to pull It’S a question 新浪采用了什么技术来实现这个最核心的问题的呢？ Feed架构 Push：

简单，但是当量打的时候，则分发到所有粉丝那边就变得比较麻烦，如小潘同学这种微博控，粉丝数有250w+，他发一条消息，如果采用push，简直就是自虐嘛 Pull：