谢谢大家
谢谢大家
推和拉模式的选择问题吧
如果选择推,那就类似上面两位的方式最简单,可能数据量有点庞大,但是一张消息表搞定
如果选择拉,那除了消息表(msg_id,msg_content),还要单独有一张用户消息表(uid,msg_id,status),你发一条消息的时候是发给N个用户的这个表里就会有N条记录,然后你打开消息列表页面的时候根据每页显示多少条,根据msg_id去查找内容显示,如果点击了就算已读,更新status
另外补充几点
如果觉得用户消息表还是数据量太大,可以根据不同维度拆分,比如老的消息基本没人看就按时间拆分,如果绝对部分用户不看的就按用户活跃度拆分等等方式
如果读的压力太大,每次读的时候用redis,memcache缓存一下
添加一个消息-用户的表 用户读取消息的页面时,增添相关内容,之后查数据库如果用户有该行则证明已读。
这个是简单实现的逻辑,可以进行一定的优化,降低数据库IO压力和需要排除重复操作的判断
在数据库中加一个status字段表示是否已读,用户读取消息的时候更新一下数据库吧status从0改为1
update A set status = 1 where ID = .