微博消息系统架构演进

合集下载

微博数据的动态演化与网络结构分析

微博数据的动态演化与网络结构分析随着互联网的快速发展，社交媒体成为人们生活中重要的一部分，微博作为中国最大的社交媒体平台之一，拥有庞大的用户群体和海量的数据资源。

这些数据资源不仅反映了社会民众的关注焦点和情感态度，还蕴含着微博社交网络的演化规律和结构特征。

本文将围绕微博数据的动态演化和网络结构展开分析，探讨微博对社会影响力和信息传播的作用。

首先，微博数据的动态演化是指微博社交网络中的用户关注和话题变化的过程。

通过对微博用户行为的观察和数据的分析，可以发现微博用户的关注与取消关注行为呈现出一定的规律。

研究发现，微博用户的关注行为受到社会关系、用户兴趣和话题热度等因素的影响。

例如，社会关系中的朋友关系和兴趣相似度会促使用户进行关注，而热门话题和明星事件等则会吸引用户的关注。

此外，用户关注行为也会随时间发生变化，受到用户兴趣的迁移和话题的流行度等因素的影响。

其次，微博数据的网络结构分析是对微博社交网络连接关系的研究。

微博作为一个典型的社交媒体平台，用户之间的连接关系主要包括关注关系和@关系。

通过对微博用户之间的关联分析，可以发现微博社交网络呈现出一些特征性的结构。

研究发现，微博社交网络的结构具有小世界特性和无标度特性。

小世界特性表明，微博社交网络中的任意两个用户之间通过少数关系就可以相互连接；而无标度特性则表明，微博社交网络中存在少数几个高度关联的影响力用户，其关注度远高于其他用户。

这些网络结构特征不仅反映了微博用户之间的社会关系，也对信息传播和舆论发酵等起到重要的影响。

微博数据的动态演化和网络结构分析对于了解社交媒体的发展和影响力具有重要意义。

首先，通过对微博用户关注行为的分析，可以了解用户兴趣的变化和社会关系的形成，为广告推送和用户画像等提供基础数据支持。

其次，通过分析微博社交网络的结构特征，可以识别社交影响力用户和热门话题，为社会舆情监测和品牌营销等提供参考依据。

最后，在信息传播和舆论发酵方面，微博数据分析可以揭示关键用户和传播路径，为信息筛选和传播途径的优化提供参考。

微博的应用与发展

微博的应用与发展摘要：本文首先介绍了微博的概念及发展历程，然后重点介绍了微博的功能与优势。

在简单地对目前微博发展的现状进行了分析之后，通过对微博的盈利模式与用户行为的研究，展望了微博未来的发展趋势，并针对趋势提出了相应的应对策略。

一、微博简述1、微博的含义与特点微博，即微博客（MicroBlog）的简称，是一个基于用户关系的信息分享、传播以及获取平台，用户可以通过WEB、WAP以及各种客户端组件个人社区，以140字左右的文字更新信息，并实现即时分享。

微博是最近新兴起的一个web2.0表现。

它最大的特点就是集成化和开放化，可以使得用户通过的手机、IM软件（gtalk、MSN、QQ、skype）和外部API接口等途径向微博客发布消息。

2、微博的起源与在中国的发展2006年3月的创始人推出了Twitter,英文原意为小鸟的叽叽喳喳声，用户能用如手机短信等数百种工具更新信息，这就是最早出现的微博。

Twitter 被Alexa网页流量统计评定为最受欢迎的50个网络应用之一，截至2010年1月份，该产品在全球已经拥有7500万注册用户。

2009年8月份中国最大的门户网站新浪网推出“新浪微博”内测版，成为门户网站中第一家提供微博服务的网站，微博正式进入中文上网主流人群视野。

微博作为市场上出现的一种新产品，目前仍然处于起步和成长阶段，微博要作为一种成熟地产品走进用户的生活还需要一个漫长的发展阶段。

如图１所示：美国微博目前正处于快速发展阶段，而中国微博处于起步阶段。

