我的想法是这样的:
如果有给这个用户的新消息,先把具体内容存到数据库,然后把有新消息的通知进入 rabbitmq 队列
如果此时用户websocket在线,直接发送到前端(只是通知前端消息数目+1 ,不发送具体消息内容)
如果用户不在线,就先放在队列里面。用户前端上线后,和后端建立 websocket 连接,然后后端就把队列里面积累的东西发过去
用户点击消息提示之后,再从后端查询数据库,得到所有的新消息的具体内容
这样做有什么问题吗?业界通常的做法是什么?
我的想法是这样的:
如果有给这个用户的新消息,先把具体内容存到数据库,然后把有新消息的通知进入 rabbitmq 队列
如果此时用户websocket在线,直接发送到前端(只是通知前端消息数目+1 ,不发送具体消息内容)
如果用户不在线,就先放在队列里面。用户前端上线后,和后端建立 websocket 连接,然后后端就把队列里面积累的东西发过去
用户点击消息提示之后,再从后端查询数据库,得到所有的新消息的具体内容
这样做有什么问题吗?业界通常的做法是什么?
13 回答12.8k 阅读
8 回答2.6k 阅读
2 回答5.1k 阅读✓ 已解决
9 回答1.7k 阅读✓ 已解决
3 回答2.2k 阅读✓ 已解决
5 回答849 阅读
4 回答1.2k 阅读✓ 已解决
实时性要求多高呢?不是特别高的话long polling甚至定时查都够用,否则ws
场景还需要更具体一些,这种问题需要场景才好确定怎么做
PS:貌似在v2上看到这个问题了