服务器几乎立即通知特定浏览器
server notify specific browser almost immediately
我正在构建一个系统，其中有 2 个组，我们称它们为用户和消费者。任何用户都可以向任何消费者发送消息。他们如何做到这一点并不重要，但发生的事情是消息被放置在服务器上的数据库中，并且每当发生这种情况时，都应向感兴趣的特定消费者（由用户确定）发送通知。
那么假设我们有100个消费者，那么大概会有1000个用户。每当用户向 him/her 发送消息时，消费者需要几乎立即（最多 5 秒）得到通知。
消费者界面是一个标准的 angular 网站，我正在使用 tomcat 来托管它，但这并不重要，如果需要可以切换到 Node 或类似的方式。
现在我想弄清楚的是通知消费者消息已到达的最佳方式。
我考虑的是 websockets、SSE、长轮询和普通拉式方案，每 5 秒发出一个 ajax 请求。我认为所有的选择都是可行的，但还有一些进一步的挑战：
- consumers are logged in (ideally in one session) around 18 hours a day.
- Hardware is limited (Can't afford that much that's why I'm trying to optimize :) )
- consumers probably only get new message(s) every 10 minutes or so but when they do they NEED to get the message(s) almost instantly (<5 seconds)
据我所知，这存在安全问题（我猜一天 18 小时在浏览器中登录同一个会话可能会有问题??
关于硬件，我唯一认为的是，如果您有 100 个消费者，那么每 5 秒为每个消费者向服务器发送一个 ajax 请求很快就会变得（不必要地）昂贵上面的例子。
我不知道让 websockets 运行这么长时间有多昂贵，如果在收到响应之前发出一个长轮询请求然后再发出一个新请求是否可能更便宜？？
最后我不太明白SSE是如何工作的。从服务器到客户端的连接是否打开？如果是，SSE 和长轮询之间有什么区别？？
任何意见、想法、建议？？
此外，任何关于硬件 capacity/usage 客户端-服务器交互的文章、博客文章、书籍等的链接都将非常受欢迎，因为我想自己阅读，但很难找到关于这些的良好硬件信息东西.
如果需要任何详细说明，请直接询问:)
对于延迟应小于 5 秒但可能每 10 分钟才收到新消息的情况：
- websockets、sse和long-poll基本相同，并且都是零延迟
- ajax 轮询更糟糕。
前三个保持一个专用套接字打开，但只有连接一次的开销（长轮询有每10分钟连接一次的开销，但这永远不会成为系统瓶颈），而ajax 轮询的开销是每 N 秒建立一个新连接，平均延迟 N/2 秒。
websockets 和 long-poll 的缺点是它们保持套接字打开。我在那里没有看到安全问题，但您确实有潜在的性能问题，因为每个套接字都将使用服务器上的资源。但是有 100 个用户，我认为一个普通的云服务器实例就可以应付。
将 SSE 看作是专门为您的用例设计的简化 websockets，或者是长轮询的标准化版本，它还可以在您获取数据时保存重新连接。提示：SSE 是您应该追求的技术，但有一个警告。插件：我的书，Data Push Apps with HTML5 SSE，更详细地回答了你的问题;-)
需要注意的是 IE 仍然 不支持它。我的书讨论了处理旧版浏览器的问题（这很容易，特别是如果您提前计划的话）。
在您的情况下，由于您只希望每 10 分钟收到一次新数据，因此您可以对所有浏览器进行长轮询：这与 SSE 之间的区别在于微优化。
作为关于这个主题的另一本书推荐，Ilya Grigorik 的高性能浏览器网络非常好。
看看 Crossbar.io (http://crossbar.io). This includes Publish & Subscribe message routing (which is what you need for your use case). There's a connector for AngularJS in the browser, and you have a large choice of languages for your backend component (for both see http://wamp.ws/implementations)。
这适用于非常有限的资源 - 我们已经管理了您在 Raspberry Pi 上描述的消息量。长-运行 连接同样不是问题，通知消费者的时间主要由网络延迟决定（低于 5 秒）。
完全披露：我在 Tavendo 工作，他们是上述项目的维护者。不过，它们都是开源的，并且适合您的用例。
我正在构建一个系统，其中有 2 个组，我们称它们为用户和消费者。任何用户都可以向任何消费者发送消息。他们如何做到这一点并不重要，但发生的事情是消息被放置在服务器上的数据库中，并且每当发生这种情况时，都应向感兴趣的特定消费者（由用户确定）发送通知。
那么假设我们有100个消费者，那么大概会有1000个用户。每当用户向 him/her 发送消息时，消费者需要几乎立即（最多 5 秒）得到通知。 消费者界面是一个标准的 angular 网站，我正在使用 tomcat 来托管它，但这并不重要，如果需要可以切换到 Node 或类似的方式。
现在我想弄清楚的是通知消费者消息已到达的最佳方式。 我考虑的是 websockets、SSE、长轮询和普通拉式方案，每 5 秒发出一个 ajax 请求。我认为所有的选择都是可行的，但还有一些进一步的挑战：
- consumers are logged in (ideally in one session) around 18 hours a day.
- Hardware is limited (Can't afford that much that's why I'm trying to optimize :) )
- consumers probably only get new message(s) every 10 minutes or so but when they do they NEED to get the message(s) almost instantly (<5 seconds)
据我所知，这存在安全问题（我猜一天 18 小时在浏览器中登录同一个会话可能会有问题??
关于硬件，我唯一认为的是，如果您有 100 个消费者，那么每 5 秒为每个消费者向服务器发送一个 ajax 请求很快就会变得（不必要地）昂贵上面的例子。
我不知道让 websockets 运行这么长时间有多昂贵，如果在收到响应之前发出一个长轮询请求然后再发出一个新请求是否可能更便宜？？
最后我不太明白SSE是如何工作的。从服务器到客户端的连接是否打开？如果是，SSE 和长轮询之间有什么区别？？
任何意见、想法、建议？？ 此外，任何关于硬件 capacity/usage 客户端-服务器交互的文章、博客文章、书籍等的链接都将非常受欢迎，因为我想自己阅读，但很难找到关于这些的良好硬件信息东西.
如果需要任何详细说明，请直接询问:)
对于延迟应小于 5 秒但可能每 10 分钟才收到新消息的情况：
- websockets、sse和long-poll基本相同，并且都是零延迟
- ajax 轮询更糟糕。
前三个保持一个专用套接字打开，但只有连接一次的开销（长轮询有每10分钟连接一次的开销，但这永远不会成为系统瓶颈），而ajax 轮询的开销是每 N 秒建立一个新连接，平均延迟 N/2 秒。
websockets 和 long-poll 的缺点是它们保持套接字打开。我在那里没有看到安全问题，但您确实有潜在的性能问题，因为每个套接字都将使用服务器上的资源。但是有 100 个用户，我认为一个普通的云服务器实例就可以应付。
将 SSE 看作是专门为您的用例设计的简化 websockets，或者是长轮询的标准化版本，它还可以在您获取数据时保存重新连接。提示：SSE 是您应该追求的技术，但有一个警告。插件：我的书，Data Push Apps with HTML5 SSE，更详细地回答了你的问题;-)
需要注意的是 IE 仍然 不支持它。我的书讨论了处理旧版浏览器的问题（这很容易，特别是如果您提前计划的话）。
在您的情况下，由于您只希望每 10 分钟收到一次新数据，因此您可以对所有浏览器进行长轮询：这与 SSE 之间的区别在于微优化。
作为关于这个主题的另一本书推荐，Ilya Grigorik 的高性能浏览器网络非常好。
看看 Crossbar.io (http://crossbar.io). This includes Publish & Subscribe message routing (which is what you need for your use case). There's a connector for AngularJS in the browser, and you have a large choice of languages for your backend component (for both see http://wamp.ws/implementations)。 这适用于非常有限的资源 - 我们已经管理了您在 Raspberry Pi 上描述的消息量。长-运行 连接同样不是问题，通知消费者的时间主要由网络延迟决定（低于 5 秒）。
完全披露：我在 Tavendo 工作，他们是上述项目的维护者。不过，它们都是开源的，并且适合您的用例。