关于SNS动态消息的思路和处理。

见链接：http://www.iteye.com/topic/176677?page=2
下面这条比较值得推荐：
1.用户拥有好友的id列表
2.数据库允许通过id直接定位到记录或者数据块（用hash或者定长表，不要用b树索引），保证通过id查询时间最短。
3.每个用户都做近期操作的Log，存到自己id对应的记录或者数据块中。
4.访问某用户的好友近期操作时，直接按照好友id列表取出对应用户的log.
5.对log组成的新表按时间排序...

其实只需要四个字段就够，获取数据时真正关心的是ID, 时间，显示需要关心的是数据和样式
user_id
operation_raw_data
operation_type
operation_time

根据operation_type从cache中获取operation_render_template

性能排序：
1.消息分发，最差，对于用户每个操作会产生大量io，不适合用户量多的情况。
2.用户操作日志使用单一表，较差，因为数据量多，每次查询后排序将会浪费大量时间。
3.对每个用户都建立一个操作日志表，较好，缺点是建立的表太多，但是查询速度相对快。
4.自行实现每个用户的操作日志表，直接使用链表，头指针使用定长顺序表或者hash表，查询的同时可以按时间合并链表，计算可控，速度最快。

最近也在做这个东西，刚才看了大家的讨论，终于想通了该怎么做了。现在给大家说说。

建一日志表，记录所有用户的操作日志，结构如下：

 

event（事件）

字段名称	类型	默认值	描述
ID	Int(10)		自增长，主键
userID	bigInt(20)	Not null	用户ID.索引
userName	Varchar(20)	Not null	用户姓名
content	text	Not null	内容
createTime	int(10)	Not null	创建时间.索引

 

 

content中保存用户的操作日志，也就是本贴讨论的重点。我采用的方法是前面有同学提到json方式。如：

{

 "blog":[

  {"id":1,"title":"安利台湾25周年庆"}

 ],

 "photo":[

  {"id":1,"title":"51韶关游"}

 ]

}

 

 

 

其中blog、photo代表某种应用的标识，可以无限添加。只要显示的时候能分析就行。里面的id和title就是内容的属性，结构自定。

 

 

 

至于新旧操作怎么合并，我是采取对event表的插入操作进行拦截实现的——我定义会员所有的操作均调用event的插入方法。

 

 

在拦截函数中，先select该会员的记录。如返回为空，则直接插入新记录。如返回记录，则将待插入数据与原数据进行合并。如待插入数据为：

{

 "blog":[

  {"id":2,"title":"我是谁"}

 ],

 "share":[

  {"url":"http://www.tudou.com","title":"土豆网 - 视频 - 播客 - 每个人都是生活的导演"}

 ]

}

 

 

则合并后的content为：

{

 "blog":[

 

  {"id":2,"title":"我是谁"}

  {"id":1,"title":"安利台湾25周年庆"},

 ],

 "photo":[

  {"id":1,"title":"51韶关游"}

 ],

 "share":[

  {"url":"http://www.tudou.com","title":"土豆网 - 视频 - 播客 - 每个人都是生活的导演"}

 ]

}

 

 

然后使用update方法即可。

 

 

 

但这里有一个问题就是，如果用户每天或每个数据表清理间隔中（如我的系统定义为2天）都有操作产生，则会累积很巨大的历史记录，我初步考虑是在拦截方法中进行过滤。而如果用户在2天内没有新的操作产生，则会被我另外定义的数据清理任务删除记录。

假如现在有个需求,用户可以自行删除好友的动态,比如他已经看到好友动态某人写blog了,不想再知道这条消息了怎么处理？

回楼上。要做也可行，即然都用了json。那就把你的好友都放进来。要删除的去掉就OK了