大型网站用户消息实现机制探讨

大家好：在大型网站中如何更好的实现用户消息机制，我想到的方法有以下两个：

1、用户的新消息计数保存在一个表中，而消息本身保存在另外的表中，这样的话，获取用户新消息数很快，获取消息列表也比较快，但是，在没有采用事务的前提下，可能存在数据不一致性，就是新消息数和消息记录对不上的情况，不用事务有响应速度的考虑。

2、新消息和历史消息分开保存，新消息数要每次count，消息总数和消息列表要关联新旧消息两个表，不过，这样保证了数据一致性，也不存在过期数据清理的问题。

在这里想跟大家探讨一下，有没有其他更好的实现办法，谢谢

第一种好了，这个数字无所谓的。不对就不对吧。

呵呵，不对的话，用户投诉多

好友列表：
$userlist = select followed_id from Relation where follower_id=1


消息更新列表：
select id from message where author_id in ($userlist) order by id desc limit 21

消息数：

select count(*) from message where author_id in ($userlist)

你好，没有太明白你的意思，能解释一下吗？

你想复杂了，还是一张表搞定就行了，用户初次登陆count一下就行了，查到的东西选择性的放入cache，以后操作信息的时候对cache进行下同步处理
想好cache策略和兼顾前端服务器集群下的cache同步

你好，你的想法不错，曾经也想到过，但是如果消息的种类比较多的话，初次登陆的时候要count多个表，这样似乎会影响登录的速度。。。感谢你参与讨论

都说高性能网站要 牺牲不一致性啦！！！！

只要你的count不是全表的就问题不大啦，建好索引还是很快的。

在一定程度上同意你的说法。。