规则一:如果您正在收集要在崩溃和重新启动时保留的数据,请不要将其存储在内存中。尽可能快地将它从您的代码中取出并放到磁盘上或更持久的地方。
将数据存储在数据库中。它不必花哨,它可以是一个简单的磁盘上的 SQLite 数据库。
我强烈建议您研究Sequel ORM gem,它可以轻松处理大量 DBM。
以下是开始使用基于磁盘的 SQLite 数据库的容易程度:
require 'sequel'
DB = Sequel.connect('sqlite://temps.db')
如果您有权访问另一个 DBM,请使用它。Sequel 使事情变得简单,只需从代码中获取数据并存储即可。
就我个人而言,我有两个表和应用程序,一个用于捕获数据并将其写入原始数据表的守护程序,另一个用于读取原始数据、对其进行汇总并将其写入汇总表。第二个应用程序将定期启动,可能作为一项 cron 作业,汇总自上次汇总以来收到的所有数据,然后退出。
两个表都有时间戳字段,因此很容易检查新数据。
你可以弄清楚其余的。
您可以考虑使用 RabbitMQ 之类的东西作为后端,并从捕获节点向其发送消息,并让另一个节点读取消息。我认为这基本上是一个简单问题的过度设计,但这将是另一种确保数据不会在重新启动后丢失并提供使用数据库的替代方法,但没有以数据库为中心的任何优势设计。
关于即时启动新代码:
这是可能的,但我仍然会使用两个或更多应用程序与上面提到的数据库通信,以划分捕获和分析功能。这样,您就可以在不同的地方运行多个捕获应用程序,而不会让它们踩到另一个的汇总活动。一个应用程序将负责汇总数据,无论是一百万个还是一百万个捕获应用程序。这样,您可以取下一端或另一端,整个应用程序仍然可以运行。
使用Signal.trap
您可以设置中断处理程序,例如 HUP,并通过exec
. 我将从以下内容开始:
Signal.trap('HUP') { exec($0, ARGV) }
如果您想合并您的 Rails 应用程序,请通过 Rails 应用程序使用的支持数据库来完成。将捕获和分析所需的表添加到该数据库,将几个模型添加到 Rails 应用程序,以及相关的表单/报告/页面,并让您的守护程序和摘要代码将这些表写入他们的核心内容。