如何在不关闭站点的情况下在数据库中构建缓存的统计信息？答案

【问题标题】：How to build cached stats in database without taking down site?如何在不关闭站点的情况下在数据库中构建缓存的统计信息？
【发布时间】：2025-12-23 18:25:11
【问题描述】：

我正在开发一个 Ruby on Rails 网站。

为了提高性能，我想建立一些各种统计数据的缓存，以便将来显示它们时，我只需要显示缓存而不是拉所有数据库记录来计算这些统计数据。

例子：

一个模型用户有_many 评论。我想将他们有多少 cmets 存储到用户缓存模型中。这样，当我需要显示用户创建的 cmets 数量时，它只是对 stats 模型的简单查询。每次创建或销毁新评论时，它只会增加或减少计数器。

如何在网站上线时构建这些统计信息？我担心的是，在我请求数据库计算用户拥有的评论数量之后，但在它能够执行命令将其保存到统计信息之前，该用户可能会潜入并在某处添加另一条评论。这将增加计数器，但随后立即被另一个线程覆盖，导致保存不正确的统计信息。

我对 ActiveRecord 事务块很熟悉，但据我了解，它们是为了保证所有或没有一个整体成功，而不是充当数据库上数据的互斥保护。

是否有必要关闭网站以进行此类更改？

【问题讨论】：

【解决方案1】：

您的用例已由 rails 处理。它被称为计数器缓存。这里有一个rails：http://railscasts.com/episodes/23-counter-cache-column

由于它太旧了，它可能已经过时了。一般的想法是存在的。

【讨论】：

【解决方案2】：

将应用程序和报告逻辑混合在一起通常不是最佳做法。将您的报告数据发送到应用程序外部，或者发送到另一个数据库，发送到由守护进程读取的日志文件，或者发送到其他一些处理存储细节的 API。

如果这一切听起来工作量太大，那么您并不真正想要实时报告。假设您有某种备份（热备份或冷备份），运行聚合并生成备份报告。这样它就不会影响正在运行的应用程序，并且您的数据不应超过 24 小时。

【讨论】：

您能详细解释一下您对此的看法吗？主要的缺点是什么？您认为集成应用程序和报告逻辑有多糟糕？这个关于如何实现成就的问题有一个高度评价的答案，似乎完全混合了应用程序和报告逻辑，这也是我计划如何实现的，观察者在每次保存后增加数据。 *.com/questions/885277/…

【解决方案3】：

仅供参考，我想我在这里找到了解决方案：

我正在寻找的是所谓的悲观锁定，并在 2.10.2 中得到解决。

【讨论】：