sina微博架构

新浪科技讯 11月16日下午消息，由新浪微博(https://www.sodocs.net/doc/247155246.html,)主办的中国首届微博开发者大会在北京举行，这是国内微博行业的首场技术盛宴。作为国内微博市场的绝对领军者，新浪微博将在此次大会上公布一系列针对开发者的扶持政策，以期与第三方开发者联手推动微博行业的整体发展。

以下为演讲实录：

大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。最晚的一次，是12点多收到一个邮件说想了解一下微博底层是怎么构架的。很多技术人员对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家对微博的底层技术有更好的了解。另外不管是做客户端、Web

1.0、Web

2.0、论坛、博客都要考虑架构的问题，架构实际上是有一些共性的。今天我通过讲解微博里面的一些架构，分析一下架构里面哪些共性大家可以参考。

首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了3个大的版本。第一版就 LAMP架构，优点是可以非常快的实现我们的系统。我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。我们第一版采用的是推消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息存成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。第一版的技术细节，典型的LAMP架构，是使用MyISAM 搜索引擎，它的优点就是速度非常快。另外一个是MPSS，就是多个端口可以布置在同一服务器上。为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由2种部署方式。我们可以把三个单元分别部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。我推荐第2种方法。这个方法解决了两个问题，一个是负载均衡，因为每一个单元都有多个节点处理，另外一个是可以防止单点故障。如果我们按照模式1来做的话，任何一个节点有故障就会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。

我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。我们技术上碰到几个问题。第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多系统需要处理很长时间。另外系统在处理明星用户发表时系统繁忙可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。我们就考虑这个系统怎么改进。首先是推模式，这肯定是延迟的首要原因，我们要把这个问题解决掉。其次我们的用户越来越多，这个数据库表从一百万到一亿，数据规模不一样处理方式是有差别的。我们第一版单库单表的模式，当用户数量增多的时候，它不能满足就需要进行拆分。第二个是锁表的问题，我们考虑的是更改引擎。另外一个是发表过慢，我们考虑的是异步模式。

第二版我们进行了模块化，我们首先做了一个分层，最底层叫基础层，首先对数据做了拆分，图上最右边是发表做了异步模式。第二个服务层，我们把微博

基础的单元设计成服务层一个一个模块，最大改进是对推模式进行了改进。首先看一下投递模式的优化，首先我们要思考推模式，如果我们做一下改进把用户分成有效和无效的用户。我们一个用户比如说有一百个粉丝，我发一条微博的时候不需要推给一百个粉丝，因为可能有50个粉丝不会马上来看，这样同步推送给他们，相当于做无用功。我们把用户分成有效和无效之后，我们把他们做一下区分，比如说当天登陆过的人我们分成有效用户的话，只需要发送给当天登陆过的粉丝，这样压力马上就减轻了，另外投递的延迟也减小了。

我们再看数据的拆分，数据拆分有很多方式，很多互联网产品最常用的方法，比如说如可以按照用户的UID来拆分。但是微博用户的一个特点就是说大家访问的都是最近的数据，所以我们考虑微博的数据我们按照时间拆分，比如说一个月放一张表，这样就解决了我们不同时间的维度可以有不同的拆分方式。第二个考虑就是要把内容和索引分开存放。假如说一条微博发表的uid,

微博id是索引数据，140个字的内容是内容数据。假如我们分开的话，内容就简单的变成了一种key-

value的方式，key-value是最容易扩展的一种数据。索引数据的拆分具有挑战，比如说一个用户发表了一千条微博，这一千条微博我们接口前端要分页访问，比如说用户需要访问第五页，那我们需要迅速定位到这个记录。假如说我们把这个索引拆分成一个月一张表，我们记录上很难判断第五页在哪张表里，我们需要加载所有的索引表。如果这个地方不能拆分，那我们系统上就会有一个非常大的瓶颈。最后我们想了一个方法，就是索引上做了一个二次索引，把每个月记录的偏移记下来，就是一个月这个用户发表了多少条，ID是哪里，就是按照这些数据迅速把记录找出来。

异步处理，发表是一个非常繁重的操作，它要入库、统计索引、进入后台，如果我们要把所有的索引都做完用户需要前端等待很长的时间，如果有一个环节失败的话，用户得到的提示是发表失败，但是入库已经成功，这样会带来数据不一致问题。所以我们做了一个异步操作，就是发表成功我们就提示成功，然后在后台慢慢的消息队列慢慢的做完。另外新浪发表了一个很重要的产品叫做MemcacheQ，我们去年做了一个对大规模部署非常有利的指令，就是stats

queue，适合大规模运维。

第二版我们做了这些改进之后，微博的用户和访问量并没有停止，还有很多新的问题出现。比如说系统问题，单点故障导致的雪崩，第二个是访问速度问题因为国内网络环境复杂，会有用户反映说在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值，MySql复制延迟、慢查询，另外就是热门事件，比如说世界杯，可能会导致用户每秒发表的内容达到几千条。我们考虑如何改进，首先系统方面允许任意模块失败。另外静态内容，第一步我们用CDN 来加速，另外数据的压力以及峰值，我们需要将数据、功能、部署尽可能的拆分，然后提前进行容量规划。

另一方面我们还有平台化的需求，去年11月我们就说要做开放平台，开放平台的需求是有差异的，Web系统它有用户行为才有请求，但是API系统特别是客户端的应用，只要用户一开机就会有请求，直到他关闭电脑这种请求一直会不间断的过来，另外用户行为很难预测。

系统规模在持续的增大，另外也有平台化的需求，我们新架构应该怎么做才能满足这些需要？我们看一下同行，比如说Google怎么样考虑这个问题的？Google首席科学家讲过一句话，就是一个大的复杂的系统，应该要分解成很多小的服务。比如说我们在https://www.sodocs.net/doc/247155246.html,执行一个搜索查询的话，实际上这个操作会调动内部一百多个服务。因此，我们第三版的考虑就是先有服务才有接口最后才有应用，我们才能把这个系统做大。

现在我们看一下第三版，首先我们把底层的东西分成基础服务，基础服务里面有分布式的存储，我们做了一些去中心化、自动化的操作。在基础服务之上有平台服务，我们把微博常用的应用做成各种小的服务。然后我们还有应用服务，这个是专门考虑平台各种应用的需求。最上面我们有

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我们可以理解成它就是一个RAM存储。

一个好的架构还需要举行高可用性。我们看一下业界的指标，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里面。假如说我们不做持久化，因为我们推送数据也不能丢失，我们就要写一个很复杂的程序，将数据异步去存，这样

就会非常复杂，而且系统也会有不稳定的因素。从另外一个角度来说，我们做持久化也是做过测试的。我们推送整个流程可以做到100毫秒和200毫秒之间，就是说我们在这个时间能把数据推送出去。

我们再看一下内部细节，就是我们收到数据之后首先要经过最上面RECEIVER。然后推到我们的引擎里面，这个引擎会做两个事情，首先会把用户的关系拿过来，然后按照用户关系马上推送给他相应的粉丝。所以我们调用方已经在那儿等待了，我们需要有一个唤醒操作，就是说在接口这儿把它唤醒，然后把它发送过去。最后是一个高并发的长连服务器，就是一台服务器支持10万以上的并发连接。最右边中间有一个圆圈叫做Stream

Buffer，我们需要Stream

Buffer是要保存用户最近的数据。因为用户可能会有断线的，比如说他发送数据的时候断线半分钟，我们需要把这半分钟补给他。这就是我们的推送架构。

下面介绍一下平台安全部分。由于我们的接口是完全开放的，所以我们要防范很多恶意行为，有很多人担心我们接口是开放的，是不是有人通过这个接口发垃圾广告，或者是刷粉丝，我们技术架构怎么来防范这一点呢？这是我们的安全架构，做了三个层面的事情。最上面是我们有一个实时处理，比如说根据频度、内容的相似性来进行判断，判断发的是不是广告或者是垃圾内容。中间这个是一个日志处理器，我们会根据一些行为进行判断，比如说如果我们只是实时拦截的话，有些行为很难防止，我们做了个离线纠正的模块，比如说他潜伏的几个月开始发广告了，我们可以事后把这些人清除掉，以保证我们平台的健康。最后是通过监控的维度来保证内容的安全。目前内容安全的架构大概是541的体系，就是说我们的实时拦截可以做到50%的防止，离线分析大概可以做到40%的防止。

微博平台需要为用户提供安全及良好的体验应用，以及为开发者营造一个公平的环境，所以我们的接口需要清晰安全的规则。从一个APP调用我们的接口，需要几个阶层，需要划分不同的业务模块。第二个是安全层。第三个是权限层。这是我们平台安全的两个维度，一个接口安全，一个是内容安全。

我今天讲的是架构方面的问题，在座大部分是开发者，可能大家都在处理不同的架构问题，架构很多地方是相通的。我们需要做一个软件系统需要解决的本质问题是什么？微博第一版解决发布规模问题，第二版是解决数据规模的问题，第三版是解决服务化的问题。将复杂的问题简单化之后，我们才可以设计出一个容易扩展的大规模架构。我今天介绍就这么多，我们微博实际上是很需要各方面的技术人员，大家对我们的架构如果感兴趣的话、对我们的系统感兴趣的话，也希望各方面的技术人员参与我们微博的团队，随时可以给我微博上发私信。

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

林昊，网名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.sodocs.net/doc/247155246.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.sodocs.net/doc/247155246.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.sodocs.net/doc/247155246.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之间不存在谁模仿谁的问题，虽然双方都在