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