新浪架构师谈微博架构.docVIP

微博(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发布信息表 info：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、慢的消息通知我们每一个用户建立一个InBox和OutBox，InBox包含关注我的用户ID，OutBox是我关注的用户ID。Box分为三个部分，一个是基准Box，一个是添加Box，一个是删除Box，实际的Box数据是基准Box和添加Box的并集和删除Box做差集后得到的集合。1、用户插入关注用户，在用户的OutBox的添加Box加入一条，同时在被关注用户的InBox的添加Box也加入一条添加2、用户删除关主用户，在用户的OutBox的删除Box加入一条，同时在被关注用户的InBox的删除Box也加入一条添加3、微博产生后发送消息，将发送微博的用户的InBox（其中含基准Box，插入Box和删除Box）连同微博操作连接一起发送给消息处理器。4、消息处理器合并Box，并把Box的内容回写到发送微博用户的InBox的基准Box中。5、在后台添加一个Box合并进程，缓慢的合并用户的Box数据。6、前台在展示的时候，因为没有合并，展示列表展示OutBox的基准Box和我新添加用户的Box以及删除用户的Box内容。前台展示是需要商榷的，看PUM是否接受这种方式，如果不接受，我们只能在刷新时预测查询基准表，并且在页面合并。因为前台展示通常是分页的，这样会比较难获得准确的分页量，每页的显示