这个话题应该是在一年前就应该想的了，只是自己的思维比较迟钝，今天才想起了这个问题。下午没事突然对我们公司的SNS的好友动态是如何实现的很感兴趣，于是问了一下大风同学（一个大牛），记得feed的底层是他负责的。
然后他就告诉我了，首先是建了一个用户动态的表，每个用户在做不同事情的时候（比如发表日志、修改心情、分享动作等）就会往动态表里面增加一条记录，然后通知后台进程，这个进程是专门处理feed消息的分发的，比如我修改了心情，在动态表里面存了一条记录，然后后台进程取出这条数据来，再根据这条数据里面的uid，去查询他的好友（比如我有10个好友），然后往另外一个表（这个表就是用户登录时查询这个表来获取用户的好友动态）插入10条记录，内容就是我改心情的消息，只是uid字段是10个好友的uid。
我发现这样的话动态表的数据量会很大，我们公司线上的每天都有几千万的feed信息。真不知道facebook他们每天feed的消息会有多少亿了。不过也许设计方案不一样。
刚刚上网搜了一些SNS中的好友动态设计方案，找了几篇不错的文章，可以阅读一下：
SNS中好友动态功能的设计思路
sns网站的好友动态的数据结构设计讨论
常见功能设计之 “好友”
SNS中, minifeed, 邻播, 好友动态中，防止信息爆炸的思路
后面三篇文章跟这个关系不太大，只是讨论SNS中的好友关系设计，也可以阅读阅读^_^
这样操作一定是有问题的，即不节省空间，效率又不高，而且一旦修改的话，会有问题。
空间增加了一倍，不算很大。 效率不高你指表现在哪方面？ 修改什么会出现问题？
你好，我是souout得站长，非常感谢您的支持， 现在souout商业化了，不好意思，这个链接过期了.
哦，原来这样，那只能把它去掉了，呵呵，分析得是挺不错的。