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

时间:2014-06-30 08:16:52

标签: java performance optimization architecture multicast

这是一个场景: 我有一个'数据馈送' - 一个定期更新的REST / JSON服务(假设 - 每10秒左右),如果数据集发生了变化 - 那么所有订阅的监听器都需要更新。

目前使用HTTP进行长轮询实现,这是一个技术性 - 但主要的概念是客户端不打扰服务器,服务器不会打扰客户端 - 除非有什么值得烦恼的。 当 新的时候,所有客户都会立即收到通知。 该技术由Java / Tomcat7,异步IO(asyncResponse)组成。

我认为它很有效:我可以每小时约0.07美元驱动10K并发会话(AWS M3.Medium实例)。

(问题 - 我认为它很有效,但我希望听到一些基准数据来验证。或者换句话说 - 你认为它是一个很好的降价吗?请分享!!)

如果我的所有客户都收到相同的数据集(相同的JSON),有没有办法可以进一步优化?

我正在考虑IP V6'多播' - 这会将我的带宽消耗降低几个数量级 - 但这是否实用?

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

这里没有一个重点突出的问题(除了IPv6) - 我想听听你的想法,经验和其他方法 - 我讨厌重新发明轮子,我敢肯定集体智慧在那里远远超过我自己。

感谢。

1 个答案:

答案 0 :(得分:0)

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

  1. 假设可以在多个客户端共享源(我不知道这是否与您的应用程序相关) - 使用CDN。请在此处查看此类解决方案的说明 - http://tech.ftbpro.com/post/78969626647/growing-x20-without-spending-an-extra-penny-on-hosting

  2. 使用专门的消息服务作为主干。该领域中比较突出的是PubNub