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

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

架构之路（系列三）卫向军新浪微博

引言

新浪微博在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服务。

水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。

与分层模型对应的，微博系统中的服务器主要包括三种类型：前端机（提供API 接口服务），队列机（处理上行业务逻辑，主要是数据写入），存储（mc、mysql、mcq、redis 、HBase 等）。

垂直延伸技术架构

随着业务架构的发展和优化，平台研发实现了许多卓越的中间件产品，用来支撑核心业务，这些中间件由业务驱动产生，随着技术组件越来越丰富，形成完备的平台技术框架，大大提升了平台的产品研发效率和业务运行稳定性。

区别于水平方向上层依赖下层的关系，垂直方向以技术框架为地基支撑点，向两侧驱动影响业务架构、监控平台、服务治理平台，下面介绍一下其中的核心组件。

接口层WebV4框架

接口框架简化和规范了业务接口开发工作，将通用的接口层功能打包到框架中，采用了Spring的面向切面（AOP）设计理念。接口框架基于jersey 进行二次开发，基于annotation定义接口的URL和参数，并且内置Auth、频次控制、访问日志和降级功能，同时还有自动化的Bean-json/xml序列化接口框架用来支撑接口层平台的监控与服务治理系统。

服务层框架

服务层主要涉及RPC远程调用框架以及消息队列框架，这是微博平台在服务层使用最为广泛的两个框架。

MCQ消息队列

消息队列提供一种先入先出的通讯机制，在平台内部，最常见的场景是将数据的落地操作异步写入队列，队列处理程序批量读取并写入DB，消息队列提供的异步机制加快了前端机的响应时间，其次，批量的DB操作也间接的提高了DB操作性能，另外一个应用场景，平台通过消息队列，向搜索、大数据、商业运营部门提供实时数据。

微博平台内部大量使用的MCQ(Simple Queue Service Over Memcache)消息队列服务，基于MemCache协议，消息数据持久化写入Berkeley，只有get/set两个命令，MCQ有丰富的client library，同时也非常容易做监控（stats queue），在微博线上运行多年，性能比通用的MQ高很多倍。

Motan RPC框架

微博的Motan RPC服务，底层通讯引擎采用了Netty网络框架，序列化协议支持Hessian 和Java序列化，通讯协议支持Motan、http、tcp、mc等，Motan框架在内部大量使用，在系统的健壮性和服务治理方面，有较为成熟的技术解决方案，健壮性上，基于Config配置管理服务实现了High Availability与Load Balance策略（支持灵活的FailOver和FailFast HA策略，以及

Round Robin、LRU、Consistent Hash等Load Balance策略），服务治理方面，生成完整的服务

调用链数据，服务请求性能数据，响应时间（Response Time）、QPS以及标准化Error、Exception 日志信息。

资源层框架

资源层的框架非常多，有封装MySQL与HBase的Key-List DAL中间件、有定制化的计数组件，有支持分布式MC与Redis的Proxy，在这些方面业界有较多的经验分享，我在这里分享一下平台架构的对象库与SSD Cache组件。

对象库

对象库支持便捷的序列化与反序列化微博中的对象数据，序列化时，将JVM内存中的对象序列化写入在HBase中并生成唯一的ObjectID，当需要访问该对象时，通过ObjectID读取，对象库支持任意类型的对象，支持PB、JSON、二进制序列化协议，微博中最大的应用场景将微博中引用的视频、图片、文章统一定义为对象，并抽象出标准的对象元数据Schema，对象的内容上传到对象存储系统（Sina S3）中，对象元数据中保存Sina S3的下载地址。

SSD Cache

随着SSD硬盘的普及，其优越的IO性能被越来越多的替换传统的SATA和SAS磁盘，常见的应用场景有三种：1）替换MySQL数据库的硬盘，目前社区还没有针对SSD优化的MySQL 版本，即使这样，直接升级SSD硬盘也能带来8倍左右的IOPS提升；2）替换Redis的硬盘，提升其性能；3）用在CDN中，加快静态资源加载速度。

微博平台将SSD应用在分布式缓存场景中，将传统的Redis/MC + Mysql方式，扩展为Redis/MC + SSD Cache + Mysql方式，SSD Cache作为L2缓存使用，第一降低了MC/Redis成本过高，容量小的问题，也解决了穿透DB带来的数据库访问压力。

垂直的监控与服务治理

随着服务规模和业务变得越来越复杂，即使业务架构师也很难准确的描述服务之间的依赖关系，服务的管理运维变得越来难，在这个背景下，参考google的dapper和twitter的zipkin，平台实现了自己的大型分布式追踪系统WatchMan。

