使用传统的帖子，Ajax帖子或渠道API为我自己的Like按钮？

Question

我正在开发一款每天有4000万用户的移动应用。

该应用程序将向用户显示他们可以选择阅读的文章，没有图像，只有纯文本。用户可以拉动刷新以获取新文章。

我想为每篇文章实现类似的按钮（我自己喜欢按钮而不是Facebook）。假设每个客户每天每人点击100次，它将等于40M x 100 = 4000 M的数据传输时间。

我以前没有大项目经验的新手。什么是适合我的项目的最佳方法。我发现每个频道创建的Google Channel API为0.0001美元，即每天80M x 0.0001 = 8000美元（假设每人有2个连接），这非常昂贵。或者还有其他方法可以做到这一点？恩。 Ajax或传统帖子。我的应用程序不需要实时。哪一个资源消耗较少？有人可以指导我。我真的需要帮助。

我打算在这个项目中使用谷歌应用引擎。

Answer 1

效率的微小差异将成为这些数量的运营成本的重大变化。我不会盲目相信文件所提出的理论主张。构建和测试每个替代设计并确保它与其他软件兼容是明智的。对数千名模拟用户进行的几天试验将以可承受的成本产生有价值的结果。

渠道，Ajax和传统的网络请求在您的问题的概念层面都是可行的。添加一些监控代码并比较不同规模级别的负载测试结果。除性能和成本外，仪表代码还应监控可靠性。

Answer 2

我非常怀疑你的应用程序每天会有4000万用户，并且更加怀疑每个用户每天会点击10次。

但我不明白为什么点击Like会导致大量的数据传输。这是一个简单的Ajax请求，除了空响应之外甚至不需要返回任何内容，成功的代码为200，失败的代码为400。

Answer 3

我会首先尝试小规模的不同选项，以获取一些数据，您可以从中推断出来计算成本。但是，使用轻量级处理程序的简单ajax请求可能比Channel API便宜。

如果你每天获得4000万用户，阅读至少100篇文章，然后赚100个喜欢，我猜你每天会有超过80亿的请求。在此基础上，即使考虑使用类似按钮，您的实例成本也可能很高。在这一系列的请求中，您在服务器端处理请求的方式对于管理成本非常重要。

使用AppStats，Chrome Dev Tools和Apache Jmeter等工具可以帮助您更好地了解响应时间，实例和实施情况。扩展前的带宽成本和用户体验。