【方法1】
按照常规的设计涉及到 几个表
[user] 用户信息表
id (int)
name
[user_msg] 用户发表动态的表
uid (int)
date
content
[user_care] 用户关注表
userid (int)
useridb (int)
如果我关注了1000个用户
那么用户中心首页把这1000个用户的动态,按照时间顺序展现出来前100 条,可以分页
那么sql 就是
select top 100 * from [user_msg] where uid in(select useridb from [user_care] where userid=我的用户id) order by date desc;
这样用 in 性能是不是非常糟糕??
有没有更好的办法?如何设计呢?
我也在其他地方提问
得到结果
【方法2】
目前我想的是这样,楼上有也这样说
但是数据量很大,单用户动态多的话,粉丝多的话,用户总数多的话,每天的推送量估计要排队好久
网站整体性能估计还是不行,只能堆服务器
1、当一个用户产生一条内容的时候,存储在数据库一份内容,同时发送到另一台服务器专门处理动态
2、另一台服务器接收到一条动态,根据这条动态的用户信息,找出该用户的粉丝列表
3、
用户id 1-10000 的用户订阅动态 放一台服务器
用户id 10001-20000 的用户订阅动态 放一台服务器
用户id 20001-30000 的用户订阅动态 放一台服务器
用户id 30001-40000 的用户订阅动态 放一台服务器
.................
这样就可以动态的扩展服务器
根据粉丝列表的id ,分别把这条动态发送给不同的服务器去处理存储
4、某用户中心的用户看动态的时候,实际上访问额不同的服务器
【方法3】
http://www.cnblogs.com/sunli/archive/2010/08/24/twitter_feeds_push_pul...
来问问有没有更好的办法,也想知道新浪微博 推特这些网站是怎么实现的?