2016-05-05 127 views
5

几天前我出现了这个问题。要求是设计一个向用户提供体育内容的移动应用程序(比如足球)。 该应用程序将允许用户订阅特定的团队。 根据用户的团队选择,应用程序仅在用户的主屏幕上提供与该团队相关的内容。 当然,用户可以选择查看所有团队的内容(通过菜单选项)。自动刷新移动应用程序的高效设计

特别关注用户主屏幕上的内容如何自动刷新,并且还应考虑到用户已经(或未订阅)特定团队。

最后一个问题,我建议以下2个解决方案:

1)应用程序可以发送请求的小到只包含用户的标识,用户的球队选择服务器。根据输入请求中的团队选择,服务器将只返回与团队相关的内容。

2)如果内容量较少,且不同的团队数量很少,则广播所有信息并让应用程序进行必要的过滤(当然这与#1相比效率较低)。

在论坛上分享,以获得其他可能的设计决策。如果这不是合适的论坛,请在评论中回答,我将在适当的论坛发帖。

谢谢

回答

4

绝对选项1)。

我们在其他行业开发了类似的用户有兴趣获取有关不同资源状态的信息。架构如下:

  1. 服务器保留所有用户订阅。这就是你让事情这样的:SubscribedUserId事件类型(赢了,损失,numberOfPointsChanged所有,任何情况而定),接口DeliveryChannel(HTTP通知,电子邮件,推手机通知)
  2. 每当有事通过资源,我们将消息放入队列中。邮件包含喜欢的东西:teamEventIsForsubscriberUser接口DeliveryChannel是DeliveryAddress,等...
  3. 独立的Windows服务(S)(一个处理所有deliveryTypes [电子邮件,HTTP,推]或一个每个通道)消耗队列消息并将实际内容传递给用户。在你的情况下,它将通过推送通知。

现在,考虑到推送通知不能保证传递(尽管总体交付速度非常好),但您可能还需要实现某种类型的http资源,其中移动应用程序可以不时地轮询检查是否有某个特定用户的消息(可选)。

+0

感谢您的回复。我会开始赏金,以便我们能够获得更多评论/回复。 – mukeshkumar

4

基本上当你想要做一个自动刷新系统,你只有两个办法:

1:客户端发送请求(S)周期性。这是不够的,如果:

  1. 清爽的间隔不能太短
  2. 您不希望您的应用程序数以百万计的人
  3. 计算结果不会花费太多
运行

这可以通过在数据库服务器端仅使用一些查询来实现。当然,如果你需要更多的性能,你可以有一些中间层。

2:从服务器推的结果:这是一个有点棘手结构正常,但这里是索姆好点:

  • 你只新的数据发送给客户
  • 性能方面它是最好的

然而,限制是比较重要的:

  • 处理失去CONNEXIONS的有点难
  • 您需要捕捉更新数据的每一个事件,以便将刷新推送给客户端。

但因为有比你更需要这个architure解决方案存在:这里是适合最适合你的和javaworld之一:

JMS:Java消息服务,这是一个面向消息的中间件(妈妈)。

JMS是一个具有不同实现的规范,personnaly我会为activeMQ这是Apache的。这里有一个关于这个主题:Which JMS implementation do you use?

如果你不/不能使用JMS然后只记得这个:面向信息的中间件。谷歌应该帮助你找到你需要的东西。

1

您有第三个选项:

3)遵循发布 - 订阅模式。

要实现此目的,您可以使用系统,如Amazon Simple Notification Service (SNS)。首先,您需要设置一个平台应用程序,其中包含您的API密钥(适用于Android)或私钥和APNS证书(适用于iOS)。

当用户第一次启动您的应用程序时,应用程序会要求用户授权推送通知访问,联系您的服务器并发送令牌(用于在SNS平台应用程序上注册端点)。

这使您可以将推送通知发送到在用户设备上运行的应用程序(可以静默处理,或显示为有新数据可用的实时通知)。

然后,您可以为每个团队设置主题,即给定用户可以选择订阅。当用户选择一个团队时,应用程序向您的服务器发送一个请求以订阅该主题,然后您使用他们的API转发给AWS。如果用户想要取消订阅某个主题,则会再次将此请求转发给AWS。

这允许您将每个团队的更新发送到适当的主题,并且只将这些信息分发给实时订阅,可扩展和实时的用户。您的服务器只需要一次ping该主题,AWS将处理交付给每个用户。

当然,您需要实现逻辑来处理通知,订阅,注册等,但它确实允许您的用户实时接收更新。

查看你的选择:

1)最容易实现的,可能必要谁尚未注册新的安装。您将需要这种方式,所以我建议您最初实施此方法。您的服务器将承受与用户成比例的负载,所以当您扩展(并使用HTTP缓存,如清漆或squid以最小化计算和数据库负载)时,值得考虑选项3)

2)没有必要将这些信息广播给您的用户,但它是有效的发布 - 订阅单个主题(所有用户)。只通知关心的用户会更有效率。

3)这是最具可扩展性的选项,并具有实时性的附加优势。即使他们当时没有使用您的应用程序,您也可以通知用户更新。在发布 - 订阅架构下,我们只能通知与您的信息有关的用户,一旦更新,您可以设置超时值,以防止用户从服务器更新到XX时间。这样,如果更新比您的超时值更频繁,用户将永远不需要击中您的服务器。

相关问题