减少柜台维护的请求数量答案

【问题标题】：Reduce requests number on counters maintainment减少柜台维护的请求数量
【发布时间】：2016-02-25 15:49:42
【问题描述】：

假设我有一个 Parse 模型 Book，它有一个属性 pagesViewCount，还有一个 Parse 模型 Page，它有属性 book 和 viewCount。

由于 Parse 不支持聚合 (SUM)，所以当我的客户看到一个页面时，我必须递增这两个值以保持它们同步。

现在，我调用云函数 markAsRead，它接收 pageObjectId 作为参数，然后从那里获取页面，然后调用：

page.increment('viewCount');
page.get("book").increment("pagesViewCount")
Parse.Object.saveAll([page, page.get("book")])

这很好用，除了这涉及到多个请求，并且由于 Parse 只允许 30req/sec 的突发限制，我想如果没有这么多用户，这可能是一个大问题。

有没有其他选择？

PS ：我想我可以调用page.save() 而不是 saveAll page & book 因为递归性，但这将是相同数量的请求，因为可读性较低，对吧？

编辑：Page 和 Book 对象只是示例，我的对象更复杂，子对象不是有限的，所以我不能将它们的 viewCount 与主对象一起存储在数组中

【问题讨论】：

【解决方案1】：

为了减少请求的数量，您可以将计数器存储在本地，然后在每次应用关闭时调用一个函数。此函数聚合所有页面的计数器。

我还会考虑您是否可以重新考虑您的数据模型，以便可能不为书中的每一页存储完整的对象？ Book、Page和当前用户有什么关系？

一种可能的解决方案是在Book（如果这是特定于当前用户）中有一个名为pagesRead 的字段，这可以是一个数组。每次用户阅读页面时，您将页码添加到此数组中。然后读取的页数等于该数组的大小。页面是否被读取只是一个问题

pagesRead.contains(pageNo)

根据您的需求和用例，可能还有其他类似的解决方案可能不包含 Page 对象。

【讨论】：

Page 和 Book 对象只是该用例的示例。在我的真实案例中，将 read 的单个值存储在数组中并不是一个好的选择，因为子对象没有有限的数量，因此可能会过多地增加容器对象的大小。但是你答案的第一部分很有趣
我明白了。书柜通常包含几百件物品，很少超过 1000 件。这不是问题。如果可能有成千上万个对象，那么这可能不是正确的解决方案。但是，如果您需要更新所有用户的数百个页面，您仍然会遇到困难。我仍然相信可能会有数据模型解决方案，具体取决于您的用例。
也就是说；用户会在每个页面上花费一些时间，因此您需要相当数量的用户才能每秒更新 30 多个页面。到那时，也许您的应用程序已经足够流行以至于您可以负担得起付费计划？或者重新设计您的数据模型？我现在可能会尝试重新设计您的数据模型，但请注意不要针对您在很长一段时间内不太可能获得的数据量过早地优化您的应用程序。
在我的例子中，一页是一种媒体，一本书是一个群体。用户可以将媒体发布到群组，并且有群组看到的媒体总数和媒体的总浏览量的计数器。确实目前这不是问题，但到时候我想不出任何方法来绕过它
目前重新设计数据模型可能还可以，但我认为没有更好的方法来表示这种关系

【解决方案2】：

不幸的是，目前批处理操作中的每个操作都被计为单个 API 请求 (source)，这意味着如果您想同时保存 30 个对象，您可能会达到免费计划的限制。您需要记住，请求/秒限制是按每分钟计算的。来自Parse FAQ：

请求限制是按每个应用的每分钟计算的。例如，如果一个应用程序设置为 30 个请求/秒，您的应用程序将命中一旦特定应用程序发送超过 1800 个请求，它的请求限制超过 60 秒的时间

避免请求/秒限制的解决方案是将您的操作分散到多个 API 请求中。例如，在您的 Cloud 代码中使用 Promise 链在较长时间内以多个步骤执行保存/更新操作，以确保您不会达到免费计划的上限。

【讨论】：