1、应用场景：比如QQ空间、微博等的好友动态

XX分享了图片。
XX发布了新日志。

不过我这个系统比较简单，就像instagram，只有分享图片，然后关注者可以在动态里面查看到。

2、目前了解的，比如新浪微博，一般采用推拉模式

推：推送
拉：查询

3、我的想法是找一个能应对产品运营初期的方案，不要用太复杂的技术和软硬件实现。只是能让产品快速上线，又能应对早期一定量的用户。

4、说说我目前的想法

4-1、如果我采用推：比如一个用户有几万粉丝，那么就要在发布的时候，产生几万条推数据。我感觉数据量和操作都比较费时。当然了，可以异步等等，我在新浪微博的技术架构ppt里面看到用比较复杂的技术来实现，比如什么MemcacheQ。
此外，新浪微博说第二版的时候才采用MemcacheQ，第一版就简单的推模式。我不知道我假设的一个用户几万粉丝，当他发布一条消息的时候，服务器insert几万条记录速度是不是很慢。当然了，运营初期，一个用户几万粉丝这种情况应该没多少。比较倾向这种方案，因为有利于以后的扩展。

4-2、如果拉吧，就是用户登录，查询他所关注的用户的动态。查询sql大概如下：

select * from 动态表 where uid in（所关注的uid）
这个“所关注的uid”，如果有几千、几万怎么办？还一个in查询，速度肯定慢了。

或许吧，做点分表，分成几张表，一个星期的数据、一个月的数据等等，再做点缓存，这样下来，查询速度应该差强人意了。

所以，总结之下，都没特别特别满意的方案。有做过类似需求的同志吗？指点一下，谢谢。