这里需要牢记的一点是，“聊天”实现通常会将实际内容广播给订阅者。
在 Discourse 中，我们拥有一套相当复杂的处理流程，这使得简单的实现变得复杂，从而导致大量的流量。
- 用户发布回复
- 所有正在查看该主题的用户通过广播发现有新内容
- 所有用户向服务器请求帖子内容（100 名观众 = 100 次请求）
- 我们拉取图片并优化图片
- 所有正在查看该主题的用户再次通过广播发现有新内容
- 所有用户再次向服务器请求帖子内容（100 名观众 = 100 次请求）
（我们实施了各种优化、速率限制、重试机制等，但大体流程如此）
所有这些请求都必须经过我们的安全管道，以确保用户有权查看该帖子等。
如果内容较短，且我们能以某种方式找到一种更轻量级的安全验证方法来处理“快速通道”，那么我们就可以通过广播分发聊天消息。这将带来显著的性能提升，采用这种设计，我们或许能在单台低配 2GB DigitalOcean Droplet 上支持 10000 名用户。
安全机制非常复杂。缓存也同样复杂，因为存在缓存失效问题。
因此，是的，我们绝对正在思考这个问题。但就目前而言……
同一主题下大量已登录的观众 + 同一主题下大量新内容 = 昂贵的服务器账单。