WatchMan大型分布式追踪系统

如其他大中型互联网应用一样，微博平台由众多的分布式组件构成，用户通过浏览器或移动客户端的每一个HTTP请求到达应用服务器后，会经过很多个业务系统或系统组件，并留下足迹（footprint）。但是这些分散的数据对于问题排查，或是流程优化都帮助有限。对于这样一种典型的跨进程/跨线程的场景，汇总收集并分析这类日志就显得尤为重要。另一方面，收集每一处足迹（footprint）的性能数据，并根据策略对各子系统做流控或降级也是确保微博平台高可用的重要因素。要能做到追踪每个请求的完整调用链路；收集调用链路上每个服务的性能数据；能追踪系统中所有的Error和Exception；通过计算性能数据和比对性能指标（SLA）再回馈到控制流程（control flow）中，基于这些目标就诞生了微博的Watchman 系统。

其系统设计一个核心原则就是低侵入性（non-invasivenss）：作为非业务组件，应当尽可能少侵入或者不侵入其他业务系统，保持对使用方的透明性，可以大大减少开发人员的负担和接入门槛。基于此考虑，所有的日志采集点都分布在技术框架中间件中，包括接口框架、RPC框架以及其他资源中间件。

WatchMan由技术团队搭建框架，应用在所有业务场景中，运维基于此系统完善监控平台，业务和运维共同使用此系统，完成分布式服务治理，包括服务扩容与缩容，服务降级，流量切换，服务发布与灰度。

现在，技术框架在平台发挥着越来越重要的作用，驱动着平台的技术升级、业务开发、系统运维服务，本文限于篇幅限制，没有展开介绍，后续会不断的介绍核心中间件的设计原则和系统架构。

参考资料

正交分解法

jersey框架

weibo-watchman系统

淘宝平台架构师谈海量互联网服务技术架构

林昊，网名BlueDavy，China OSGi User Group Director，淘宝网平台架构部架构师，个人的研究方向主要为Java模块化、动态化系统的构建以及高性能的大型分布式Java系统的构建。曾编写《OSGi实战》和《OSGi进阶》两篇Opendoc，为OSGi 在中国的推广起到了很大的作用。 王速瑜：数据集群问题：当数据增长到一定的数量级，必须要进行分布部署、备份、容灾、切割扩容等工作。请问什么程度的数量级需要分布部署，如何合理分布部署，需要考虑哪些情况？ 林昊：一般来说，也没有固定的数量级，通常是根据硬件资源的状况以及所能接受的性能状况（例如一次查询必须在3ms内完成）来决定。当达到性能瓶颈时，通常需要进行数据的拆分或备份等策略，在这个过程中最需要考虑的，就是对应用的影响程度，因此通常会需要一个强大、透明的数据层，以屏蔽数据的拆分或备份、迁移操作给应用带来的影响，另外一方面就是应尽量能做到不停机完成。当然，这很难，因为需要面对多套数据结构并存、数据冗余和同步等问题。 王速瑜：数据备份问题：对于大容量的数据备份，技术上如何做到不影响正常的服务？如何合理制定冷备、热备的实施策略、方式、时间段？在数据损坏、主服务器硬件损坏等故障情况下，如何最短时间内监控到故障并调度请求到备份服务器等容灾措施？ 林昊：对于大容量的数据备份，技术上来说：多数情况下比较好的是选择异步消息通知实现数据备份，或基于高端数据库的特性（例如Oracle的Standby）。对于冷备、热备的实施，原则要求均为不影响正常业务功能，因此可选的时段只能是系统访问量较低的时段。方式则需要根据数据量以及备份的速度来决定，多数均为采取相对高频率的进行热备，低频率的进行冷备；在数据损坏、主服务器硬件损坏等故障时，要做到尽快切换，就必须依赖强大的及时监控系统，在主服务器不可用时能够做到迅速报警。最理想状况就是能够有一种机制，自动切换备库为主库，并通知所有应用转换为连接和使用新的主库，如果做不到自动的话，这个过程就仍然得基于“人肉”来进行操作了。 王速瑜：开放平台设计问题：开放平台API设计中，调用协议设计时有哪些考虑要求？对于请求类的调用协议设计，倾向于call?A=a&B=b这种方式（这种方式对调用者比较方便，但对二进制的传输有一定限制，比如上传图片等），还是基于纯文本的方式，比如WSDL、XML等？对用户鉴权的Token机制是怎样的？有没有对接入方进行QoS的考虑，是怎么做的? 林昊：对于开放平台而言，基本上目前Facebook引领了开放平台的技术，因此在协议上多数都采用Http，接口的设计上则都倾向于REST风格；对于用户鉴权的Token机制上通常都是采用一个公私钥的匹配方式，并且此Token一定是由开放平台公司所提供；开放平台中是肯定会对接入方的QoS有限制的，并且这通常也影响到了开放平台的收费标准，在实现时多数采用基于缓存进行实时费用计算，这点更强的应该是电信行业。: 王速瑜：跨IDC部署程序模块在业务发展到一定阶段后在所难免，跨IDC的专线资源相对有限。架构师该如何合理规划和使用同城、跨城的专线进行传输数据，以及专线意外中断的容灾措施？ 林昊：跨IDC部署确实会存在很高的技术难度，部署结果的验证是最为关键的地方，其次是部署所耗费的带宽成本和时间成本，对于部署结果验证而言，通常可采用的方法为业务脚本的测试；对于部署所耗费的带宽成本而言，通常需要借助多播技术，对于时间成本而言，通常需要借助自动化的部署系统。 王速瑜：Web2.0网站的海量小文件的存储，如用户头像、相册微缩图等文件，这些文件的特点是尺寸小（100KB以内），数量巨大（数以百万计），这些文件的存储、读取、备份都是问题，请问您是如何提供具体解决方案的？

