如何合理的设置notification请求？

Question

关于网站从后端获取新的notification(通知），我在想可以有以下几种业务逻辑：

1. 如果实时性非常高，类似于Bilibili那种，肯定要firebase那种实时数据库+钩子
2. 如果实时性不高，可以每次页面跳转的时候，请求一下 GET /notification来获取
3. 或者可以在 src/index.js开启一个计时器，然后每多少分钟请求一次。

假如我现在做一个后台管理系统，我选用那种方式获取notification比较好？或者有没有更好的选择？选项#2 是不是有点给服务器增加压力了？ 选项#3是不是给浏览器增加压力了？有没有更好的做法，感谢

Answer 1

选项#2与选项#3最简单, 如果notification只是一个模块的一个很次要的功能, 并且要求频率不高确实可以用, 相对而言需要notification选项#3好一些, 也要不了多少性能

实时性要求很高就用websocket , 思否用的就是这个:

Answer 2

1. 首先要用 service worker，因为 sw 会在 tab 间共享，所以一个浏览器只会启动一个，可以避免多开 tab 对服务器造成压力，也方便多 tab 间同步数据。
2. 其次要看需求。绝大多数通知并没有很大的时效要求，比如思否，早几分钟晚几分钟没什么关系，所以几分钟轮询就足够了。
3. 跳转时拉取的问题在于，可能影响不相关的逻辑，所以不推荐。

Answer 3

@陟上晴明 谢邀，建议是如果消息后续会持续进行扩展的话，直接用 websocket 来做处理就行，实际上 websocket 并没有多复杂。我可以大概说一下实现方案：

1. 后端不管用啥，弄个常驻进程的程序就行，用于与 websocket 通信，个人推荐 JS 或者是 golang。
2. 做一个类似于进程池的东西，放在内存中，然后可以定时检查没有用户进行websocket连接了进行释放，这里算是程序优化相关的，请自行考虑，不做细说。
3. 用户登录后，首次会统计用户历史未读消息数并返回给浏览器进行展示；
4. 后续进行消息主动推送，如果产生新的消息，同时可以用 redis 的 pub-sub 进行消息推送，后端的这个消息系统收到这个推送后重新统计指定用户的消息数并通过 websocket 返回给前端就行。平时没有收到需要推送动作不做处理，也消耗不了多少性能。

差不多就是这么个流程，一般一两百行代码就可以搞定，只不过思路相对比较复杂。

Answer 4

其实可以考虑一下思否的消息推送模式哇，这个时候就得邀请官方了 😝😝😝

我的话会选择第二种和第三种方式，管理后台的消息推送并不需要“那么及时”，保证在工作的钉钉或者微信有即时推送就好。用 websocket 个人感觉成本有点太高了，又不是做一个在线IM。

另外就是定时器只要做好销毁，并不会给浏览器压力。倒是每次跳转的时候请求消息接口获取新消息。用户一直刷新可能多出来很多无效请求。

Answer 5

我觉得需要根据具体的使用场景来判断：

如果只是某些页面需要长链接，那么轮询的方式可能是最方便的。参考 gitlab ci，会每5秒请求一次结果

如果是全局的通知管理，那么不推荐使用轮询。

如果是交互很强的双向通信：推荐使用 WebSocket
如果只需要知道服务端有更新，推荐使用 SSE（Server-Sent Events）这个相对于 WebSocket 更加轻量。

Answer 6

如果你的后台管理系统对实时性要求非常高，类似于Bilibili那样，可以考虑使用实时数据库和钩子（如Firebase）来实现通知推送。

如果实时性要求不高，可以在每次页面跳转时请求 GET /notification 来获取通知。

另外，你还可以在前端代码中设置一个定时器，每隔一段时间请求一次通知。这种方式需要权衡定时请求的频率和服务器负载。

还可以考虑使用长轮询、WebSocket或消息队列来实现实时通知推送。

最佳选择可能因具体情况而异，需要根据实际情况进行评估和测试。