移动应用架构，以提高速度和减少数据传输

Question

问题的

业务上下文

我们的iphone应用程序允许用户向商家付费并赚取报酬。

用户也可以这样做：

1. 查看事务历史
2. 查看他们的观点和可用的奖励，或要求奖励。
3. 通过推荐朋友赚钱，查看转换和未转换推荐的历史。
4. 查看一些商家正在经营的交易(欢乐时光特价等)
5. 查看有关商人的信息(地点、时间等)

由于可用的交易或奖励、事务历史记录和引用在任何时候都可能发生变化，所以我们在用户的设备上有一个经典的缓存失效问题。

电流，不满意溶液

我们当前的体系结构是相当标准的，并且包含诸如"/merchants“、"/rewards”、"/transactions“、"/deals”等API内点。

我们目前通过以下方法解决陈旧的缓存问题：

1. 当应用程序打开时，频繁地轮询服务器(在某些API调用中，每分钟都会轮询)，以及当应用程序恢复焦点时。
2. 用像3分钟前最后一次更新的文本表示可能陈旧的数据

我们使用etags来避免重新发送未修改的数据(例如，整个商家列表)，但是我们目前的方法仍然浪费了大量的带宽。例如，如果一个商人改变了，所有的商人都会感到不满。如果添加了单个新事务，则所有事务都将重新启动。

在实践中，从用户的角度来看，这通常不是什么大问题，因为我们谈论的是1到200 K的最大尺寸，而且通常更少。然而，在手机接收能力差的地区，这可能是一个问题，这种情况经常出现，以至于我们听到投诉。

在服务器端，所有这些轮询都会产生大量不必要的负载，特别是因为即使etags不变，也会发生处理和数据库查询，

更好的解决方案？

我们正在重新设计应用程序和服务器代码，并考虑其他策略。由于这是一个相当常见的问题，我想知道其他人是如何解决的。

我到目前为止有一些想法：

1. 为了最小化数据传输:在服务器上跟踪每个用户实际拥有的数据。只发送已更改数据的JSON斑块，而不发送所有数据的新副本。每个用户数据的副本可以存储在redis中，并在几天或一周后过期。这将保持“活动会话”的快速性，而没有存储服务器缓存的用户在休眠期后登录时，只需发送所有数据的新副本(与现在一样)。虽然从理论上讲这是可行的，但通过对两者进行修补，保持服务器和客户端副本的同步似乎是潜在错误的丰富来源，即使我使用的是经过审查的JSON修补程序库。
2. 为了最小化服务器负载:与每个客户端建立web套接字连接，而不是轮询。让改变客户状态的事件(例如，购买、推荐转换、交易结束等)按压websocket消息，从而触发客户端刷新。这可以与idea 1一起使用，也可以与当前发送所有更改数据的新副本的方法一起使用。即使采用了当前的方法，这仍然是一个巨大的改进，因为只有在需要的时候才会请求和发送数据。

现在，我倾向于2而不是1，因为1似乎充满了问题。我对在手机上依赖websockets有一些担忧，但在这里、在SO和其他地方做了研究之后，这种担心似乎是不成立的。

我很想听听其他可能完全不同的解决这些问题的建议。

Answer 1

因为它是一个本地应用程序，如果你愿意的话，你可以完全避开HTTP。

您可以使用HTTP/2.0，它允许流。流是线头阻塞(HOL)阻塞的部分解决方案，允许多个请求共享单个TCP连接，并以增量和一致的方式交付。它还允许一些服务器发起的通信.它仍然是TCP，所以它不是HOL阻塞的完整解决方案。

您可以使用WebRTC，它使用DTLS来完全避免HOL阻塞，并有效地启用服务器或对等事件。

对于这种用例，我倾向于避免HTTP，因为它给应用程序数据请求流设置了人为的和毫无同情心的约束。这在浏览器中是必需的，但在应用程序中则不然。HTTP的优势是为所有基于broswer、桌面和移动应用程序的客户端提供单一的服务界面，尽管如此，我们可以放心地接受它。

您可以在端口443上使用基于TLS的AMQP (类似于RabbitMQ)，并通过其消息队列进行基于事件的通信。后端服务会将更新推到队列中，或者中间更新程序服务将调用REST服务并更新它们。在TCP级别，这仍然会受到HOL阻塞的影响。

另一种选择是ZeroMQ和CurveZMQ。这也是一种面向消息的解决方案，但您不需要像AMQP这样的独立的中央代理。您的应用程序可以通过消息直接与您的服务器对话。您的服务器可以执行REST轮询和状态管理，并尽可能频繁或不频繁地将更新推送到客户端。这允许在失败情况下优雅地退化。这是最灵活的，也可以说是最精简的选项，但是TCP也是如此，所以不能完全避免HOL阻塞。

值得的是，HOL阻塞不太可能接近您当前的问题，解决它需要重大的妥协。