新浪微博技术

中国首届微博开发者大会在北京举行，这是国内微博行业的首场技术盛宴。作为国内微博市场的绝对领军者，新浪微博将在此次大会上公布一系列针对开发者的扶持政策，以期与第三方开发者联手推动微博行业的整体发展。图为微博平台首席架构师杨卫华演讲。 以下为演讲实录： 大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。最晚的一次，是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.wendangku.net/doc/7c3643133.html,执行一个搜索查询的话，实际上这个操作会调动内部一百多个服务。因此，我们第三版的考虑就是先有服务才有接口最后才有应用，我们才能把这个系统做大。

新浪微博分析报告

新浪微博分析报告

新浪微博分析报告 新浪微博加粉丝,完善个人资料。最好用自己的真实姓名（或有趣的匿名）、真实的头像（美女、帅锅或有趣的头像）、个人介绍（可以是搞笑的吸引人的）。真实的信息让人觉得更可信，会大大提高被收听的几率。 通过微博第三方应用（狠狠转、互粉大厅、粉丝大师、互粉加加、互粉小助手、推兔、爱互粉、推兔互粉等。。。）来添加粉丝数量。最好不要用软件，软件刷的粉丝大多是死粉，且用软件刷还很容易被封号。 我发现想让一个人转发或评论你的微博不是件容易的事。首先微博必须有看点（让别人有耐心看下去）、笑点（让别人对你产生兴趣）、创意（让别人新鲜有趣），或者有活动优惠（大部分网民是爱贪便宜的）。且不要刷屏，网民是很反感刷屏的，所以一天发3~5条微博就差不多了。多参加一些热点话题的讨论，尽量把自己的曝光度提升。如：我申请了#第三代搜索技术#这个话题的主持人，那么怎么推广呢？

我们可以点击微博下面的推广， 也可以通过狠狠转的“我要转发”，其他第三方应用也有这项功能， 也可以借助热门话题的力量进行宣传

借助话题，如：#第三代搜索技术#话题镶入#360#、#360好搜#、#奇虎360#等这些热门话题中，从而有了间接的关系，我们可以这样做：这就是借助引流方式。

添加相应的标签，有助于网民的搜索 还有就是借助其他渠道宣传，qq、微信、论坛、软文等。。。。推广方式很多，我也不多说了。 针对一个兴趣（或一个产品）来发布微博，如果每天都发不同的兴趣（或产品）那样会损失一批粉丝。明星就可以不在乎这些，但我们不是，所以要多多与网民互动，培养信任度，这样也有助于提高网民的转帖效率。 微博营销，也就是社会化媒体营销，同微信、论坛、博客、sns社区是一样的，他们不同于其他传统营销，它们的内容都是由用户自愿提供的，而不是直接的雇佣关系，这个就需要社交思维。这种营销方式广泛，易于流行。我们可以从微博、论坛寻找潜在用户，让其进入微信进行一对一交谈，从而成为精确用户进行维护。 最近了解到微博在2014.04月份采取了措施，在微博发微信二维码、微信公众号会被删或封号等

新浪微博框架

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

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

新浪微博研究报告

