问自动刷新移动应用程序的高效设计

EN

基本上，当你想做一个自动刷新系统时，你只有两种方法：

1:客户端定期发送请求。在以下情况下，这就足够了：

1. 刷新间隔不是太短
2. 你不能期望你的应用程序运行数百万次

结果不会花费太多

这可以通过在数据库服务器端天真地使用一些查询来实现。当然，如果您需要更高的性能，您可以使用一些中间层。

2:从服务器推送结果:这对于适当的架构来说有点棘手，但这里有一些优点：

wise是最好的clients

• Performance ，您只需将新数据发送到

然而，限制更重要：

• 处理丢失的连接有点困难
• 您需要捕获更新数据的每个事件，以便将刷新推送到客户端。

但是因为有比您更多的需求，所以这个架构解决方案存在:这里是Javaworld中最适合您的：

JMS : Java消息服务，是一种面向消息的中间件(MOM)。

JMS是一种具有不同实现的规范，我个人倾向于activeMQ，它是Apache规范。这里有一个关于这方面的主题：Which JMS implementation do you use?

如果您不/不能使用JMS，那么只需记住这一点：Messare-Oriented-Middleware.谷歌应该可以帮助你找到你需要的东西。

当然是选项1)。

我们在其他行业开发了类似的东西，在这些行业中，用户有兴趣获得关于不同资源状态的信息。架构是这样的：

1. 服务器保留所有用户的订阅。这就是你保存东西的地方：SubscribedUserId，EventType (赢，输，numberOfPointsChanged，所有，不管是什么情况)，deliveryChannel (http通知，电子邮件，mobiles)
2. Whenever的推送通知)资源发生了一些事情，我们将消息放在一个队列中。消息包含如下内容：teamEventIsFor，subscriberUser，deliveryChannel，deliveryAddress，etc...
3. Separate窗口服务(一个或多个处理所有deliveryTypes电子邮件、http、推送或每个通道一个)消费队列消息并将实际内容传递给用户。在您的情况下，它将通过推送notifications.

现在，考虑到推送通知不能保证投递(尽管总体投递率相当不错)，您可能还想实现某种http资源，移动应用程序可以不时轮询以检查是否有针对特定用户的新闻(这是可选的)。

你还有第三个选择：

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

要实现这一点，您可以使用诸如Amazon Simple Notification Service (SNS)之类的系统。首先，您需要设置一个包含API (适用于Android)或私钥和APNS证书(适用于iOS)的平台应用程序。

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

这使您能够向用户设备上运行的应用程序发送推送通知(可以静默处理，也可以显示为有新数据可用的实时通知)。

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

这使您可以将每个团队的更新发送到适当的主题，并将此信息仅分发给订阅、可伸缩和实时的用户。您的服务器只需ping该主题一次，AWS将处理对每个用户的交付。

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

查看您的选项：

1)最容易实现，对于尚未注册的新安装可能也是必要的。无论采用哪种方式，您都将需要此方法，因此我建议您首先实现此方法。然而，您的服务器将承受与用户成比例的负载，因此当您进行扩展(并使用HTTP缓存，如varnish或squid以最小化计算和数据库负载)时，值得考虑选项3)。

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

3)这是最具伸缩性的选项，并且具有实时的附加优势。您将能够通知用户更新，即使他们当时没有使用您的应用程序。在发布-订阅架构下，您将能够仅通知与您的信息相关的用户，并且一旦更新，您可以设置一个超时值，以防止用户在XX时间之前从您的服务器进行更新。这样，如果更新比超时值更频繁，用户将永远不需要访问您的服务器。