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