【发布时间】：2014-07-06 23:10:36
【问题描述】：
这是一个场景： 我有一个“数据源”——一个定期更新的 REST/JSON 服务（比如说——每 10 秒左右），如果数据集发生变化——那么所有订阅的侦听器都需要更新。
目前它是使用基于 HTTP 的长轮询实现的，这是一种技术性 - 但主要概念是客户端不会打扰服务器，服务器也不会打扰客户端 - 除非有什么需要打扰的事情。 当有新的东西时，所有客户都会立即得到通知。 该技术由Java/Tomcat7、异步IO（asyncResponse）组成。
我认为它很有效：我可以以每小时 0.07 美元左右的价格驱动 10K 并发会话（AWS M3.Medium 实例）。
（问题 - 我认为它效果很好，但我想听一些基准数据来验证。或者换句话说 - 你认为这是一个很好的收益吗？请分享！！）
如果我的所有客户都收到相同的数据集（相同的 JSON），有没有办法可以进一步优化？
我正在考虑 IP V6“多播”——这会将我的带宽消耗减少几个数量级——但这是否可行？
例如，为了支持 100 万并发用户，假设每 10 秒有一次更新，我需要支持每秒 10 万次“点击”（或响应）。如果响应大小为 10K，则带宽在这里开始成为一个大问题： 10K * 100K * 60 * 60 * 24 --> 每 24 小时 86 Giga。
这里没有真正的单一、集中的问题（除了 IPv6） - 我想听听您的想法、经验和替代方法 - 我讨厌重新发明轮子，我相信集体智慧远超我自己的。
谢谢。
【问题讨论】：
标签： java performance optimization architecture multicast