新浪微博研究报告 前言：这份报告是对新浪微博的全方位解读。新浪目前已经在微博领域赢得先发优势，在用户数量上正试图与腾讯相抗衡，不过在公司营收上，其最大竞争对手是百度。我们给予新浪微博20亿美元估值，并认为其将挑战腾讯在社交应用领域的霸权。腾讯在规模上有优势，但是新浪在影响力上占了上风。与此同时，我们维持新浪“持有”评级，但是将其目标价上调最高至80美元。在中国新一轮SNS爆发期，我们认为腾讯将在营收上领先于新浪。 摘要：不到一年时间，已经有14%的中国互联网用户使用微博，其中新浪的市场份额接近87%，腾讯接近8%（附1） 新浪目前正遭到腾讯全产品线的围攻，在综合六类互联网社交沟通产品的整体市场份额对比中，腾讯占有88%份额，但新浪只有2%； 我们对新浪微博估值为20亿美元。估值的一半依据来自广告收入，另一半依据增加用户活跃程度所带来的营收；但是这样一来会造成对新浪自身其他板块的营收总体照成20%的减额。 如果以40x2011PE（36x ex-cash）衡量，新浪已经很贵；但以28x2012PE（24x ex-cash）估算，新浪股价将是合理的。 研究正文（共分为九大部分） 1.按浏览时间衡量新浪微博占87%市场份额 自新浪推出微博产品一年后，中国已有14%的互联网用户使用微博服务，在中国最常用网络应用程序中排名第16位。2010年中国微博用户增加5倍，总浏览时间增加11倍。在移动互联网领域，微博的上述市场份额更高。按总浏览时间衡量，新浪微博以87%份额居统治地位，按活跃用户数衡量，新浪微博的市场份额为54%（2010年11月数据）。新浪将继续引领微博产品的创新。 新浪推出微博产品后的股价表现注：以下图片如无特殊说明，均来自MIRAE ASSET 2.新浪微博与腾讯的整体数据对比 单纯对比新浪微博与腾讯微博的做法并不可取。正确的方法应该是对比新浪微博与腾讯Qzone，腾讯Qzone目前也是腾讯全社交战略（total SNS）的核心。腾讯全社交战略（total SNS）包括博客、IM、邮箱、BBS、SNS以及最新发布的免费短信应用微信（Kik），此战略的目的是提供一站式平台服务，满足网络用户的各种在

新浪架构师谈微博架构

微博(Micro-Blog)顾名思义是微型博客，是一种基于用户关系的信息分享和传播平台,用户可通过浏览器、手机、及时通讯软件(MSN、QQ、Skype等)及外部API接口等多种渠道发布140字以内信息[1]。支持跨平台交流、与移动设备无缝连接的技术优势,饱含Web2.0特质。 有这么一道题- 微博数据库设计：有A,B,C3个用户，A关注C，C关注A和B；A,B更新后C会收到信息提示,比如： 2010-11-16 22：40 用户A 发表a1; 2010-11-16 22：41 用户A 发表a2; 2010-11-16 22：42 用户A 发表a3 2010-11-16 23：40 用户B 发表b1; 2010-11-16 22：40 用户B 发表b2; 问题1：如何设计数据表和查询？ 问题2：如果C关注了10000个用户，A被10万个人关注，系统又该如何设计？ 问题1，我的解答是：设计两张表，一张用于表示用户user，有ID,用户名(username)，发布内容（message），发布时间(time)等字段；另一张表用于表示用户之间关注，有ID，用户名(username)，关注的用户名，开始关注时间等字段。回去想了想，发现如果数据表照我这样设计的话，问题2的情况就会产生大量的数据，但如果把关注的用户都写在一个记录里那样字符串可能会更大。所以想听听诸位达人的意见，如果是你们会怎样设计数据表呢？ 问题1简单而且随意，直接跳过，估计面试的人都不会看。问题2的困难在于： 第一点.C关注的用户太多，设计上必须在显示C的页面的过程中，避免去数据库查询所有被关注的用户是否有更新。 第二点.第二点.A被关注的人太多，设计上必须在A更新的时候，避免去通知所有关注…… 为避免不必要的复杂连接关系，最好还是设计符合第三范式的关系数据。 我想至少应该设计三张表，分别是： 用户表user：ID，username...； 关注关系表attention: ID->ID； 发布信息表in fo：ID->message； 三张表的设计是比较规范的，至于用户和关注之间的关联要看需求，做join也可以，做DataMap也可以。 个人觉得，需要的逻辑关系在哪儿，而且要进数据库，想不数据量大都不行。当然关注可以不做在一张表中也是一个选择，按关系类型分开走，可以减少特定需求的查询量。 这玩意得丢内存里头吧memcached 发新的话题的话丢队列里头写数据库去 user { befollow[0...n]; post[0...n]; topics[0..n]; } 然后，user[befollow[k]].topics=current_user.topics[j]; 用户只要检查topics就好了要不每次上来来个join什么的，估计数据库就挂了

