我是否将WebSocket用于正确的要求？

实时通知是Websockets蓬勃发展的地方，并提供了超过AJAX的巨大优势。

如您所知，在辩论AJAX的角色（CRUD的伟大之处，在轮询时没有太大的意义）以及比较Websocket性能与AJAX性能（涉及实时更新的Websocket总是更快）之前，已经对此进行了讨论。

还是有其他有效的方式满足我的要求？

是的…您可以通过向on_update数据库访问点添加“挂钩”来节省资源并提高性能（以及将来的代码维护问题）。

这个想法很简单：每当函数调用更新MySQL数据库时，更新请求也会发送到回调。该回调负责将更新发布到正确的频道。

这样，您就不会轮询MySQL数据库。

一些数据库提供更新回调，而另一些则不提供。我认为MySQL确实如此。但是，我避免使用这些数据库链接的回调，因为它们是特定于数据库的。最好（IMHO）将回调添加到应用程序中的数据库访问点，因此替换数据库不会影响代码库。

1. 由于我正在为网站创建Rest Webservices，因此AJAX是实现通知功能而不是WebSockets的更好方法吗？
   

我认为AJAX不是一个好方法。

HTTP / 2有助于缓解AJAX的缺点，但不能解决所有缺点。

我不知道您希望同时连接多少个客户端，但是强迫客户端每隔一两秒发送一次请求就非常接近自我造成的DoS攻击。

考虑一下：如果一个客户端每两秒钟发送一个AJAX请求（而不是2,000个并发客户端），您的服务器将需要响应1,000 req / sec-
这些包括身份验证，数据库查询和所有爵士乐。

另一方面，使用Websockets，在2,000个已连接客户端的情况下，您有2,000个持久连接在消息到达之前不执行任何操作。无需CPU或工作，只需连接的内存。在推送实际数据之前，服务器没有压力。

1. WebSockets的实现是否比击打Rest终结点的AJAX调用复杂（因为两者的目的相同，都是为了获得通知）？
   

是的，它们的实现更加复杂，但是一旦开始，它们并不难。此外，还有许多库和帮助程序工具可以让您省去很多工作。

与Websocket方法相关的常见问题包括水平缩放的处理（通常通过添加发布/订阅数据库或服务，例如Redis），消息排序（在可能的情况下最好忽略）和数据传播问题（何时标记）数据视为“已看到”？我们是发送整个数据还是仅发送一条声明该数据可用的通知？我们使用多少个渠道以及如何划分订阅？）。

通常，答案是特定于应用程序的，并且取决于您尝试展开的功能以及数据集的预期大小（如果我在SO上给出的每个答案都是一个渠道，那么维持它是不现实的）。

无论如何…祝你好运！