我有一个将安装在 40,000 个桌面上的浏览器插件。
此插件将连接到通过 https 可用的后端配置文件，例如http://somesite/config_file.js.
插件配置为每天轮询此后端资源一次。 但是只有一个后端服务器。因此，如果 40,000 个端点开始一起轮询，服务器可能会崩溃。 我可以考虑从桌面插件中随机化轮询频率。但是随机化仍然不能保证服务器不会出现过载。
在这种情况下使用 websocket 是否解决了可扩展性问题？
【问题讨论】：
标签： performance concurrency websocket
每天轮询一次很少。
除非您切换到 Push 并获得更多通知，否则我认为 Websockets 没有任何优势。
但是，错开轮询确实很有意义，因为同时同步请求就像编写针对您自己的服务器的 DoS 攻击。
交错不一定是随机的，恕我直言，它可能不应该。
您可以从固定时间开始，然后为每个客户端 ID 添加一秒，从而在 24 小时内允许约 86K 连接，这对于任何服务器来说都应该很容易处理。
附带说明一下，40K 并发连接可能没有您想象的那么难。
EDIT（与 cmets 有关）
Websockets 与服务器发送事件：
恕我直言，在推送数据（相对于轮询）时，我更喜欢 Websockets 而不是服务器发送事件 (SSE)。
Websockets 有一些优点，例如客户端通信，它允许客户端ping 服务器并确认连接仍然存在。
具体用例：
从问题中的描述和 cmets 看来，您正在使用带有自定义插件的浏览器客户端，并且您希望每天安装的更新可能需要浏览器处于活动状态。
这引发了影响实施的不同问题（客户端浏览器是否全天打开？您是否可以控制客户端浏览器及其环境？您能保证在浏览器关闭时安装吗？）。
...
恕我直言，您可以考虑让客户端插件在每天早上首次加载时测试更新（首次访问）。
人们上班的时间不同，他们第一次打开浏览器的时间也不同。因此，您预期的 40K 请求将自然地分散在该时间线上（可能是 20-30 分钟的时间跨度）。
这种方法确保浏览器和计算机实际上是打开的（使更新成为可能），并且更新请求在一段时间内交错（如果我的假设是正确的，大约每秒 33.3 个请求）。
如果您提供预先编写的静态配置文件（可能每天由服务器更新），避免动态内容并最大限度地减少任何数据库调用，那么 33 req/sec 应该很容易管理。
【讨论】：