微博调研报告

微博调研报告 微博自从2007年开始兴起，2010年是微博在中国高速发展的一年，2011年中国的微 博依旧是受欢迎的服务，但总的增长速度有所降低，甚至是有所下降，这说明微博服务经 过一两年的高速发展之后开始逐步进入平稳期。纵观微博的发展，可以说微博已经改变了 传统的媒体和信息传播模式，带动了公众数字化发展的潮流。 国内新浪和腾讯微博现状 4月6日，DNG数据调研中心发布2011一季度国内微博调研报告，报告称国内微博形 成两大阵营，新浪和腾讯居第一阵营，在人气榜、媒体影响力和基于微博开放平台应用软 件等三方面都处于领先地位；搜狐和网易处于第二阵营，全面落后于第一阵营。以目前的 状况来看，微博的霸主地位将在新浪和腾讯之间展开争夺已是无可争辩的了。 据报告显示，在人气榜方面，腾讯凭借其强大的QQ用户群，排行榜首的刘翔粉丝数已达1400万之多，居于领先地位，新浪微博排行榜首的姚晨粉丝数为700多万，处于追赶地位：在媒体影响力方面，DNG选择李泽楷和梁洛施分手、大S和汪小菲结婚、利比亚战争 和日本地震等四大热门事件作为参考指标。从博友围观来看，新浪凭借着自身的新闻优势 仍然有优势，但优势地位在缩减。在前三个事件中，新浪微博仍然居于第一位，腾讯则在 日本地震事件中超越了新浪。按照这样的趋势，腾讯微博媒体影响力可能会超越新浪微博；在基于微博开放平台应用软件方面，新浪凭借其动手早和强大品牌知名度，无论是在软件 数量还是种类上都居于第一位。而在日前bShare公布的2011年3月份社会化分享量排行 榜单中，腾讯微博上升了一名，赶过开心网成为新科第4名，新浪微博位居于第2位，QQ 空间依旧是平台里的老大。有分析称，腾讯微博和新浪微博谁将会成为最终的霸主，今年 之内应该会有答案。 微博产生和流行的原因 微博产生的原因 现代社会，人们追求个体自由，市场经济也需要能够独立选择的个体存在，才能实现 价值的交换。人们摆脱了封建社会的族群、出身和等级。此外，启蒙运动之后，神学日渐 式微，人们的理性和科学精神日益增强，这就是马克斯@韦伯所说的“祛魅”，一切形而上的神灵都作为迷信人们抛弃，人们为了自由不愿意受宗教的束缚。然而，自由却给人们带 来了另外的困境，按照弗洛姆的思想，在这个世界中，只有过去和死亡是确定的，而其余 一切都是不确定的，变化无常的。个体化使“孤独日益加深”，而且个人的欲望不断滋生 但现代社会却无法满足所有个人的欲望，个人面对强大世界的危险自能独自承担。也就是说，人摆脱了束缚，获得了自由，但却没有自决的能力来驾驭这种自由。“解决个体化的 人与世界关系的唯一可能的创造性方案是：人积极地与他人发生联系，以及人自发地活动——爱与劳动。”（弗洛姆《逃避自由》）人们需要广泛的归属感，认同感，而事实上， 身边的同事是竞争关系，家人虽然有亲情在，然而却未必是知心人。所以，网络的交流就 成为了主流了。QQ、SNS交友网站只能小范围的和人交流，而博客却需要写长篇的文章， 并且要用电脑。在繁忙的社会生活中，人们大多没有时间和精力来进行长篇大论，但又想 将自己的灵感和思想公之于众。所以微博的产生为我们提供了一个很好的渠道。现在，手 机的WAP、3G业务日益发达，微博可以用手机发布，这种“公开的短信“就理所当然地成

新浪微博的品牌影响力分析