从总体上来看在微博在未来发展的道路上必然会经历被夸大的预期峰值以及预期与现实幻灭的低谷两个阶段，只有进行不断地产品创新才能保证微博产品长久、可持续的生命力，并最终达到稳定与成熟。

图１：微博的发展历程具体从微博在中国的发展阶段来看，虽然微博在中国的诞生时间不长，在将来微博客的整个发展史上可能刚处于导入期阶段，但微博客的发展和流行，迄今可以说已经历了五个关键阶段：1)微博客鼻祖推特(Twitter) 在2006 年3 月由的创始人伊万•威廉姆斯（Evan Williams）推出，在中国则以饭否2007 年的流行为代表，第一批的中国微博客用户多为Twitter 和饭否等网站的用户。

新浪微博架构与平台安全演讲稿

数据
• 重新思考 Rest API
• 大部分调用都是空返回 • 大部分时间在处理不必要的询问 • 无法实时投递 • 存在请求数限制（ limit）（rate
如何解决
• 新一代推送接口(Stream API) (Stream • 采用推送的方式
• 有新数据服务器立即推送给调用方 • 无数据则不消耗流量 • 客户端实现更简单
•
数据压力及峰值
• •
将数据、功能、部署尽可能拆分部署尽可能拆分提前容量规划
平台化需求
• Web 系统
• 有用户行为才有请求
• API 系统
• 轮询请求 • 峰值不明显 • 用户行为很难预测
• 系统规模持续增大 • 平台化需求 • 新的架构如何设计新的架构如何设计？
• “Break large complex systems
• 类似 mysql seconds behind master
• “Many services are written to alert
operations on failure and to depend upon human intervention for recovery, about 20% of the time they will make mistakes.
• 2. YMB is designed for wide wide-area
replication. This isolates individual PNUTS clusters from dealing with update between regions”
新推送架构
现状
• API 大部分请求都是为了获取最新
微博方案

微博架构方案

-采用分布式搜索引擎，如Elasticsearch；
-提供微博内容全文搜索，优化用户体验；
-实现实时搜索，提高搜索效率。
四、网络安全与数据保护
1.网络安全
-部署防火墙、入侵检测系统，防止恶意攻击；
-使用安全协议，如HTTPS，保障数据传输安全；
-实施严格的权限管理，防止内部数据泄露。
2.数据保护
-对用户敏感数据进行加密存储和传输；
-分析监控数据，优化系统性能。
六、实施与验收
1.实施计划
-制定详细的项目实施计划，明确时间节点、责任人和验收标准；
-按照实施计划，分阶段推进项目实施；
-组织技术培训，确保项目团队具备实施能力。
2.验收标准
-系统稳定性：确保99.99%的在线时间；
-性能指标：满足业务需求，响应时间不超过500ms；
-数据安全：无数据泄露事件发生；
微博架构方案
第1篇
微博架构方案
一、项目背景
随着互联网的快速发展，社交媒体已经成为人们日常生活中不可或缺的部分。微博作为国内领先的社交媒体平台，为广大用户提供了一个实时信息分享、互动交流的场所。为了满足日益增长的用户需求，保障平台稳定、高效运行，现需对微博平台架构进行优化升级。
二、方案目标
1.提高系统稳定性：确保平台在高并发、高负载情况下，仍能稳定运行，降低故障率。
（2）采用分布式设计，提高系统性能，确保高并发场景下的稳定运行。
（3）引入负载均衡技术，合理分配请求，提高资源利用率。
2.数据库设计
（1）采用关系型数据库存储用户数据，如MySQL、Oracle等。
（2）采用NoSQL数据库存储非结构化数据，如MongoDB、Redis等。
（3）建立合理的索引策略，提高数据查询速度。

微博系统架构的可信性研究

２１年第Ｏ期０１８
■ ｄｉ１．９９．ｓ６１１２０１００ｏ：０３６￣ｉｎ１７．１２２１８０７ｓ
的可信性研究
庆轩
（清华大学，北京１０８００４）
摘要：文章对微博系统架构进行了介绍，提出了新产生的问题及改善方案。关键词：微博系统；改善方案；可信性
第一版微博服务一经推出，受到了中国广大网民的充分认可，最早的人人网、开心网、博客和播客等各种社会网络与交互方
式都没有受到国内大众的广泛参与，而微博这个新事物，以它小巧灵便、快捷时尚的身姿挤入了继ＱＱ、飞信后，国人参与人数
最多的网络服务。随着用户迅速攀升，原先的ＬＭＰ架构已经不堪重负，最初的微博发放的推拉模式也受到了挑战。Ａ
‘ ＼＼
旺三圊Ｅ三五回臣三
据，更新的策略是ＬＵ（近最少使用）Ｒ最，以及每个ＫＶ对的有效时限。ＫＶ对存储有效时限是在ｍｅ由Ａｐ置并作为端ｐ设
参数传给ｍｓ的。同时ｍ采用是偷懒替代法，ＨＳｓＩ不会开额外的进程来实时监测过时的ＫＶ对并删除，而是当且仅当，新来
一
图１ｍｅａｈ的应用ｍｃｃｅ
需要注意的是，Ｍｅａｈｄ使用内存管理数据，所以它ｍｃｃｅ
是易失的，当服务器重启，或者Ｍｅａｈｄ进程中止时，数ｍｃｃｅ据便会丢失，所以Ｍｅａｈｄ不能用来保存持久数据。有很ｍｃｃｅ多人都有错误理解，认为Ｍｅａｈｄ的性能非常好，相对于ｍｃｃｅ

微博传播网络中信息演化与用户影响分析

微博传播网络中信息演化与用户影响分析随着社交媒体的快速发展，微博成为了人们重要的信息传播平台。

在微博传播网络中，信息不断演化，用户通过交互和分享对信息进行传播，同时也受到其他用户的影响。

针对微博传播网络中信息演化与用户影响，本文将从演化模式、用户影响和影响因素等方面进行分析和讨论。

一、微博传播网络中信息的演化模式在微博传播网络中，信息的演化模式主要可以归纳为“点对点传播”和“瀑布传播”两种。

1. 点对点传播：即用户通过私信、评论等形式将信息传达给指定的用户，形成一对一的传播关系。

这种传播模式常见于用户之间的互动、交流等情境，它能够快速传播信息，传播效果强。

2. 瀑布传播：即信息由源头用户开始向周围用户扩散，形成级联式传播关系。

在这个过程中，一条信息会经过多个用户的转发和评论，以达到更广泛的传播效果。

瀑布传播模式突出了信息的扩散特征，能够迅速引发舆论的聚集和形成。

二、微博传播网络中用户的影响力分析在微博传播网络中，用户的影响力是衡量其在信息传播过程中的影响力大小的指标。

用户的影响力主要体现在三个方面：社交关系影响、行为模仿影响和情感传递影响。

1. 社交关系影响：用户之间的社交关系是影响力的重要因素。

当一个用户拥有更多的粉丝和社交关系时，其发出的信息将获得更高的关注度，进而在信息传播中产生更大的影响。

2. 行为模仿影响：人们往往会模仿他人的行为。

在微博传播网络中，如果某一用户拥有较高的用户影响力，其行为和观点容易被其他用户所模仿和传播，从而影响到更多的人。

3. 情感传递影响：情感是微博传播网络中的重要组成部分。

用户的情感态度和情绪能够通过信息传递给其他用户，引发共鸣和情感传递。

情感传递影响在微博网络中起到引导用户情感共振的作用。

三、微博传播网络中用户影响力的影响因素微博传播网络中用户的影响力受到多个因素的影响，主要包括以下几个方面。

1. 用户活跃度：用户在微博平台的活跃程度与影响力之间存在一定的正相关关系。

普通微博系统结构

普通微博系统结构wudi1975@ 2012.2.1 1.系统概述（此处删除数百字）Balabala讲了一通项目背景，删之毫无鸭梨。

2.系统压力分析和估算微博这种系统特点非常鲜明，那就是非常多的人，非常频繁地使用非常少量的核心功能：发微博、查微博、评论微博、被通知有新微博（被@或者关注引导）。

微博的事务性要求非常低，但并发量和数据量极大。

2.1写并发（此处删除数百字）简要估算了一下微博系统的承受压力的目标，结果为：系统长期支持一千的并发，短时间可以支持一万的并发，那么平均每秒产生的数据就是几兆。

2.2读并发参考新浪微博等需要支持大并发、大压力问题的系统解决方案，一开始就采取了把读、写分开的方式来处理数据压力问题，写的压力从业务角度而言比较纯粹，读的压力则比较复杂，涉及的数据量也更大，但是解决的手段也多，下文再详细分析。

3.基本结构新浪微博压力比本系统大，而且其架构已经证明了事实可行，所以，本系统尽可能参考新浪微博的架构。

3.1基本B/S系统三层架构用户A 浏览器用户B浏览器用户X浏览器………客户界面数据库数据持久化WEB服务器业务1业务2业务3………HTTPsocket<图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协议的一个实现）工具来实现与数据库的通信。

这个通信是在局域网进行。

新浪架构师谈微博架构

微博(Micro‎-Blog)顾名思义是‎微型博客，是一种基于‎用户关系的‎信息分享和‎传播平台,用户可通过‎浏览器、手机、及时通讯软‎件(MSN、QQ、Skype‎等)及外部AP‎I接口等多‎种渠道发布‎140字以‎内信息[1]。

支持跨平台‎交流、与移动设备‎无缝连接的‎技术优势,饱含Web‎2.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 发表a32010-11-16 23：40 用户B 发表b1;2010-11-16 22：40 用户B 发表b2;问题1：如何设计数‎据表和查询‎？问题2：如果C关注‎了1000‎0个用户，A被10万‎个人关注，系统又该如‎何设计？问题1，我的解答是‎：设计两张表‎，一张用于表‎示用户us‎e r，有ID,用户名(usern‎a me)，发布内容（messa‎g e），发布时间(time)等字段；另一张表用‎于表示用户‎之间关注，有ID，用户名(usern‎a me)，关注的用户‎名，开始关注时‎间等字段。

回去想了想‎，发现如果数‎据表照我这‎样设计的话‎，问题2的情‎况就会产生‎大量的数据‎，但如果把关‎注的用户都‎写在一个记‎录里那样字‎符串可能会‎更大。

所以想听听‎诸位达人的‎意见，如果是你们‎会怎样设计‎数据表呢？问题1简单‎而且随意，直接跳过，估计面试的‎人都不会看‎。

问题2的困‎难在于：第一点.C关注的用‎户太多，设计上必须‎在显示C的‎页面的过程‎中，避免去数据‎库查询所有‎被关注的用‎户是否有更‎新。

第二点.第二点.A被关注的‎人太多，设计上必须‎在A更新的‎时候，避免去通知‎所有关注……为避免不必‎要的复杂连‎接关系，最好还是设‎计符合第三‎范式的关系‎数据。

微博技术架构发展历程

应用用框架
├── │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ ├── ├── ├── ├── └── application ├── config │ └── module ├── controllers │ ├── Interface ├── library │ ├── Cache │ ├── Comm │ │ ├── Bigpipe │ │ ├── Mb │ │ ├── Redis │ │ ├── Template │ │ └── Weibo │ ├── Data │ ├── Do │ ├── Dr │ ├── Ds │ ├── Dw │ ├── Entity │ ├── Exception │ ├── Model │ ├── Page │ ├── Pl │ ├── Plc │ ├── Pls │ ├── Plugin │ ├── Tool ├── models ├── plugins └── views daemon mb public system tests
图床
手手机
平台服务
DB CACHE 存储 MQ
应用用服务
实时搜索多IDC
基础服务
BigPipe渲染
V3上菜过程
1s 2s 3s 4s 5s
V4上菜过程
1s
2s
3s
4s
5s
应用用框架
├── ├── │ │ │ │ │ │ │ │ │ ├── ├── ├── │ │ └── daemon libraries ├── bigpipe ├── cache ├── db ├── exception ├── formchecker ├── i18n ├── swift ├── template └── weibo system tests thirdpart ├── Smarty-2.6.26 └── sinasso www ├── classes │ ├── cache │ ├── controller │ │ ├── interface │ ├── do │ ├── dr │ ├── ds │ ├── dw │ ├── exception │ ├── page │ ├── pl │ ├── plc │ ├── plugin │ ├── tool ├── config ├── htdocs └── tpls

什么是微博信息流,微博信息流是如何实现的？

什么是微博信息流，微博信息流是如何实现的？专栏结束后，有不少同学留言希望我能讲一些微博基础架构的知识。

所以接下来的微博技术解密系列，我将分享微博在信息流架构、存储中间件等方面的经验，希望能给你带来启发和帮助。

今天我们先来看微博信息流架构，也就是微博的 Feed 是如何构建的。

首先什么是 Feed 呢？根据我的理解，Feed 是互联网 2.0 时代的产物，它与互联网 1.0 时代的产物——门户网站最大的不同之处就是 Feed 不需要用户在各个板块之间来回跳转获取信息，而是把不同的信息都聚合在一起，可以供用户源源不断地访问。

这里就涉及了两个问题，一个是信息如何保存，另一个是信息如何聚合。

这也是今天我要分享的主要内容，我会从存储架构的角度阐述微博 Feed 是如何存储的，然后会从业务架构的角度阐述微博 Feed 是如何聚合的。

微博 Feed 存储架构我们知道，微博 Feed 是由关注人的微博聚合在一起组成的，所以要存储每个人发的微博，那么在设计存储架构时主要需要注意三个问题：•每秒数据写入量，也就是每秒发博量是多大。

•每秒数据访问量，也就是每秒微博请求量是多大。

•是否有冷热数据之分，也就是微博的请求是否有时间特点。

结合微博的业务场景，我来回答上面提出的三个问题。

首先是每秒发博量，这里要考虑到极端情况，比如元旦零点，瞬间会有大量用户发博，达到数万 QPS。

再来看下每秒微博请求量，同样要考虑到在热点事件时，比如“春晚”时会有大量用户访问微博，请求量也会达到数万 QPS；并且每个用户关注的不止是一个人，假设关注数的平均值是 200，那么微博数据的请求量就是几百万QPS。

除此之外，微博的访问也是有时间特点的，用户一般访问新发微博的概率要远远大于一周前发的微博，所以说微博数据也是有冷热之分的。

这三个问题共同决定了微博的存储架构应该如何设计。

在讨论微博存储架构前，我们先来看看目前业界比较成熟的存储方案，主要分为下面几种。

新浪微博发展历程及趋势

DCCI预计，微博未来不仅仅是新媒体平台，更是信息交互、应用分发、电子商务平台，把微博理解成为媒体是狭隘、短视的。人际实时交互关系网络是微博逻辑的核心，这就使得微博未来不可避免与社区会有一战，战争的结果是微博、社区的互相渗透互相拥抱互相融合。
微博与社区之间的进入、碰撞，既是主动又是被动的。对于优势不同的主体来说，这是一场时间的赛跑，彼此都要利用对方的不足打时间差。
新浪微博市场调查-用户行为分析
男女用户行为比较
在新浪微博的总用户中，女性比例为43%，男性比例为 57%；但在新浪微博的活跃用户中，女性占据着65%的份额，男性仅为35%。
新浪微博市场调查-用户行为分析
男女用户行为比较
在使用微博目的差异上，女性用户在“记录自己的心情、娱乐、休闲、了解最新发生的事情让自己不落伍” 等方面比男性比例更高，显示出女性在使用微博上相对男性更关注生活。而男性则在“交流工作、学习心得，结交新朋友拓展人脉”这方面比女性更高，显示出男性在使用微博上相对女调查-用户行为分析
在微博资讯内容的关注方面，90后更加关注心情状态，偏好娱乐八卦和名人动态，这种差异很好体现了不同年龄群体的兴趣差异。
新浪微博市场调查-用户行为分析
不同年龄层的微博用户使用微博的功能不尽相同，年纪越轻的微博用户，对微博功能的探索和使用更加深入。90后用户使用手机微博的比例接近百分之五十，80后用户较偏爱微博的转发功能。
从上午10点起，新浪微博用户就开始频繁发送微博，使用高峰期出现在晚上，每晚22点达到峰值，发送比例为6.9%。
新浪微博市场调查-用户行为分析
从各省情况来看，广东微博用户属于典型的“夜战型”，高峰期从第一天23点持续到第二天凌晨5点，而且发送微博的数量明显高于其他区域；北京微博用户属于“工作达人型”，从早上8点到下午18点，一直比较

新浪微博的架构发展历程By杨卫华

Push
• 优点：实现简单，首选优点：实现简单， • 缺点：分发量缺点：
Pull
• 发表：存到自己发表：存到自己outbox(轻) 轻 • 查看：所有关注对象查看：所有关注对象Inbox(重) 重
Pull
User I Get home_timeline
User I’s Following List = A, B, C
- Jeff Rothschild, Vice President of Technology at Facebook
Cache挑战：multiget 挑战：挑战 hole
Application Max RPS of application < (A and B and C)
Multiget
Multiget (keys…)
Memcacheq
• 基于基于Berkeley db, 稳定可靠 • Memcached protocol, 丰富的 client library • 容易监控(stats queue) 容易监控 • 只有个命令：get/set 只有2个命令个命令：
避免单点故障
核心服务，核心服务，需避免单独故障方法
地理分布的方案
• MySQL master/slave • Dynamo/Cassandra • PNUTS
架构挑战：架构挑战：API访问量访问量
以新浪微博开放平台为例
• REST API
–编程简单，library丰富
• 可用curl, javascript实现一个client
–缺点单向询问方式
异步设计
• 不同步等待 • 将消息存入消息队列将消息存入消息队列(Message Queue) • 轻量级的发表

解析微博的信息呈现结构

解剖微博：解析微博的信息呈现格式摘要: 都云人言可微，哪怕微言耸听！大小门户齐上阵，且看沙场秋点兵。

–定场诗一首前言：回到七嘴八舌的原始社会所谓沟通，就是人们忙着做两件简单事：听别人说什么；自己该说什么。

有一种沟通，主席台上某个发言人拿着扩音器讲话，身为听众只能在台下窃窃私语，这个...都云人言可微，哪怕微言耸听！大小门户齐上阵，且看沙场秋点兵。

–定场诗一首前言：回到七嘴八舌的原始社会所谓沟通，就是人们忙着做两件简单事：听别人说什么；自己该说什么。

有一种沟通，主席台上某个发言人拿着扩音器讲话，身为听众只能在台下窃窃私语，这个叫门户；有一种沟通，大家都可以轮流上讲台上拿着扩音器说话，并且邀请台下的观众评论，这个叫论坛；有一种沟通，大家都回到自己家说话，张贴标语，然后可以任意的去别人家拜访和聆听，这个叫日志，也叫Blog；还有一种沟通，大家围坐在一起，你可以选择收听那些你感兴趣的人，物以类聚，七嘴八舌，这个外国叫Twitter，到了中国叫“微博”。

一个人说话大家听，是信息的专制；大家轮流说话，似乎是信息的民主；有组织无纪律的七嘴八舌，也许可以算作信息的原始社会。

平等，是微博的可怕之处，每个人都有话语权，也有选择聆听的权利。

微博的任务核心任务、扩展任务、外延任务，这三者组成了微博要实现的沟通目的。

反射系统由收听和发送两个部分组成，参与者通常扮演倾听者和发言人两个角色。

其实这个世界很奇怪，从很小的时候，我们莫名其妙的学会七嘴八舌，聋哑人通常有两个原因产生：一是无法收听，所以不知道所谓发音，虽然发声系统是完好的，也说不出话，很痛苦；二是无法发声，虽然能听得到，但是无法产生反馈，很痛苦。

最幸福的莫过既不能收听也不能发声，因为他们完全与声音绝缘。

微博信息格式的核心任务、扩展任务、外延任务核心任务包括：大家说了什么；其中哪些是“我说的话”，哪些是“别人的话”；在别人的话里面，某个人又说了些什么，谁对我说过什么。

新浪微博架构分析

首先给大家介绍一下微博架构发展的历程。

新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了几个版本。

第一版就是是非常快的，我们可以非常快的实现我们的模块。

我们看一下技术特点，微博这个产品从架构上来分析，它需要解决的是发表和订阅的问题。

我们第一版采用的是推的消息模式，假如说我们一个明星用户他有10万个粉丝，那就是说用户发表一条微博的时候，我们把这个微博消息攒成10万份，这样就是很简单了，第一版的架构实际上就是这两行字。

第一版本的技术细节，典型的LAMP架构，是使用Myisam搜索引擎，它的优点就是速度非常快。

另外一个是MPSS，就是多个端口可以布置在服务器上。

为什么使用MPSS？假如说我们做一个互联网应用，这个应用里面有三个单元，我们可以由三种部署方式。

我们可以把三个单元部署在三台服务器上，另外一种部署模式就是这三个单元部署在每个服务器上都有。

这个解决了两个问题，一个是负载均衡，因为每一个单元都有多个结点处理，另外一个是可以防止单点故障。

如果我们按照模式一来做的话，任何一个结点有故障就会影响我们系统服务，如果模式二的话，任何一个结点发生故障我们的整体都不会受到影响的。

我们微博第一版上线之后，用户非常喜欢这个产品，用户数增长非常迅速。

我们技术上碰到几个问题。

第一个问题是发表会出现延迟现象，尤其是明星用户他的粉丝多。

另外系统处理明星用户发表时候的延迟，可能会影响到其他的用户，因为其他的用户同一时间发表的话，也会受到这个系统的影响。

我们就考虑这个系统怎么改进。

首先是推模式，这肯定是延迟的首要原因，我们要把这个问题解决掉。

其次我们的用户越来越多，这个数据库表从一百万到一亿，数据规模不一样处理方式是有差别的。

我们第一版单库单表的模式，当用户数量增多的时候，它不能满足就需要进行拆分。

第二个是锁表的问题，我们考虑的是更改引擎。

另外一个是发表过慢，我们考虑的是异步模式。

第二版我们进行了模块化，我们首先做了一个层，做了拆分，最右边的发表做了异步模式。

千万级规模高性能、高并发的网络架构

千万级规模高性能、高并发的网络架构经验分享本文通过介绍新浪微博的平台架构以及核心技术难点，对于大型网站的发展历程提出一系列理论和实际相结合的经验总结。

主要介绍：1.架构以及我理解中架构的本质；2.新浪微博整体架构是什么样的；3.在大型网站的系统架构是如何演变的；4.微博的技术挑战和正交分解法解析架构；5.微博多级双机房缓存架构；6.分布式服务追踪系统；7.总结。

在开始谈我对架构本质的理解之前，先谈谈个人对千万级规模的网站的理解，对这个数量级我们战略上要藐视视，战术上要重视。

先举个例子感受一下千万级到底是什么数量级？现在很流行的优步(Uber)，从媒体公布的信息看，它每天接单量平均在百万左右，假如每天有10个小时的服务时间，平均QPS只有30左右。

对于一个后台服务器，单机的平均QPS可以到达800-1000，单独看写的业务量很简单。

为什么我们又不能说轻视它？第一，我们看它的数据存储，每天一百万的话，一年数据量的规模是多少？其次，刚才说的订单量，每一个订单要推送给附近的司机、司机要并发抢单，后面业务场景的访问量往往是前者的上百倍，轻松就超过上亿级别了。

我想从架构的本质谈起，希望大家理解在做架构设计的时候，从什么出发点开始，解决的什么样的问题。

架构，刚开始的解释是我从知乎上看到的。

什么是架构？有人讲，说架构并不是一个很悬乎的东西，实际上就是一个架子，放一些业务和算法，跟我们的生活中的晾衣架很像。

更抽象一点，说架构其实是对我们重复性业务的抽象和我们未来业务拓展的前瞻，强调过去的经验和你对整个行业的预见。

我们要想做一个架构的话需要哪些能力？我觉得架构师一个最重要的能力就是你要有战略分解能力。

这个怎么来看呢，第一，你必须要有抽象的能力，抽象的能力最基本就是去重，去重在整个架构中体现在方方面面，从定义一个函数，到定义一个类，到提供的一个服务，以及模板，背后都是要去重提高可复用率。

第二，分类能力。

做软件需要做对象的解耦，要定义对象的属性和方法，做分布式系统的时候要做服务的拆分和模块化，要定义服务的接口和规范。

新浪微博发送消息和授权机制原理（WeiboSDK）

新浪微博发送消息和授权机制原理（WeiboSDK）1.⾸先是在微博发送消息，对于刚開始做weibo发送消息的刚開始学习的⼈会有⼀个误区，那就是会觉得须要授权后才⼲够发送消息。

事实上发送消息仅仅须要⼏⾏代码就能够实现了，很easy，不须要先授权再发送消息，由于weibosdk已经帮我们封装好了。

（此情况须要⽤户安装client）发送消息流程为：点击发送消息按键----SDK会⾃⼰主动帮我们推断⽤户是否安装了新浪微博client--假设未安装弹出安装提⽰----假设安装直接跳转到sina微博client进⾏发送----发送成功后⾃⼰主动跳回原应⽤程序。

1)在AppDelegate中注冊sdk, AppDelegate须要实现WeiboSDKDelegateAppDelegate.h@interface AppDelegate : UIResponder <UIApplicationDelegate, WeiboSDKDelegate>{...AppDelegate.m- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions{//注冊SDK[WeiboSDK enableDebugMode:YES];[WeiboSDK registerApp:kAppKey];- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation{return [WeiboSDK handleOpenURL:url delegate:self];}2)拼接消息对象WBMessageObject，并发送消息[WeiboSDK sendRequest:request];WBSendMessageToWeiboRequest *request = [WBSendMessageToWeiboRequest requestWithMessage:[self messageToShare]];erInfo = @{@"ShareMessageFrom": @"SendMessageToWeiboViewController",@"Other_Info_1": [NSNumber numberWithInt:123],@"Other_Info_2": @[@"obj1", @"obj2"],@"Other_Info_3": @{@"key1": @"obj1", @"key2": @"obj2"}};// request.shouldOpenWeiboAppInstallPageIfNotInstalled = NO;[WeiboSDK sendRequest:request];//这句就能够发送消息了，不须要先授权- (WBMessageObject *)messageToShare{WBMessageObject *message = [WBMessageObject message];if (self.textSwitch.on){message.text = @"測试通过WeiboSDK发送⽂字到微博!";}if (self.imageSwitch.on){WBImageObject *image = [WBImageObject object];image.imageData = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"image_1" ofType:@"jpg"]];message.imageObject = image;}if (self.mediaSwitch.on){WBWebpageObject *webpage = [WBWebpageObject object];webpage.objectID = @"identifier1";webpage.title = @"分享⽹页标题";webpage.description = [NSString stringWithFormat:@"分享⽹页内容简单介绍-%.0f", [[NSDate date] timeIntervalSince1970]];webpage.thumbnailData = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@"image_2" ofType:@"jpg"]];webpage.webpageUrl = @"?a=1";message.mediaObject = webpage;}return message;}重要：假设程序发送完消息⽆法跳回原应⽤的话是由于在plist⽂件⾥没有配置URL Types，appKey在你的新浪开发⼈员帐号⾥有。