# 极端负载错误

**URL:** <https://meta.discourse.org/t/extreme-load-error/180311>\
**Category:** Self-hosting\
**Created:** [2021年二月19日 06:16 UTC](https://meta.discourse.org/t/extreme-load-error/180311 "2021-02-19T06:16:09Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![sam](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/sam/32/102149_2.png) [@sam](https://meta.discourse.org/u/sam)\
**Post date:** [2021年二月21日 23:17 UTC](https://meta.discourse.org/t/extreme-load-error/180311/9 "2021-02-21T23:17:47Z")

</div>

这里需要牢记的一点是，“聊天”实现通常会将实际内容广播给订阅者。

在 Discourse 中，我们拥有一套相当复杂的处理流程，这使得简单的实现变得复杂，从而导致大量的流量。

1. 用户发布回复
2. 所有正在查看该主题的用户通过广播发现有新内容
3. 所有用户向服务器请求帖子内容（100 名观众 = 100 次请求）
4. 我们拉取图片并优化图片
5. 所有正在查看该主题的用户再次通过广播发现有新内容
6. 所有用户再次向服务器请求帖子内容（100 名观众 = 100 次请求）

（我们实施了各种优化、速率限制、重试机制等，但大体流程如此）

所有这些请求都必须经过我们的安全管道，以确保用户有权查看该帖子等。

如果内容较短，且我们能以某种方式找到一种更轻量级的安全验证方法来处理“快速通道”，那么我们就可以通过广播分发聊天消息。这将带来显著的性能提升，采用这种设计，我们或许能在单台低配 2GB DigitalOcean Droplet 上支持 10000 名用户。

安全机制非常复杂。缓存也同样复杂，因为存在缓存失效问题。

因此，是的，我们绝对正在思考这个问题。但就目前而言……

同一主题下大量已登录的观众 + 同一主题下大量新内容 = 昂贵的服务器账单。

---

_[View the full topic](https://meta.discourse.org/t/extreme-load-error/180311)._