新浪微博的品牌影响力分析 一、关于新浪微博 （一）、微博的含义和起源 微博，即微博客的简称，是一个基于用户关系的信息分享、传播以及获取平台，用户可以通过WEB、WAP以及各种客户端组建个人社区，以140字左右的文字更新信息，并实现即时分享。①根据尼尔森在线研究的《中国社交媒体受访用户研究报告》，中国目前主流社交媒体中，微博发展最快，覆盖率远高于排名第二位的SNS（社交网站）。 微博起源于美国，埃文·威廉姆斯于2006年创建Obvious公司，并推出了Twitter服务，在最初阶段，这项服务只是用于向好友的手机发送文本信息。随着微博的不断发展和Twitter服务的升级，Twitter在社会生活的各个方面发挥着举足轻重的作用。2008 年奥巴马选举事件，让 Twitter 成功的进入到政治领域，成为政客们与民众交流与表现的平台。美国歌手迈克尔·杰克逊在家中死亡的消息，在Twitter上一经发出，也引起了全世界的关注。随着Twitter 的逐渐壮大，2009 年Obvious公司相继推出了西班牙语、法语、意大利语和德语的 Twitter 版本。Twitter 的迅猛发展也为其一轮轮的融资提供了最有利的数据说服力。（二）、新浪微博简介 随着Twitter 在国外的迅猛发展，国内的微博市场也逐渐被重视和开发。新浪微博于2009年8月14日开始内测。9月25日，新浪微博正式添加了@功能以及私信功能，此外还提供“评论”和“转发”功能，供用户交流。经过不断发展，新浪微博推出了一系列新产品和新功能，包括广场、应用、游戏、微群、微刊等等。2012 年 1 月 5 日，新浪还推出“悄悄关注”的功能，为微博用户提供了更加人性化的功能服务。近期，新浪微博又推出升级版，增加了“喜欢”等功能，扩充了页面内容，旨在进一步优化用户体验。 （三）、新浪微博发展现状 ①微博，https://www.wendangku.net/doc/7c3643133.html,/view/1567099.htm，百度百科

Java系统架构师【面试题】

Java系统分析/架构师面试题 【专业知识相关】 1、谈谈对OOP、IOC、AOP的设计理念的理解； 2、谈谈对主流的J2EE框架（Spring、Struts、Ibatis、Hibernate等）；这 些框架的局限性在哪儿？在何种情况下会不适合用这些框架？ 3、关于J2EE方面开发方面，说出前、后端的设计模型； （提示：比如前端的MVC框架，Axis，Ext，JQuery，Flex等，后端的Ejb，Spring，IOC，AOP，JMS，JNDI，RMI，以及负载均衡等） 4、什么是SOA，ROA？谈谈两种技术的原理及适用场景； 5、说说JVM原理，内存泄露与溢出的区别，何时产生内存泄露？ 6、谈谈JAVA通信方面相关知识，以及大项目之间通信方案； 【软件架构、服务器、中间件相关】 7、谈谈架构师的职责有哪些？ 8、软件设计领域，有哪些设计模式，你常用的几种设计模式；各个设计模式 有哪些优缺点，适应哪些场景； 9、谈谈你日常用的几种WEB服务器、中间件的相关特性及优缺点； 10、如果要设计一个搜索引擎，像Google那样只有两个页面，要求性能最大 化，Web方面应该如何设计？（不需要考虑搜索的逻辑） 11、企业级应用有哪些特殊要求？在何种情况下我们不需要考虑这些要求？ 12、谈谈你现在做技术最大的困惑是什么？ 13、描述一个你感觉最成功的一次架构案例? 14、怎么做到系统整合? （提示：A、通过代码的整合方式，使用相同的数据库。B、通过SSO方式，可以是异构数据库.） 15、浅谈一下负载均衡的原理? 16、怎么处理权限分配?有几种权限分配模型?（提示：目前流行的三种： A、自主型访问控制； B、强制型访问控制； C、基于角色的访问控制RBAC）【数据库方面】

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

亿级用户下的新浪微博平台架构 架构之路（系列三）卫向军新浪微博 引言 新浪微博在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服务。 水平分层有一个特点，依赖关系都是从上往下，上层的服务依赖下层，下层的服务不会依赖上层，构建了一种简单直接的依赖关系。

新浪微博分析报告

