ajax - 通知系统——Socket.io 还是 Ajax？

Question

我正在使用 Laravel5，我想为我的(网络)项目创建一个通知系统。我想要做的是，通知用户新的通知，例如；

• 另一个用户开始关注他，
• 另一位用户在他的墙上写下，
• 另一个用户给他发消息等，

(可能通过下拉菜单突出显示标题上的图标。例如 StackOverflow)。

我在 Laracast 上找到了新教程:Real-time Laravel with Socket.io，其中使用 Node、Redis 和 Socket.io 实现了类似的事情。

如果我选择使用 socket.io 并且我有 5000 个在线用户，我假设我将必须建立 5000 个连接，5000 个广播加上通知，所以它会发出大量请求。我需要在主 Blade 上为每个登录的用户启动，是这样吗？

这样做不好吗？我还认为使用 Ajax 请求也可以实现相同的目的。我应该避免使用过多的连续 ajax 请求吗？

我想问一下，Socket.io 是否是创建此类系统的良好逻辑方式，或者它是在 5 秒内使用 Ajax 请求的更好方法？或者还有其他更好的方法吗？ Pusher 可以作为替代方案，但我认为免费是更好的替代方案。

Answer 1

一些想法:

1. Websockets 和 Socket.io 是两个不同的东西。

   Socket.io 可能会使用 Websockets，它可能会退回到 AJAX(在不同的选项中)。

2. Websockets 对网络更友好且资源效率更高，但就编码和设置而言，它们需要工作。

   出于多种原因，将 SSL 与 Websockets 一起用于生产也非常重要，并且某些浏览器要求 SSL 证书有效...因此可能需要付出代价。

3. 即使浏览器支持，Websockets 有时也无法连接(这是推荐使用 SSL 的原因之一)...替换 AJAX 代码。

4. 5 秒 5000 个用户是每秒 1000 个新连接和请求。某些应用每秒无法处理 1000 个请求。情况并非总是如此，但这是一个很常见的问题。

   您拥有的用户越多，您的 AJAX 就越像 DoS 攻击。

   另一方面，Websockets 是持久的，没有新的连接——这是一个很大的资源问题——尤其是考虑到 TCP/IP 的慢启动功能(是的，这是一个功能，而不是错误)。

   即使新客户端被拒绝，现有客户端也不应该遇到 DoS(服务器设计可能会影响此问题)。

5. Heroku dyno 应该能够处理 5000 个 Websocket 连接，并且仍有空间处理更多连接，同时仍能响应常规 HTTP 请求。

   另一方面，我认为 Heroku 强加了每秒事件请求和/或每个 dyno 的积压限制(每个约 50 个请求)。这意味着如果超过一定数量的请求正在等待第一个响应或您的应用程序接受连接，新请求将被自动拒绝....因此您必须确保您的新请求不超过 100 个一个时间。对于每秒 1000 个请求，您需要并发性以每个请求 10 毫秒的速度允许 100 个并发请求作为最低性能状态……这在您的本地计算机上可能很容易，但是当网络延迟开始时，它很难实现。

   这意味着在使用 AJAX 时，运行在一个 Heroku Dyno 上的 Websocket 应用程序很可能需要多个 Dynos。

这些只是您在选择方法时可能考虑的事情的想法，无论您使用什么 gem 或框架来实现您的方法。

外包您的应用程序的某些部分，例如推送通知，需要考虑其他因素，例如可伸缩性管理(您节省了哪些资源？)与价格等'