微博(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什么的，估计数据库就挂了
是直接写到数据库的，不能用join,发贴后就丢队列里，向每一个follow我的人的tweet写数据
不能用纯粹的关系数据库来解决问题，因为数据量和访问量都很大。所以设计必须首要考虑性能问题。
我假定前提，
1、一个用户不经常更改他的关注对象，
2、用户添加关注对象的操作远多于移除关注对象的操作。
3、用户发微博的频率是比较高的，要比更改关注用户操作的频率高。
4、消息的通知到达时间用户是不敏感的
有了这些前提，我们做平衡处理。
我们可以忍受
1、较慢的删除关注用户操作
2、比删除操作快但比发微博操作慢的添加关注用户操作。
3、快的微博提交操作
4、慢的消息通知
我们每一个用户建立一个InBo x和OutBox，InBo x包含关注我的用户ID，OutBox是我关注的用户ID。
Box分为三个部分，一个是基准Box，一个是添加Bo x，一个是删除Bo x，实际的Box数据是基准Bo x和添加Box的并集和删除Bo x做差集后得到的集合。
1、用户插入关注用户，在用户的OutBox的添加Bo x加入一条，同时在被关注用户的InBo x的添加Bo x也加入一条添加
2、用户删除关主用户，在用户的OutBox的删除Bo x加入一条，同时在被关注用户的InBo x的删除Bo x也加入一条添加
3、微博产生后发送消息，将发送微博的用户的InBox（其中含基准Box，插入Bo x和删除Box）连同微博操作连接一起发送给消息处理器。
4、消息处理器合并Box，并把Bo x的内容回写到发送微博用户的InBo x的基准Box中。
5、在后台添加一个Bo x合并进程，缓慢的合并用户的Box数据。
6、前台在展示的时候，因为没有合并，展示列表展示OutBox的基准Bo x和我新添加用户的Bo x以及删除用户的Box内容。
前台展示是需要商榷的，看PUM是否接受这种方式，如果不接受，我们只能在刷新时预测查询基准表，并且在页面合并。因为前台展示通常是分页的，这样会比较难获得准确的分页量，每页的显示量会不同。如果需要更高的要求，我们只能再添加其他数据结构。
如果需要更快的算法，我们必须抛弃关系数据库，将用户用B+树做索引，对于Box进行另外处理，需要论述的话，能写一个论文了。
更正一下，抛弃关系数据库可能更好的方式是，用用户ID做Hash索引，因为用户不删除，只增加。
同时，我们可以采用的物理架构和产品，我们需要找到一个轻量级的数据库存储引擎，例如我们可以用BDB，操作系统可以用vxWorks，然后专门针对消息发送和Bo x做一套系统。
更正设计，InBox可以不需要，采用客户端拉的机制，可以去掉InBox，带来的问题就是你必须在线才能得到通知。
InBox会很大，需要平衡，像姚晨这样的，会把消息处理器累死，所以，需要筛选，消息处理器的需要另外设计。
消息处理器可以去掉，当用户上线时，查阅关注博主的博文变更记录，根据阅读标志，阅读标志为每个用户建立一组。进行伪消息通知。
消息处理器存在于需要主动推送的场合。例如，短信和邮件。不是所有的用户都会进行短信订阅的，所以消息处理器的负载可以减轻。陆兄的意思是不是：用DBMS底层的数据库引擎或相关数据结构（比如哈希，B+树等）重新设计一个适合微博应用环境的数据库，而不是利用现有的DBMS进行设计？
数据库是需要的，但不应该是关系型的。自己做数据库是可行的，在这个应用中，或者说需要高速处理的“热”数据中，是不需要关系的，也不应该用关系数据库的设计范式来约束设计。
对于Box这样的数据结构，是不需要保存在一个关系数据库的数据表中的。做成Hash表会很好，当然可以采用现有的数据库产品，把Box的索引类型定义为Hash的。很多数据库产品是可以这样处理的。
但是，这样会有麻烦，因为Box和用户紧密关联的，不可能为一个用户去建立一个Hash索引的表，这样你又不得不回到关系数据库的老路上去了。你可能会说，我可以定义在Hash主键中包含用户的账号，这样Bo x的数据自然会按照用户分开了。但是，需要获取用户整个Box数据的时候又碰到麻烦，没有和用户关联的索引去快速检索。
能做的就是把Bo x保存在内存或者独立的文件中，在这种应用中对数据完整性的要求是很低的，Box应该在内存中保存，在适当的时机脱水持久化。而且活跃的Bo x可能很少很少。
所以我的建议是分别处理，持久化一块，“热”的实时播发一块，持久化为了简便采用传统的关系数据库是可以的。
为了性能，需要特别处理。全部的设计，会很复杂，作为面试题，太难了！
为了提高处理能力，并行是不可避免的，需要把Bo x这样的结构分解分发在不同的机器上处理。但是在这样的应用中，事务又是不需要的，数据完整性也是不需要的，甚至不需要日志来恢复数据，并行处理的时候用传统的RDBMS又会有瓶颈。
所以这不是一个数据库设计问题。靠做关系数据库的设计是完成不了这样的任务的。
就是一个查询时间换空间的问题
本人认为在10万条以内，直接的标准关系型数据库设计就好
更大的话可以考虑做空间换时间的设计
具体可以做内存空间缓存，文件缓存，数据库缓存都可以
就数据库缓存来说，除了标准的关系型数据库外，另外需要加个表做个用户-》关注信息的表
每次有被关注的用户发布信息，就把其信息的ID写入被关注用户的用户关注信息表，对这个表可以优化，把比较老的数据及时删除。
还有一种折中的做法就是分别对关注关系的关注用户字段和用户信息的用户字段和时间字段做索引，问题就基本能解决，百万级没有问题
如果数量再大，需要对用户信息做时间的分表，保证每个表的信息数量在千万数量级
当然，每次访问都读取数据表就是一种愚蠢的做法，短期内数据不更新的情况下应当从内存读取数据或者文件缓存来读取数据
缓存的更新又是另外一个话题啦
问题2的困难在于：
第一点.C关注的用户太多，设计上必须在显示C的页面的过程中，避免去数据库查询所有被关注的用户是否有更新。
第二点.A被关注的人太多，设计上必须在A更新的时候，避免去通知所有关注他的人自己更新了(也就是数据库中为每个人设置标志或者增加记录)。
这两点其实是矛盾的，因为你总需要在某个时候交流“A更新了”这条信息。就需要在系统设计的时候进行折衷和权衡。甚至对不同的用
户分类采用不同的方案。
可以采用以下的方案：
普通用户放到一张表中，视为B类。假设绝大多数用户都是B类，即关注的人不太多，被关注也不太多。进一步假设绝大多数的微博记录来自于普通的B类用户。
对那些关注别人太多的，分为C类。专门为C类用户增加一个表，他关注的人如果不是A类，则每次更新都在这张表里面推送一条记录。这样显示C的主页时，只用先查询这张表，再在A类人的专属表中查找A类人的更新即可。因为C类的人数比较少，所以这张表应该会比较小，查找起来会比较快。
对A类的人，则独立出来成为单独的一张表，供别人查询，因为A类的人数较少，所以这张表应该会比较小，查找起来比较快。
这就是一个简单的设计，足以表示你针对问题进行考虑，并给出了有一定效果的解决方案。
当然，这是按照楼上要求的只通过表的设计来实现。
而实际构建系统的时候，该用视图的用视图，该建立索引的建立索引，花样会更多，效果会更好。
以下设计以sqlserver2005为例
记录用户信息的用户表
Users(uid bigint identity(1000,1) primary key,uname varchar(50) not null unique);
记录A对B的关注信息的关注表
Attention(byuser bigint foreign key references Users(uid),touser bigint foreign key
references Users(uid) primary key(byuser,touser));
注：byuser 发起关注者，touser 被关注者
记录某人发表文章信息的文章表
Article(aid bigint identity(1000,1) primary key,uid bigint foreign key references Users
(uid),title varchar(100) not null,context ntext not null,publishDate datetime not null);
由于需要获取更新信息，所以要能记录哪些文章是查看过，那些不是的文章状态，并且此状态不是文章
的状态，而是每一个文章对于每一个关注者的状态。所以，新表的设计目的是某用户对某文章的查看状
态。
AttentionUpdate(auid bigint identity(1,1) primary key,attentionUser bigint foreign key
references Users(uid),ariticle bigint foreign key references Article(aid) unique
(attentionUser,ariticle),attentionState char(1) not null);
注：unique约束的目的是保证某一个用户对某一个文章的关注唯一；attentionState状态的目的是记录
该用户对该文章的操作状态，比如查看、评论、分享等。
并且由题目得知（题目有不明之处，先查询出的用户A的更新信息是正序，而后查询出的用户B的更新信
息是倒叙，此处就按正序来做），在查询更新信息的时候，需要按照关注用户Id、文章更新时间的正序
排序。
所以
在要求：查询出用户C关注的A和B的关注信息的查询语句
(拟定用户C的ID为1003、A：1001、B：1002)
(拟定文章状态为'1'为未读)
有语句：
select art.publishDate,u.uname,art.title
fro m Users u,Article art
where u.uid=art.attentionUser and arti.aid in
(select aid fro m AttentionUpdate where attentionUser=1003 and attentionState='1')
order by u.uid asc,art.publishDate asc
限制：必须保证AttentionUpdate中的记录表示的关注状态和关注表中的记录相符，即是说当某用户发表一篇文章的时候，就要根据该用户被关注的情况在AttentionUpdate表中插入attentionState为1 attentionUser为关注其用户的数据；在某用户删除一篇文章的时候，做相应删除；在某用户修改的时候要做相应修改。
而且还可以做相应扩展，比如对用户分组，对组别设置访问权限。根据权限对AttentionUpdate表中的记录插入做选择性插入即可，修改、删除如是。
以上是我个人的设计，小子是5月份刚从学校毕业的学生，虽然现在在做一家b2c网站的开发，但对性能问题也不是很通透，只能给出一个我能想到的最优的解决方案...但对高并发访问没有经验，也没有把握，猜测是在视图、存储过程、以及查询上做优化..
新浪架构师谈微博架构
技术开发者往往对微博这个产品非常关心，对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家对微博的底层技术有更好的了解。另外不管是做客户端、Web1.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，我们去年做了一个对大规模部署非常有利的指令，就是statsqueue，适合大规模运维。
第二版我们做了这些改进之后，微博的用户和访问量并没有停止，还有很多新的问题出现。比如说系统问题，单点故障导致的雪崩，第二个是访问速度问题因为国内网络环境复杂，会有用户反映说在不同地区访问图片、js这些速度会有问题。另外一个是数据压力以及峰值，MySql复制延迟、慢查询，另外就是热门事件，比如说世界杯，可能会导致用户每秒发表的内容达到几千条。我们考虑如何改进，首先系统方面允许任意模块失败。另外静态内容，第一步我们用CDN来加速，另外数据的压力以及峰值，我们需要将数据、功能、部署尽可能的拆分，然后提前进行容量规划。
另一方面我们还有平台化的需求，去年11月我们就说要做开放平台，开放平台的需求是有差异的，Web系统它有用户行为才有请求，但是API系统特别是客户端的应用，只要用户一开机就会有请求，直到他关闭电脑这种请求一直会不间断的过来，另外用户行为很难预测。
系统规模在持续的增大，另外也有平台化的需求，我们新架构应该怎么做才能满足这些需要？我们看一下同行，比如说Google怎么样考虑这个问题的？Google首席科学家讲过一句话，就是一个大的复杂的系统，应该要分解成很多小的服务。比如说我们在https://www.doczj.com/doc/1618050515.html, 执行一个搜索查询的话，实际上这个操作会调动内部一百多个服务。因此，我们第三版的考虑就是先有服务才有接口最后才有应用，我
们才能把这个系统做大。
现在我们看一下第三版，首先我们把底层的东西分成基础服务，基础服务里面有分布式的存储，我们做了一些去中心化、自动化的操作。在基础服务之上有平台服务，我们把微博常用的应用做成各种小的服务。然后我们还有应用服务，这个是专门考虑平台各种应用的需求。最上面我们有API，API就是新浪微博各种第三方应用都在上面跑。平台服务和应用服务是分开的，这样实现了模块隔离，即使应用服务访问量过大的话，平台服务不会首先影响。另外我们把微博的引擎进行了改进，实现了一个分层关系。用户的关注关系，我们改成一个多惟度的索引结构，性能极大的提高。第四个层面就是计数器的改进，新版我们改成了基于偏移的思路，就是一个用户他原来读的一个ID比如说是10000，系统最新的ID是10002的话，我们很清楚他有两条未读。原来的版本是采用绝对计数的，这个用户有几条未读都是用一个存储结构的话，就容易产生一致性的问题，采用这种偏移的技术基本上不会出错。
另外基础服务D B冷热分离多维度拆分，在微博里面我们是按照时间拆分的，但是一个大型的系统里面有很多业务需要有不同的考虑。比如说私信这个就不能按照时间来拆分，这个按照UID来拆分可能更简单。然后我们突出存储还做了一个去中心化，就是用户上传图片的速度会极大的提高，另外察看其他用户的图片速度也会极大的提高。另外是动态内容支持多IDC同时更新，这个是在国内比较新颖的。
下面给大家介绍一下新浪微博怎么样打造一个高性能架构。到目前为止有五千万用户使用新浪微博，最高发表3000条以上每秒，然后一个明星用户发表的话，会被几百万用户同时读到。这些问题的本质是我们架构需要考虑高访问量、海量数据的情况下三个问题。易于扩展、低延迟、高可用和异地分布。我们每天有数十亿次外部网页以及API接口的需求，我们知道微博的特点是用户请求是无法cache 的。因此面对这个需求我们怎么样扩展？几点思路。第一我们的模块设计上要去状态，我们任意一个单元可以支持任意节点。另外是去中心化，避免单点及瓶颈。另外是可线性扩展。最后一个是减少模块。
我们要做一个高性能的系统，要具备一个低延迟、高实时性，微博要做到高实时性这是核心的价值，实时性的核心就是让数据离CPU 最近，避免磁盘的IO。我们看淘宝核心系统专家余锋说过的一句话“CPU访问L1就像从书桌拿一本书，L2是从书架拿一本书，L3是从客厅桌子上拿一本书，访问主存就像骑车去社区图书馆拿一书”。我们微博如果要做到非常实时的话，我们就需要把数据尽量离CPU节点最近。所以我们看一下cache设计里面怎么达到这个目标。首先INBO X，这个数据我们需要放再一个最快的地方，因为用户随时访问。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 Bu ffer，我们需要Stream Bu ffer是要保存用户最近的数据。因为用户可能会有断线的，比如说他发送数据的时候断线半分钟，我们需要把这半分钟补给他。这就是我们的推送架构。
下面介绍一下平台安全部分。由于我们的接口是完全开放的，所以我们要防范很多恶意行为，有很多人担心我们接口是开放的，是不是有人通过这个接口发垃圾广告，或者是刷粉丝，我们技术架构怎么来防范这一点呢？这是我们的安全架构，做了三个层面的事情。最上面是我们有一个实时处理，比如说根据频度、内容的相似性来进行判断，判断发的是不是广告或者是垃圾内容。中间这个是一个日志处理器，我们会根据一些行为进行判断，比如说如果我们只是实时拦截的话，有些行为很难防止，我们做了个离线纠正的模块，比如说他潜伏的几个月开始发广告了，我们可以事后把这些人清除掉，以保证我们平台的健康。最后是通过监控的维度来保证内容的安全。目前内容安全的架构大概是541的体系，就是说我们的实时拦截可以做到50%的防止，离线分析大概可以做到40%的防止。
微博平台需要为用户提供安全及良好的体验应用，以及为开发者营造一个公平的环境，所以我们的接口需要清晰安全的规则。从一个APP调用我们的接口，需要几个阶层，需要划分不同的业务模块。第二个是安全层。第三个是权限层。这是我们平台安全的两个维度，一个接口安全，一个是内容安全。
我今天讲的是架构方面的问题，在座大部分是开发者，可能大家都在处理不同的架构问题，架构很多地方是相通的。我们需要做一个软件系统需要解决的本质问题是什么？微博第一版解决发布规模问题，第二版是解决数据规模的问题，第三版是解决服务化的问题。将复杂的问题简单化之后，我们才可以设计出一个容易扩展的大规模架构。我今天介绍就这么多，我们微博实际上是很需要各方面的技术人员，大家对我们的架构如果感兴趣的话、对我们的系统感兴趣的话，也希望各方面的技术人员参与我们微博的团队，随时可以给我微博上发私信。
杨为华：今天主要给大家介绍一下微薄cache设计，在我们业界有一个趋势就是平台和应用。以前Web1.0发展到Web2.0，有一种更进一步趋势就是转变成平台和应用。很多应用不是单纯一个Web应用，国内已经有不少公司做这个方向，做Web2.0或者cache，刚开始都是自己模式，希望能够把这个行业一些人聚合起来大家一起交流，大家犯过的一些错误可以避免，让我们做事情更有效率。
最早我们新浪曾经有一个DB产品，刚开始做通过我们社区介绍，慢慢让大家知道DB在一些方面用起来更适合大家的地方，后来比如说我们去年发展一种分布式的，现在随着社区大家互相介绍，如果有人单独讲一个DB会觉得很不好意思。微博最早我们只能看国外的，慢慢有不少公司做这个，刚开始我们介绍一些基本技术，比如说微博的东西可以用推和拉做，等到以后经过我们把这个话题讲到以后，有人再讲微博技术光讲推和拉觉得不好意思，要进行一些更深入的话题，慢慢我们就在这个过程当中。今天讲一下cache的设计，我讲过一次微薄扩展设计，那是一个基本话题，刚才也讲了一个架构讲得比上次更深刻，光讲一个推是不够的，我今天演讲主要从是cache 进一步补充一下，一部分是Feed架构简介，第二是cache的设计。
微博技术核心主要三个，一条微博有很多关注的人，分别将你发表的微博分发到你所有关注的人，聚合就是打开微博首页这里看到我关注人的信息，以及这个微博信息的展现，微博在技术上也称之为status或者Feed，下面图就是一个典型的Feed。
Feed架构刚才是两种设计模式推或者拉，还有第三种方式叫做复合型。做到一定程度单纯推或者拉是不够的。推的话如果把Feed 比喻成邮件，推就是inbo不惜是收到的微博，OUTPOX是已发表的微博，发表到所有的粉丝，查看就是直接访问到。PUSH优点就是实现简单，通常做一个种型是首选方案，缺点就是分发量。PULL发表是在自己的outbox，查看是所有关注对象的inbox。优点节约存储，缺点是计算大量，峰值问题。当前访问量比较大是不是计算得过来，服务器是不是够用，假如说你的服务器是按照你峰值规划你的服务器，在平时时候是非常多的空闲，这个是不合理，不管推和拉都有一些共同的难题比如说峰值的挑战，比如说世界杯活动在新浪微博每秒钟发表量达到2500条，我们可以使用异步处理2500个峰值，处理速度慢一点，你关注人不能马上看到，峰值过后保证系统不会被峰值压跨，下面就是cache，现在有一句话对于这种real—time就是说：传统硬盘已经不够用，很多东西要分放在硬盘里面才能满足需求。因此cache设计决定了一个微博系统的优劣。
里面是一种复合型，不是一个简单的推或者拉的类型，因为就是说像我们新浪微博到这个级别要做很多优化，从模型上就是一个推或者拉的模型，我们按照它的关系来说，把cache分成需要四种存储的东西，这两个里面跟索引比较类似，第三就是列表和客户自己资料。
看一下第一部分就是inbox微博首页开始ID列表，完全是内存里面，但是有一个缺点，我们要添加元素需要先AET再SET；第二部分outbox发出微博有存储最新ID在于聚合。为了高效，我们通常分两部分，第一就是说最新的一个ID列表比如说我们有100条内容，这个用户很久没有来，这个是空要过来取就要从我工作列表用ID地址聚合起来；第三部分是关注列表，这些都是纯ID，然后following，following加载开销比较大，上百万粉丝，越大的集合越容易变更，改变则需要deleteall减少使用followinglist场景；第四部分contetcache 微博内容体里面有一个很重要的内容，热内容。这个用户有200万粉丝，这个内容是热内容，在线粉丝也非常多，多分防止单点访问瓶颈，最终格式预生成，apenAPI需要返回xml，json格式。
刚才说了介绍cache的架构，现在介绍cache的第二个方面就是使用流程。有一个典型的场景，比如说发表我们cache怎么操作，首页展现怎么操作。发表需要改变三个内容，首先我们要声称contentcache，对于常规contentcache我们也要做复制，如果对方粉丝在线会在inbox数值ID变更。
第三方面修改outbox，根据粉丝列表修改inbox数据列表，然后首页Feed操作流程。左边有两个：inbox，outbox。两个是可选的，如果inbox没有我们有一个树型计算，我们会根据ID列表聚合起来反馈给I用户。
获取首页Feed的流程，首先间看inbocache是否可用，获取关注列表，聚合内容从following关系，根据idlist返回最终Feed聚合内容。最常用两个流程就是这样。
下面介绍微博cache经验谈，首先说流量。打开首页，这个时候打一个I来说，比如说contentcache为例，比如multigntn条Feed，cache大小等于N，并发清且如1000次/秒，总流量等于50，20K。假如我们机房里面有1万并发需要800MBPS贷款，如果不改变价格这个流量是实现不了。再一个1G内网我们做了很多压力测试，一般环境跑三四百兆已经不错了，你网内不光是访问cache开销，还有很多其他流量，因此我们需要优化带宽访问，我们可以把热门数据加载到localcache，要用压缩算法，可以做复制，有的时候将一个内部cache分组，不同的服务器组，访问不同的cache减少内网通信的开销。第一个问题就是带宽的问题，其中内销cache开销访问量大第一会碰到瓶颈。第二问题就是hotKeys，我们要访问姚晨的微博，我们要建设一个Ilocolcache，删除时间要把所有的都删除。
cache规划方面一些问题，将不同业务，不同长度KEY存储到不同的MEMcache，不同的业务有不同的生命周期，LRUcache小量，memorystorage大部分，更高效的内存利用。
mutex，什么情况会出现这个问题，比如说一个很热的内容，cache里面没有了，因为memcache不是很可靠的东西，你放在里面可
能会消失，经常出现这样的情况：一个很热的cache没有了，因为我们系统有很多并发很热数据没有了，非常多的并发如果我们没有一个很好的策略，比如说几十个，几百个加一个内容这会是一个悲剧。我们给每个KEY加载MUTEX，这个并发连接取数据库，然后把mutex删除成规，这个时候我只需要一个连接，数据库加载到BD里面有可以了。
因为前面已经介绍很多内容，我今天介绍一个很简单的东西就是想关注更多微博平台的技术，有三个方向一个就是S2技术沙龙，每个月举行一次，另外就是说对很多讲师光做讲座不过瘾，讲座只是传授别人东西，没有能够交流，所以我们对一线架构师有一个自己线下交流，我们讨论一些实际中遇到的问题，对这些架构师有帮助提高，交流一下自己正在做，或者有一些东西还不成熟，不适合拿出来讲的东西，可以线下交流。另外我们有各新浪微博开发大会，会介绍更多微博平台架构分享的东西。
S2技术沙龙介绍了希望关注分享Web2.0技术，下面有一个它的网址，另外就是说介绍一下即将举行一个新浪微博开发者大会，主要除了宣传作用，希望更多分享新浪微博技术，比如说这个平台需要架构与存储，可能到时候讲比今天更深入一些，会讲一些sinaappengine技术，数据挖掘，合作与商业模式，开发者与平台。目前有一个开发平台的网站。
今天介绍比较简单主要是这样看看有什么可以提问。
提问：我想问一下新浪微博设计之初有没有考虑过安全的问题，图片存储等等，这种方面的问题这个微博设计之初考虑很多安全方面工作，我想了解一下这方面有什么看法和见解。
杨为华：我们也在解决两个方面，一个用低质量内容，有一些搜索用户可能做了一些不好的东西，故意出现一些关键字让自己搜索排名更靠前，有一些用户发广告，对于传统广告我们有一些技术，新浪博客有一些技术，通过一些词语热度可以判断一些内容是不是广告内容。实时搜索我们也正在做，这方面我们也刚开始起步。
提问：我之前是跟腾讯微博有相关的，但是我已经不在腾讯了。
杨为华：没关系，腾讯微博也可以一起探讨。
提问：我想问一个比较细节的问题，你说到为了节省内部带宽的问题会使用到logcache，这个部署你们是跟Web2.0服务器放在一起还是什么？
杨为华：每个前端布置一个cache，另外还有一些APC那种基础非cache的技术，或者其他内存数据共享这种，非标准的方式都可以做，cache是一个很泛的观念。
提问：获取cache会用MUTEX的技术。这个环节具体是什么？这个环节是在哪个环节做的？
杨为华：写到一个典型的场景，热点内容有很多人同时访问这个网站，这个cache量没有了，如果不做任何保护实际上数据库访问压力很大，还有其他场景，还没有复制过来数据就过来了，很多人认为cache没有加载访问数据库也是比较悲剧。
提问：这些东西是在应用这个层次做还是类似也有一个cache上面做？
杨为华：我们是应用做的。
提问：我请问一下您微博系统使用cacheDV。
杨为华：计数方面用了。
提问：你有一个推模式，你用复合模式，你们简单介绍一下你们怎么用这个复合模式，对微博每个人都会有一些好友有会跟随一些人，能不能讲一下对于个人主界面缩影算法，我看到我的界面怎么知道哪些人在前面，哪些人在后面？能说一下你们的算法，每个人登陆进
去有一个我的主界面，我有一些好友，也是一些人的粉丝，你们怎么做排序？
杨为华：我们就是时间排序，最简单的方法，我们没有找到更好的算法之前。
提问：不是根据一些热点？
杨为华：我们也考虑过那个方向，但是我们认为挑战性非常大，你认为好的方法用户不一定认可，这个挑战很大。你用算法做一些东西，但是用户认为不重要的东西，如果用户没有展示，用户可能也会有其他看法。为什么用复合模式，我们也不知道为什么叫复合模式，我们根据实时运行情况，发现哪里有瓶颈我们会想到更好的方法解决。这个瓶颈，能不能给在线用户加一个什么东西，减少系统压力，不影响原来的价值，主要处于每个性能模块的角度考虑的。
提问：你能不能说一下一个用户登陆以后你们做了一些什么步骤，我估计有些是用推的，有些是用拉，各个平台设计微博不一样，有的速度很快，有的会有延迟，你能介绍你们用户交流流程吗？
杨为华：这个图可以看到，最前面还有别的cache，用刚才方式我们看有没有命中，如果没有通过OTUBOX关注列表进行计算，然后把结果合并起来，在上面有一些配件成了cache，反映给用户，整个流程跟这个图上原理来说区别不大。
信息
目前是这样的思路，逐渐改进中，希望高手指点- -
一个微博数据库设计带来的简单思考
在微博系统中，当前用户、关注者（也就是粉丝）、被关注者（崇拜对象）这三种角色是少不了的。他们之间看似简单的关系，但是其中数据库表将如何设计，却让我很难琢磨，在如下解决方案中，你们会选择哪种? 为什么要选择这种? 是否有更好的解决方案?
解决方案一：
表名用户信息表
字段名字段代码字段类型描述
用户名 U se r_id V archa r(20) 主键
登陆密码 Passw ord V archa r(20)
…… …… ……
表名关注和被关注者表
字段名字段代码字段类型描述
用户名 U se r_id V archa r(20) 主键
关注者 F uns Te xt
被关注者Wasfuns Te xt
这是我最初想到的一种设计，这里“关注者”和“被关注者”都是采用拼接一些特殊字符分割存储的，比如A用户有只有关注者B、C、D、E，那么存入数据库关注者字段的数据将是B;C;D;E（暂且认为分割字符为；）。
基于上述方案，我提出一个问题：当这个用户的“关注者”或“被关注者”数量很大的情况下（比如10 万个关注者）将是怎样的一串字符呢？而且当我们需要查询“关注者”或者“被关注者”最近的博客信息，将面临和博文信息表的一些时间排序查询，处理难度是要浪费性能的。
解决方案二：
基于上述面临的问题，有人给我提供了一个扩展性的解决方案，同时也很好的解决了一个字段海量数据的问题。将方案一中的关注和被关注者表分解成两张表，如下：
表名关注者表
字段名字段代码字段类型描述
编号 Id Num be r 主键
用户名 U se r_id V archa r(20)
关注者编号 F uns_id V archa r(20)
表名被关注者表
字段名字段代码字段类型描述
编号 Id Num ber 主键
用户名 U se r_id V archa r(20)
被关注者编号Wasfuns_id V archa r(20)
我看到这样的设计我很吃惊，试想一下，假如我一个用户对应有1W个关注者，那么该用户就会在关注者表中存在一万条他的记录，这难道不是严重的数据冗余吗？这甚至不符合数据库的设计规范。但是事实上证明，这种设计对大数据量的扩展是很不错的，既然如此，那假如用户和用户之间的关系不只是限于关注和被关注的关系，是不是又要新增表？
解决方案三：
话说“合久必分，分久必合”，对上述的设计再进一步修改，于是将方案二的两张表又合二为一，如下：表名关注和被关注者表
字段名字段代码字段类型描述
编号 Id Int 主键
用户名 U se r_id V archa r(20)
目标对象 O perate_o bject V archar(20)
状态 Sta tus N umbe r
当目标对象为关注者，标示为1；
当目标对象为被关注者，标示为2；
当双方互相关注，标示为3；
当目标对象为OO，标示为XX。
O K，这样的设计不仅解决了相当一部分的数据冗余，而且还能表示用户之间的多种关系，方便系统日后的扩展。但是问题又出来了，很明显这样设计对状态的维护也是存在疑问的，用一张表代替多张表，数据肯定是成倍的增长，是否不符合当前常说的“拆库拆表”的战略方针（好像这样的状态一般用于“标记男女”或者“是否删除了”之类的，貌似用于这种场合比较的少）。
做一个微博项目，如何设计数据库表，指点指点，谢谢了。
用户模块
|- 用户注册
|- 填写用户名，昵称，生日（选择），性别，密码，密码提示问题，密码答案完成注册（要求验证用户名不能重复，并加入验证码）
|- 个人资料
|- 可以对昵称，生日，性别以及自我介绍进行修改。
|- 上传头像
|- 选择上传用户头像，只允许格式jpg，jpeg，gif和png，且大小小于2M
|- 我的听众
|- 查找所有收听我的用户，并列表显示（6条，显示信息参考找人的列表），对于你没收听的用户，可以选择立刻收听
|- 我收听的人
|- 查找所有我收听的用户，并列表显示，可以选择取消收听此用户。
|- 私信
|- 收件箱
|- 可以查看收到的所有私信，列表显示（5条，按时间倒序），显示发送用户的昵称，照片，发送内容，发送时间
|- 可以选择删除某封信，也可以选择直接回复私信
|- 发件箱
|- 可以查看所有发送过的私信，列表显示（5条，时间倒序），显示接收用户的昵称，照片，发送内容，发送时间
|- 可以选择删除某封信，也可以选择为其再写一封
|- 写信
|- 输入收信人帐号以及发送内容，将私信发送给该用户
广播模块
|- 我的大厅
|- 显示当前登陆用户的照片，昵称，并显示我当前的听众数量以及所有发送过的微博数量
|- 可以在输入框里发送自己的微博信息，允许上传一张图片（也可以不传）|- 可以显示所有收听的人和自己发送的最新微博信息（时间倒序，5条每页），显示时要显示发送人昵称，照片，时间（显示距当前系统时间的差距，例如：XXX分钟前，XXX小时前，XXX天前。只需要显示最大范围的单位即可，例如：如果是1小时30分前，只需要显示“1小时前”即可。）
|- 显示最进的热门话题（显示5个，按消息数量倒序）
|- 我收听的话题（显示5个，按消息数量倒序）
|- 我收听的用户（显示9个，按听众数倒序）
|- 广播大厅
|- 显示所有人发布的微博信息（5条，按时间）
|- 可以选择30秒自动刷新功能（选中的每30秒自动刷新页面）
|- 热门话题，我收听的话题（同上）
|- 我的广播
|- 显示我发布的最新微博信息（时间倒序，5条）
|- 其他同上
|- 提到我的
|- 显示所有微博消息中对我发送的消息（在对话和转播中查找，5条，时间倒序）
|- 收藏广播
|- 显示我收藏的所有微博信息（5条，时间倒序）
|- 对话，转播
|- 可以针对某条微博进行对话、转播（与正常发送功能相同，但列表显示时显示对话的那条微博信息，转播也同样处理）
|- 新建话题
|- 发表微博信息时可以输入一个话题名称，如果该话题不存在，则保存此话题，如果该话题存在，则直接将这条微博消息加入到这个话题中
话题模块
|- 热门话题：显示15个话题（按信息数量倒序）
|- 收听话题：显示15个话题（当前登陆用户收听的话题中按信息数量倒序）|- 话题内容：显示该话题下的所有消息（每页5条，按时间倒序）
其他
|- 公告
|- 公告列表，每页3条按发布时间倒序
|- 公告详情：显示公告标题，公告发布日期，内容
|- 搜索（广播，找人）
|- 找人
|- 进入找人页面后，显示出最新的6个注册用户，以及推荐的12个用户（按广播发送数倒序，取得发送最多的12个人）
|- 输入查找的内容后，依据用户名，昵称来进行模糊查询，列表显示（5条），显示时要显示照片，昵称，最新发布的广播，收听人数以及广播数，可以选择收听这个用户
|- 查找广播
|- 依据关键字查找符合条件的广播（5条，按时间倒序，显示发布昵称，照片，内容，发布时间）
微博数据库设计
看用什么语言写，用php+mysql比较合适，sql数据库应该学过吧！这个学过的话在网上下载一个开源的记事狗微博（https://www.doczj.com/doc/1618050515.html,/），模仿他的数据库设计，微博涉及的数据库很简单，写过留言板的都可以弄，就是权限系统会复杂点！
学习园地:微博项目
介绍
微博是一个时下很火热的web2.0应用，使人们能随时随地的用手机或电脑获取信息和发布信息，基本功能比较简单，但要做细化功能和提高性能也是需要相当多的经验，所以想让大家通过自己制作一个微博系统来锻炼web开发能力及项目经验。
什么是微博：http://help.s ina.c om.c n/i/232/482_12.html
程序员的门槛现在越来越低，85后90后现在都开始进入这行了，其实真正要把代码写好，需要很多的经验和技巧，是个长期积累的过程。微博这个项目没有太高深的技术，就是大家已经学过的as https://www.doczj.com/doc/1618050515.html,,s qlserver，HTM L等，主要是通过这个项目锻炼一下编程的各种基本功，巩固已经掌握的知识，稍微全面的了解一个小型项目的开发流程。
本活动可培养如下能力
1、通过CodePlex的VSTF代码管理，练习源代码管理器的使用。
2、通过分析新浪微博的功能，锻炼业务分析能力。
3、通过编写各种文档，增强对Word的使用熟练程度。
4、通过编写用例分析文档，锻炼需求分析能力及编写有效用例的能力。
5、通过编写概要设计文档和详细设计文档锻炼文档书写能力和基本的设计能力。
6、通过画分析和设计阶段的U M L图锻炼UML能力及提高V is io使用熟练程度。
7、通过设计数据库增强数据库的设计能力，以及优化数据库查询的能力。
8、通过简单的界面设计锻炼c ss布局的能力及css,html的熟悉程度。
9、通过实现页面的ajax功能提高大规模js代码编写能力以及ajax库的熟悉程度。
10、通过单元测试培养重视代码质量的观念以及提高单元测试的经验和技巧。
11、通过服务端代码的实现锻炼as https://www.doczj.com/doc/1618050515.html,的熟练程度以及增强.N ET类库的熟悉程度。
12、通过解决排查测试出来的问题锻炼代码调试的能力及代码重构的能力。
活动过程
1、了解微博功能
注册新浪微博，分析其功能，罗列出功能列表，并知道每个功能对最终用户的价值。
输出：《新浪微博功能分析》《XX微博逻辑设计》
前者是对新浪微博的功能分析结果，后者是在前者的基础上进行裁剪或者改进定下来将要做的微博系统功能列表及每个功能的逻辑，用户看到逻辑设计后就可以知道每个功能怎么用。
2、在CodePlex注册项目
在c odeplex注册一个开源项目，以后所有相关文档和代码都放在上面，源码和文档的目录结构要设计清晰合理。
输出：项目的名字，c odeplex的项目地址
3、写用例分析文档和功能测试方案
查阅相关书籍或者网络资料，了解如何写用例分析文档及注意事项，根据第一步对微博功能的了解，写出用例分析文档。
用例分析文档有了之后，要根据它制定功能测试方案，比如用户如何注册账户，如何发微博，每一个操作步骤，每一步的预期，都写清楚，关于如何写测试用例可查阅相关资料。
输出：《XX微博用例分析文档》《功能测试方案》
格式要求用word，要生成目录索引，页眉页脚，格式要求统一专业。
4、概要设计和技术方案
根据逻辑设计和用例分析文档，做出系统的概要设计，大概用到哪些类，类的公开成员，类之间的关系，关键用例的序列图。并在此阶段确定出技术方案，服务端使用什么语言和框架，使用什么客户端ajax框架，数据库使用什么，需要不需要第三方库以及大概的主机需求，硬件方案，容量估算等。
输出：《XX微博概要设计》《XX微博技术方案》
UML图使用visio画，UML知识可参考网络文档，使用最多的是类图，序列图和组件图。
5、详细设计
细化概要设计，把类的私有成员细化出来，关键用例的序列图，关键算法的描述，性能考虑等写出来，服务所需要的配置项，需要设计哪些性能计数器，哪些环节要生成日志，日志的格式约定，哪些地方使用缓存，平台有哪些角色，每个角色的权限是什么。
输出：《XX微博详细设计》
6、数据库设计
根据详细设计做出数据库设计文档，表，索引及主要的存储过程，注意表，索引和存储过程的命名规则要统一，并分析出最常用的DB 操作的性能消耗，以及如何控制。
输出：《XX微博数据库设计》，建库脚本
7、界面设计及编码
用HTM L和CSS进行页面的布局，不需要搞太漂亮的图片，主要锻炼H TML+C SS的使用能力，模仿一些比较成熟的网站布局就行，看能否模仿出来。
通过前期的准备，用V S2008进行编码，包括HTML,JAVASCRIPT,C#,SQL，CSS等，在编码的过程中同时审视前期做的设计和分析是否有遗漏或者错误，并同步更新文档。
输出：代码。
8、单元测试
在编码过程中要对c#代码中的业务逻辑进行单元测试，找一些单元测试相关的最佳实践资料来学习，单元测试可能会有一些困难，遇到困难可以在相关社区求助，锻炼利用网络解决问题的能力。
输出：单元测试项目及代码测试覆盖率统计
9、功能测试
自己作为一个使用者根据先前制定的测似方案对最终的代码进行测试，包括在各种浏览器好分辨率下的兼容性测试。
输出：《XX微博功能测试文档》
10、部署文档
把代码输出打包，编写用户使用帮助，管理员配置说明，运行监控及维护方法等。
输出：xxx微博.rar，《XX微博使用帮助》，《XX微博部署及维护说明》
在每一个阶段性里程碑的地方，可以把输出拿出来大家讨论一下，然后再往下进行，在进行的过程中可以把自己认为不错的资料转贴到小组里，分享给其它同学，遇到问题也可以在小组里进行讨论，最可怕的就是什么问题都没有。
林昊，网名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.doczj.com/doc/1618050515.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.doczj.com/doc/1618050515.html,/view/1567099.htm，百度百科
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.doczj.com/doc/1618050515.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之间不存在谁模仿谁的问题，虽然双方都在