Java 多个并发用户订阅数据源的设计和体系结构

下面是一个场景： 我有一个“数据提要”——一个定期更新的REST/JSON服务（比方说，每10秒左右更新一次），如果数据集发生变化，那么所有订阅的侦听器都需要更新

目前它是通过HTTP上的长轮询实现的，这是一个技术问题——但主要的概念是客户端不会打扰服务器，服务器也不会打扰客户端——除非有什么麻烦。 当出现新情况时，会立即通知所有客户。 该技术由Java/Tomcat7、异步IO（异步响应）组成

我认为它工作得很好：我可以以每小时约0.07美元的价格驱动10K并发会话（AWS M3.Medium实例）

（问题-我认为这很有效，但我想听听一些基准数据来验证。或者换句话说-你认为这是一个好消息吗？请分享！！）

如果我的所有客户机都收到相同的数据集（相同的JSON），有没有一种方法可以进行更多的优化

我在考虑IPV6的“多播”——这将使我的带宽消耗减少几个数量级——但这是否可行

例如，为了支持100万并发用户，假设每10秒更新一次，我需要每秒支持10万次“点击”（或响应）。如果响应大小为10K，带宽开始成为一个大问题： 10K*100K*60*60*24-->每24小时86千兆

这里没有一个真正集中的问题（除了IPv6）——我想听听你的想法、经验和其他方法——我讨厌重新发明轮子，我相信这里的集体智慧远远超过我自己的智慧

---

谢谢。

我想建议一些其他可扩展的替代方案，您应该对您的预计负载进行成本估算，以确定哪些是可行的-

假设提要可以在多个客户机之间共享（我不知道这是否与您的应用程序相关），请使用CDN。请参见此处对此类解决方案的描述-

使用专门的消息服务作为主干。在这一领域更突出的是