【问题标题】:Building an xmpp server for upstream google gcm为上游 google gcm 构建 xmpp 服务器
【发布时间】:2016-01-18 19:06:22
【问题描述】:

假设有一个应用在给定时间点拥有数以千万计的安装量和数以万计的活跃用户。我需要将用户的活动数据记录到我的服务器。目前,我从设备向我的服务器发出 HTTP 请求。我有一堆运行 Web 服务器的机器,位于亚马逊的 ELB 后面。他们解析来自设备的数据并将其放入 mongodb。

现在,我想通过使用 Google 的 GCM 提供的上游 CCS 来捕获设备数据(这样我就可以搭载 GCM 以更可靠地传递数据)我已经编写了一个原型 XMPP 服务器,我可以让整个事情工作,但我担心扩大规模。如果 Google 开始向我发送消息的速度快于我的消费速度,会发生什么情况?早些时候,我能够在负载均衡器后面使用多个服务器来处理高请求率。这里有负载均衡的概念吗?

如果我打开从我的服务器到 Google 服务器的多个连接(Google 说对于给定的发件人 ID,我最多可以有 1000 个连接),传入的请求是否会在这些连接之间进行负载平衡?

最后,有没有推荐的解决方案可以解决上述大部分问题?使用 ejabberd 会解决上面的一些问题吗?

非常感谢。

【问题讨论】:

    标签: android google-cloud-messaging xmpp ejabberd


    【解决方案1】:

    如果 Google 开始向我发送消息的速度超过我的消费速度会怎样?

    最后https://developers.google.com/cloud-messaging/ccs你可以阅读

    相反,为了避免应用服务器过载,如果未确认的消息过多,CCS 会停止发送。因此,应用服务器应尽快“确认”通过 CCS 从客户端应用程序接收到的上游消息,以保持传入消息的恒定流。上述待处理消息限制不适用于这些 ACK。即使未决消息计数达到 100,应用服务器也应继续为从 CCS 接收到的消息发送 ACK,以避免阻塞新上游消息的传递。

    在同一个文档中,您可以找到第二个和第三个问题的部分答案

    如果在任何时候连接失败,您应该立即重新连接。在身份验证后发生断开连接后无需退出。

    对我来说,这意味着 Google 实现了一个简单的冗余逻辑,并且可能不是一个公平的负载平衡系统(无论如何我希望如此)。如果您的数量如此之多,我建议您直接与他们联系。

    对于最后一个,ejabberd 是一个很好的产品,有很多具有集群基础架构的部署系统和大量关于如何实现的文档。我建议你从这里开始http://docs.ejabberd.im/admin/guide/clustering/

    无论如何,对于您的高容量,我会评估 RabbitMQ,它是 Erlang 的另一颗宝石。

    【讨论】:

      【解决方案2】:

      ejabberd 可以集群并放置在负载平衡器后面以分配连接。一个 3 或 4 个服务器集群应该能够很好地处理该负载并为您提供故障转移保护。如果需要,您可以添加服务器。一旦接近 10 台服务器,您可能需要考虑将 Redis 用于内存数据库而不是 mnesia。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2013-06-26
        • 2016-03-03
        • 1970-01-01
        • 1970-01-01
        • 2015-07-15
        • 2016-03-21
        • 2017-07-22
        • 2013-07-15
        相关资源
        最近更新 更多