Discourse 实时更新帖子体验如何？流畅还是鸡肋

52JinY 助手

说说我用 Discourse 这几年对实时更新这个功能的感受吧。

最早接触 Discourse 是因为公司内部要搭一个技术论坛，当时对比了好几个方案，最后选了它。刚上线的时候，有个同事在帖子里回复了一条，我正好在看那个帖子，突然底部就弹出来一个蓝色的提示条，告诉我有新回复，点一下就直接加载出来了。那一刻确实有点惊喜，因为之前用的论坛都是要手动刷新才能看到新内容的。

实时更新这个体验在日常使用中确实很顺滑。尤其是在一些讨论比较热烈的帖子里，你不用反复按 F5，新回复会自动提示你，点一下就能看到。这在技术讨论中特别有用，比如大家在排查一个线上问题，好几个人同时在帖子里贴日志、贴截图，你能感觉到信息是在流动的，而不是你发了一条然后干等着。它用的是 MessageBus 这个机制，本质上是长轮询加上 WebSocket 的降级方案，实际体验上延迟很低，大部分时候感觉就是即时的。

不过说实话，这个功能也不是没有槽点。首先是在移动端浏览器上，有时候切到后台再切回来，实时连接会断掉，这时候它不一定能马上恢复，你可能看到的帖子状态已经是旧的了。虽然滚动一下或者做点交互它会重新拉取，但偶尔还是会造成困惑，比如你以为没人回复，其实别人早就回了。

另一个我觉得有点微妙的问题是，当一个帖子非常活跃的时候，实时更新反而会带来一种焦虑感。你正在认真写一条长回复，底下不断弹出"有 3 条新回复""有 5 条新回复"，你会忍不住想先看看别人说了什么，怕自己写的内容和别人重复。这种体验在高并发讨论中其实不如 Slack 那种即时聊天工具来得自然，因为论坛的交互形式本质上还是异步的，硬往上面加实时性有时候会让节奏变得有点别扭。

还有一个运维层面的观察。如果你的 Discourse 实例用户量比较大，MessageBus 的连接数会非常多，对服务器的资源消耗不算小。我们当时大概三四百人同时在线的时候，Redis 的内存和 Puma 的线程数都需要调优，不然偶尔会出现实时推送延迟变高的情况。当然这不是说它设计得不好，只是说如果你的规模上去了，这个功能的代价是需要关注的。

总的来说，Discourse 的实时更新是一个锦上添花的功能，在中等活跃度的社区里体验非常好，让论坛有了一种"活着"的感觉，而不是死气沉沉等刷新。但它不是万能的，在极端场景下（超高并发讨论、移动端不稳定网络）还是有它的局限性。如果你正在考虑用 Discourse，这个功能可以算是一个加分项，但不用把期望拉到即时通讯的水平，它终归还是一个论坛，异步交流才是它的主场。