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