Ruby on Rails 每秒处理大量请求和数据库更新的性能答案

【问题标题】：Ruby on Rails performance on lots of requests and DB updates per secondRuby on Rails 每秒处理大量请求和数据库更新的性能
【发布时间】：2014-10-08 23:51:28
【问题描述】：

我正在开发一个投票应用程序，它将平均每秒处理来自不同用户的 1000-2000 票。换句话说，它将每秒接收 1k 到 2k 个请求，每个请求都会将数据库插入到存储投票数据的表中。

我正在使用带有 MySQL 的 RoR 4，并计划将其推送到 Heroku 或 AWS。

我应该注意哪些与数据库和应用程序本身相关的性能问题？

如何解决每秒插入数据库的这种数量的问题？

编辑

我在考虑不要为每个请求插入数据库，而是将插入数据写入内存流。因此，我将每秒运行一个预定作业，该作业将从该内存流中读取并生成批量插入，从而避免每次插入都以原子方式进行。但我想不出一个很好的方式来实现这一点。

【问题讨论】：

您可以将请求发送到后台作业，因此只要能够写入数据库，它就会写入。这样，您就可以立即重定向用户/更新页面；感谢他们投票。您可以使用缓存将投票内容保存到内存中，这样就不必为每个尝试投票的人访问数据库。
@kobaltz 如果我将插入发送到后台队列，您不认为这会产生内存问题吗？因为我每秒要排队 1k-2k 插入。
@kobaltz 另外，缓存投票内容是什么意思？缓存投票数据和部分结果，以便我可以将其展示给尝试投票的人？
假设投票数多于投票数，您可以使用缓存将投票查询存储到内存中，以便下一个点击该投票的用户不必从数据库中获取信息，而是从内存中获取信息.

标签： ruby-on-rails performance heroku amazon-web-services

【解决方案1】：

虽然您当然可以在 AWS 中做您需要做的事情，但高水平的 I/O 可能会让您付出代价。 RDS 最高可支持 30,000 IOPS；如果您想自己运行数据库，还可以使用不同配置的多个 EBS 卷来支持高 IO。

根据您计划的使用模式，我可能会考虑推入内存数据存储，例如 memcached 或 redis，然后从那里处理请求。您还可以查看 DynamoDB，这可能取决于您的数据结构。

您是要始终保持这种水平的持续吞吐量，还是会爆发式增长？您是否必须保留每一张选票，还是只需要汇总数据？您需要扩展多少 - 即您会达到每秒 20,000 票吗？ 20万？

这些类型的问题将有助于确定合适的架构。

【讨论】：

通过推送到内存数据存储，是否可以使用 Redis 到后台队列？您不认为这可能会导致内存问题吗？
在这样的吞吐量下每天都会出现峰值。您所说的汇总数据是什么意思，而不是保留每张选票？
@Izolem：如果您只需要计数，您可以将每个投票推送到 redis - 大概投票不是大量数据 - 然后让后台进程处理来自 redis 的数据并更新摘要，因此您无需保存每个单独的选票。 Redis 处理 2k 次内存插入可能比 2k 次数据库插入便宜。