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

这位老兄的口气挺大的，我看新浪这套方案就挺好的。
比如说您也拿出你的建构方案，跟他比比，让我们无地自容一下，期待。

 

 我觉得这个朋友说的有些道理

javascript难道是吃干饭的吗？ 要我设计，每个垃圾信息都设计成xml格式，客户端用XSLT聚合起来就可以，还可以享受免费的browser cache

采用推的形式，分布式队列，异步化。
行级缓存：memcached，redis。存消息主体。
列级缓存：redis，TT，存收件箱和订阅关系。
注意处理关系列表时，大数据量的问题。
Mysql：用户分表，存订阅关系。动态，按时间分表。

从杨卫华的微薄看  这位仁兄的说法比较靠谱

长连接好像有个名词是comet

++9

要是不清楚什么是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的大小会不一样，这都是可以的。

不知道猜的对不对。