新浪微博分析报告 新浪微博加粉丝,完善个人资料。最好用自己的真实姓名（或有趣的匿名）、真实的头像（美女、帅锅或有趣的头像）、个人介绍（可以是搞笑的吸引人的）。真实的信息让人觉得更可信，会大大提高被收听的几率。 通过微博第三方应用（狠狠转、互粉大厅、粉丝大师、互粉加加、互粉小助手、推兔、爱互粉、推兔互粉等。。。）来添加粉丝数量。最好不要用软件，软件刷的粉丝大多是死粉，且用软件刷还很容易被封号。 我发现想让一个人转发或评论你的微博不是件容易的事。首先微博必须有看点（让别人有耐心看下去）、笑点（让别人对你产生兴趣）、创意（让别人新鲜有趣），或者有活动优惠（大部分网民是爱贪便宜的）。且不要刷屏，网民是很反感刷屏的，所以一天发3~5条微博就差不多了。多参加一些热点话题的讨论，尽量把自己的曝光度提升。如：我申请了#第三代搜索技术#这个话题的主持人，那么怎么推广呢？ 我们可以点击微博下面的推广， 也可以通过狠狠转的“我要转发”，其他第三方应用也有这项功能， 也可以借助热门话题的力量进行宣传

借助话题，如：#第三代搜索技术#话题镶入#360#、#360好搜#、#奇虎360#等这些热门话题中，从而有了间接的关系，我们可以这样做：这就是借助引流方式。 添加相应的标签，有助于网民的搜索

还有就是借助其他渠道宣传，qq、微信、论坛、软文等。。。。推广方式很多，我也不多说了。 针对一个兴趣（或一个产品）来发布微博，如果每天都发不同的兴趣（或产品）那样会损失一批粉丝。明星就可以不在乎这些，但我们不是，所以要多多与网民互动，培养信任度，这样也有助于提高网民的转帖效率。 微博营销，也就是社会化媒体营销，同微信、论坛、博客、sns社区是一样的，他们不同于其他传统营销，它们的内容都是由用户自愿提供的，而不是直接的雇佣关系，这个就需要社交思维。这种营销方式广泛，易于流行。我们可以从微博、论坛寻找潜在用户，让其进入微信进行一对一交谈，从而成为精确用户进行维护。 最近了解到微博在2014.04月份采取了措施，在微博发微信二维码、微信公众号会被删或封号等危险，但还可以在朋友圈上发。 微博是一个很大的用户圈，如果想建立品牌，采用微博、微信、论坛、博客、sns社区宣传然后再加上在猪八戒发条任务，那样基本整个网络都是我们的信息。

新浪微博市场调查报告

课题名称：在校大学生新浪微博使用情况调查 班级：20104171 市场营销 成员：刘洋杨靖赟赵青陈晓东曹有利詹聪明雷斯豪 指导老师：张雄林

在校大学生新浪微博使用情况调查报告 一、调查背景： 近年来，随着信息技术的迅猛发展，互联网开始构筑起一种全新的工作，学习和生活方式，成为重要的信息平台和交流工具。社交网络已经成为大学生课余生活的重要内容。社交网络缩小了人与人之间的距离，交流越来越便利，日益改变着我们的生活方式、学习及工作方式。大学生作为信息时代最活跃的人群，已经成为社交网络使用的主要用户。微博，作为社交网络的领军平台，同时作为一种自由表达、分享和交流的工具，近两年来，在中国已得到飞速发展。以目前领先的新浪微博为例，拥有超过3亿注册用户、超过30万认证用户，其中有13万多家企业与机构账户。微博在舆论、资讯等方面有着越来越强大的影响力已经成为共识，说“微博改变世界”毫不夸张，至少在中国得到了很大程度上的证实！我们看到越来越多的政府、商业机构把微博作为对外的一个窗口。 大学生作为接受新鲜事物最快的一个族群，这场科技推动社会进步的盛宴自然也少不了他们。那么在校大学生使用微博的状况如何？微博对他们而言意味着什么？为了进一步了解在校大学生的新浪微博使用情况，我们组织了此次市场调研。 二、调查目的： 为了解大学生微博使用情况，促进微博的改善，促进大学生积极理智地使用微博。同时也就对于大学生使用微博该注意什么进行分析，并对提高大学生微博的使用提出有关的见解。因此，我们希望通过科学客观的方法对大学生微博情况进行系统的调查，得出一定的数据进行分析，并提出相关的对策。 大学生对于微博的使用情况。大学生对于微博的满意度及改进意见。微博可以发挥什么样的营销价值？微博作为新的数字化浪潮显现出来的时候，它会带来什么样的营销机会？ 三、调查方法——问卷调查（发放网络问卷） 四、调查对象：在校大学生新浪微博用户 五、研究方法——定量研究 样本容量：共发放问卷100份，有效问卷99份，1份无效问卷 男女比例如下图： 六、结果分析 （1）新浪微博使用基本情况

普通微博系统结构

