用于在发送前收集数据的临时存储答案

【问题标题】：Temporary storage for collecting data prior to sending用于在发送前收集数据的临时存储
【发布时间】：2017-05-05 11:14:13
【问题描述】：

我正在为 PHP 应用程序开发一个作曲家包。目标是在请求、队列作业和采取的其他操作之后发送一些数据。我最初（和工作）的想法是使用register_shutdown_function 来做到这一点。这种方法有几个问题，首先，这增加了页面响应时间，这意味着计算请求的开销以及通过我的 API 发送数据的开销。另一个问题是队列工作者等长时间运行的进程不会长时间执行此方法，因此数据创建时间与发送和处理时间之间可能存在巨大差距。

我的想法是我可以使用某种临时存储来存储数据，并让 cronjob 每分钟发送一次。这种方法我能看到的唯一问题是在高 IO 上管理并发。由于许多进程将每 (n) 毫秒写入文件，因此读取文件和删除已发送的行会出现问题。

我极力避免的另一个选择是使用客户端数据库。这可能会导致性能问题。

最好的方法是什么？

编辑：这个包本质上是一个监控代理。

【问题讨论】：

这就是 RabbitMQ 之类可以相当优雅地解决这个问题的地方。
它没有。这是一个不应依赖于客户端基础设施的作曲家包。
嗯好吧。那么是否要求每个请求都写入同一个文件？如果不是，则每次写入一个唯一文件并使用 cronjob 批量处理这些文件。这应该可以防止并发问题。
是的，我想过，但在高负载系统上，它会生成数千个文件，这似乎是一个非常混乱的解决方案，尽管它可能是一种方法。

标签： php concurrency storage monitoring

【解决方案1】：

这种方法有几个问题，首先，这会增加页面响应时间，这意味着计算请求以及通过我的 API 发送数据会产生开销

我不确定您是否可以解决此问题，在 Web 请求的上下文中执行更多工作会产生额外的开销。我觉得使用基于作业队列的/异步系统可以最大限度地减少客户端的这种情况。无论您选择本地文件系统写入还是套接字写入，您都会有额外的开销，但您可以立即返回客户端，而不会阻塞该请求的处理。

另一个问题是长时间运行的进程，例如队列工作者，不会长时间执行此方法，因此数据创建时间和发送和处理时间之间可能存在巨大差距。

这不是重点吗？ :p 立即返回您的客户，然后在将来的某个时间异步完成工作？使用作业队列可以让您分离和扩展您的工作池和 Web 服务器。您的网络服务器可以非常精简，因为繁重的工作交给了工人。

我的想法是我可以使用某种临时存储来存储数据，并让 cronjob 每分钟发送一次。

我绝对建议查看与滚动自己相反的工作队列。这几乎解决了，有许多非常流行的开源项目来处理这个问题（任何 MQ）分钟的 cron 工作会为客户端进行计算吗？你如何扩展它？如果一个文件有 1000 个条目，或者你缩放 10 倍并有 10000 个条目，你能在一分钟内完成所有这些计算吗？如果服务器死了会发生什么？你如何恢复？进程间并发？您需要管理每个进程的锁吗？你会为每个进程和每分钟使用一个单独的文件吗？存储事件？如果你想跑不到 1 分钟会怎样？

耐用性保证

您为客户提供什么样的保证？如果请求返回，客户端能否确定作业是持久化的，并且会在未来某个时间完成？

我会推荐选择一个工作队列，并让您的网络服务器进程写入它。这是一个非常流行的问题，有这么多关于如何扩展它的资源，并且有明确的持久性和性能保证。

【讨论】：

基本上我的包是一个监控代理。我看不出我的客户会不愿意安装、管理和维护与他们的应用程序无关的 MQ 软件。这是这里的主要问题。感谢您的回答，但它并没有解决我的问题：/
您的客户会注册 cron 并维护/监控它吗？他们是否会负责监控后台作业数量、成功率和资源？有什么方法可以利用已经制作的监控代理？ statsd、collectd、fluentd 等？您询问了首选方式，我强烈建议您利用非常流行的架构，该架构经过充分研究，拥有大量经过实战测试、有据可查的优秀服务，拥有蓬勃发展的社区，而不是本土解决方案
cron 已在客户端应用程序上注册，并作为子进程由内置在我所针对的框架 (laravel) 中的主 CLI 脚本触发。我决定实施 4 个存储引擎供用户选择：内存（通过fastcgi_finish_request 向客户端提供请求后发送数据，如果可用）、数据库、文件和您建议的代理之一。您提到的 3 个中哪一个最适合 JSON 集合？我只是试图避免集成复杂性，即使以性能为代价。我正在构建一个 MVP，所以我需要先测试一下这个想法:)
顺便说一句，谢谢你把我推向正确的方向:)