做SNS的，一起来猜猜新浪微博的核心Feed系统是怎么设计的吧

要是不清楚什么是feed，google之。

Feed是sns类应用的核心和最复杂的部分，就是sina微博中看到的“我关注的人”的消息。像人人网中的“新鲜事”等等，都是一个东西。你想啊，你关注了几千人，又被几千人关注，你发了一个消息，另外几千人怎么看到哪？拿数据库做join和in操作肯定立刻挂。而且像sina weibo，数据和访问量庞大，怎么实现哪？这其实就是传说中的推和拉的选择，人人网写过一篇文章：http://news.csdn.net/a/20100726/277273.html，简单来说以推为主体。我猜测可能在某些情况下会使用拉，例如这个账号很久不登录，太不活跃，给他推东西纯属浪费。嗯。。。，这方面也欢迎一起来猜猜。

基于这些，我猜测的第1版架构图（我们现在就是这样做的，规模比较小，还看不出问题）：



整个架构基于memcached + mysql，图中分了ABC三个区域。所有的消息存储在mysql中，无论推送给多少人，只存储一份。另外有一个索引表，用来记录推送关系，推送给1000个人，就增加1000条记录，也就是图中的A。当发生查询时，从索引表中根据用户编号进行一次简单查询（基于用户编号为索引和条件的select），拿到索引结果后，进入B，从memcached中读取实际信息。如果不存在或者不全，进入C，根据索引信息读取网友实际发表或者转载的内容，用模板生成消息并存储到memcached中，然后返回来。

在整个过程中，B是memcached集群，性能应该问题不大。C是cache后面的东西，其中的数据库查询也是基于索引表中给的对象主键，分表条件等进行的分库分表基于主键的查询，性能问题应该也不大。关键是A区。我们现在的方案是用guzz框架把索引表分到单独的一组数据库中，然后根据用户id进行切表，每个人保留最多200条最新消息的索引。总的来说，每张表的大小还在控制内。对于像#话题#等也是一样的，建立索引表分发。无论怎样，实际的消息只有一份。

我猜测，sina微博第一版系统应该就是这样。架构简单实用。

但随着规模的扩大，A区索引表肯定会逐步出现大量性能问题。要升级到第二，第三版。这两个之间或许是一步到位的。

第二第三版架构猜测：

A区的性能问题不是mysql能够解决的，但幸好A区的数据结构非常简单。就是以 用户id+某个动态功能 为key下的一个固定大小的索引集合。最简单的办法就是把mysql换成nosql，这个数据结构用nosql应该非常容易实施。我没有用过nosql，但通过资料来看，相比mysql肯定是一大性能提升。我们暂且推测其为第二版方案吧。欢迎实际用过nosql的来谈谈行不行。

我们假设，第二版方案也解决不了问题。A区的性能问题太大了，怎么办？如果这样，我想索引系统只能是自己做了，谁也靠不住。我有个猜测，欢迎讨论。看下图。



这个架构是完全为feed定制的，我们为每个 用户id+某个动态功能 分配一个磁盘block。在索引表中，我们知道每条索引记录的大小是固定的（假设每条1k大小），而为用户提供的最多最新动态数也是固定的（假设200条）。那么我们这个block就分配固定的201K，前面的1k是头信息，后面的200k存储最多200条的索引记录。

在头信息中，记录这个块操作的系统版本号（升级使用），用户信息，操作的偏移量，总动态数等等。当插入一条新索引时，根据操作偏移量直接定位位置，写入；如果已经写到第200条，回到第一条覆盖写。读取的时候，根据偏移量数据直接读。因为记录大小固定，block维护简单，顺序读写，效率肯定不差。而这些block文件块，将存储在一套分布式文件系统中，依靠还算成熟的hadoop技术，无限扩展这个大集群。

相比数据库的优势，还省去了清理过期数据的问题。

这里面没有讨论block块缓存的问题，这是分布式文件系统的工作。对于不同的动态，可能block的大小会不一样，这都是可以的。

不知道猜的对不对。

评论

16 楼 myreligion 2011-03-09  

ch_space 写道

peterwei 写道

哥，你画的图也太恶心了吧，搞得我没有看的欲望。晚上抽空再看。想了解和深入的办法，就是我们自已去实现一个weibo,搭一下他们的架构。然后再回头看他们那些理论和谈话。

+1

不好意思，本来想拿ppt画，发现还是mspaint一目了然。像在纸上画图一样。呵呵。

15 楼 java_xiaoyi 2011-03-09  

ch_space 写道

peterwei 写道

哥，你画的图也太恶心了吧，搞得我没有看的欲望。晚上抽空再看。想了解和深入的办法，就是我们自已去实现一个weibo,搭一下他们的架构。然后再回头看他们那些理论和谈话。

+1

++1

14 楼 ch_space 2011-03-09  

peterwei 写道

哥，你画的图也太恶心了吧，搞得我没有看的欲望。晚上抽空再看。想了解和深入的办法，就是我们自已去实现一个weibo,搭一下他们的架构。然后再回头看他们那些理论和谈话。

+1

13 楼 linliangyi2007 2011-03-09  

有想法挺好，主要是实践，feed的复杂是量引起的，所以那种可行，试过就知道了

12 楼 peterwei 2011-03-09  

哥，你画的图也太恶心了吧，搞得我没有看的欲望。晚上抽空再看。想了解和深入的办法，就是我们自已去实现一个weibo,搭一下他们的架构。然后再回头看他们那些理论和谈话。

11 楼 myreligion 2011-03-09  

NanguoCoffee 写道

是我被你忽悠了呢？ 还是我语文理解能力不足？

1. 我觉得现有对外公布的资料都太表面了，具备社区进一步讨论的价值。

2. 这种架构看起来也不是很一气呵成的方案，更像是修修补补的东西，说不好有更好的方式。虽然纸上谈兵，但也具备讨论价值。

你总不能迷信TimYang给的东西就是教科书，按照他的思路模仿就行了吧？

10 楼 NanguoCoffee 2011-03-09  

是我被你忽悠了呢？ 还是我语文理解能力不足？

9 楼 myreligion 2011-03-09  

NanguoCoffee 写道

http://timyang.net/architecture/weibo/

微博大会我参加了。这个ppt当时听过。

我还记得当初提出了一个用差值计算评论数等的说法，具体不知道怎么做的。

我发这个帖子并不是想打听新浪微博的架构，只是希望大家一起讨论下 新浪微博级别 的Feed系统怎么设计。在业务发展过程中，可以设计出什么样的方案来，一起交流。

8 楼 myreligion 2011-03-09  

NanguoCoffee 写道

http://www.slideshare.net/iso1600/cache-4842490

刚看了一遍，这些东西有什么看的，是个人都知道，从JLive的论坛年代就开始了id cache。关键是怎么落地。我觉得这个ppt并不比我提出的这个分布式文件系统的方案更有参考价值和讨论价值。

7 楼 NanguoCoffee 2011-03-09  

http://timyang.net/architecture/weibo/

6 楼 rocketball 2011-03-09  

应该用的是非关系型数据库吧

5 楼 NanguoCoffee 2011-03-09  

http://www.slideshare.net/iso1600/cache-4842490

4 楼 myreligion 2011-03-09  

哪儿有写？

3 楼 NanguoCoffee 2011-03-09  

知道总体架构 和 关键问题的处理方案后，还需要细节么？

2 楼 myreligion 2011-03-09  

涉及到细节全保密吧？

1 楼 NanguoCoffee 2011-03-09  

请搜索timyang
不用猜，timyang会告诉你的