普通微博系统结构 wudi1975@https://www.wendangku.net/doc/7c3643133.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点至6点之间，这时候我们大多数的人都处于睡觉阶段，所以微博数量自然会相对较少很多。而在早上6点之后，发微博的数量明显在上升，到九点和十点左右才开始缓慢减少，小编认为这与大多数人在9点到10点之后开始正式工作时有一定的关联的，而在此之前上班族会利用上班路上的时间浏览或者发微博。再到晚上十点的时候出现一个小高峰，晚上十点之后微博数量开始减少，这时候大概很多人开始睡觉休息了。大家别小看了这么一个小图线，其实它也一定程度反映了我们的作息时间。 2.哪个月份出生的人最多？ 从图中的信息，我们可以看到微博用户信息上显示在1月，8月和10月这三个月出生的人数比较多，而在四月份出生的人数最少。对于一月份出生的人数较多这个问题，小编认为有很大程度是受很多人在填写用户信息的时候使用了默认的1900-01-01这个日期的影响，事实我们在处理数据是也证明了这一点。而对于八月和十

月出生的人数较多，根据十月怀胎往前推，刚好差不多是十一和春节的时候，这是时候大多数的夫妻都有假期在家团聚的，从宏观上来说怀孕生小孩的概率自然是相对偏高的。 3.微博用户的年龄分布 说完出生月份，这一个就要看一看微博用户人群的年龄分布了。从图中我们可以看出，微博用户的主力军还是属于80后和90后的年轻人。最多的用户是1993年，而在1990年出生的微博用户会剧减，本文认为是由于1991年是羊年，而民间有个说法：“十羊九不全”，有可能是因为类似这样的原因有些家庭不愿意在羊年生小孩，但“十羊九不全”这种说法只是迷信的表现，并没有任何依据可以说明羊年出生的小孩命运不好，所以大家要相信科学呀。 4.微博用户的所在地分布

新浪微博整体分析

新浪微博分析 微博又叫微博客 (micro blog)，是微型博客的简称，基于web2.0技术的即时信息发布系统。是一个基于用户关系的信息分享、传播以及获取平台，用户可以通过WEB、WAP以及各种客户端组件个人社区，以140字左右的文字更新信息，并实现即时分享。与传统博客相比，以“短、灵、快”为特点。140字左右的文字更新信息，并实现即时分享。微型博客可分为两大市场，一类是定位于个人用户的微型博客，另外一类是定位于企业客户的微型博客。微博客是信息日益碎片化的必然结果。“围脖”是微博客的谐音，所以微博也称围脖。微博客的代表性网站是美国的Twitter，是最早也是最著名的微博，这个词甚至已经成为了微博客的代名词。新浪作为中国最大的门户网站之一，2009年八月新浪推出新浪微薄测试版，成为门户网站第一家提供微薄服务的网站，微薄正式进入中文上网人群视野！ 一、新浪微薄发展背景 Web2.0时代。新的媒体形态层出不穷，每一个新媒体形式的出现都意味着Web2.0的普及和网络的进步。进入2010年，Web2.0更是狂飙突进，中国网民的参与度和活跃呈现爆炸式增长，这一情况的出现，与一种新媒体形态的诞生不无关系—微博。 网络与传统的博客相比，微博发布更便利、传播更迅速，发布字数限制在140字之内，方便用户通过电脑、手机等多平台浏览发布，所发布信息是传达，并可一键转发。微博相比传统博客那种需要考虑文题、组织语言修辞来叙述的长篇大论，以“短、灵、快”为特点的“微博”几乎不需要很高成本，无论你是用电脑还是手机，只需三言两语，就可记录下自己某刻的心情、某一瞬的感悟，或者某条可供分享和收藏的信息，这样的即时表述显然更加迎合我们快节奏的生活。微博微博客草根性更强，且广泛分布在桌面、浏览器、移动终端等多个平台上，有多种商业模式并存，或形成多个垂直细分领域的可能。微博更符合现在人的生活节奏和习惯。而新技术的运用使得用户更容易对访问者者留言进行回复，从而形成良好的互动关系。导致微博时代快速来临。微博已经成为门户网站标志性产品。 二、新浪微博SWOT分析 （一）概述 相对于新浪微博而言，Twitter诞生的更早，而业界中也一直有人认为新浪微博是Twitter的模仿者，但从双方对产品的定位、关注的业务特征、采取的发展策略以及总体的经营思路而言，新浪微博可以被认为是一个包含了Twitter 相关功能的新平台，其更为强调的是自身的媒体特性，以及服务于社交的目的。而Twitter期初更多的是，将传统手机短信息服务转换为以互联网载体的一个形式转换。应该说新浪微博与Twitter之间不存在谁模仿谁的问题，虽然双方都在