PHP中的编码理论：需要为多个队列引导流量（多路复用）

Posted 2023-02-16

【中文标题】PHP中的编码理论：需要为多个队列引导流量（多路复用）

【英文标题】：Coding Theory in PHP: Need to direct traffic for multiple queues (multiplexing)

【发布时间】：2012-07-23 07:41:25

【问题描述】：

我正在为我们的员工提供一个界面，用于上传他们需要行业统计数据的产品列表（目前一次手动完成）。 然后，每个产品都将通过网络服务 api 提供给我们的统计引擎。 我会回复的。 Stat 引擎将从我的 api 请求“下一个受害者”。

用户上传的每个列表将包含 50 到 1000 个产品，并且将是自己的队列。 目前，队列/列表可能会每天添加（并通过完成删除）大约 10-20 次。 如果成功，几个月后流量可能会上升到每天 700-900 个列表。

我们只是计划采用简单的循环方法来均匀地引导队列中的流量。 多路复用器会从 List A 中获取顶部项目，然后是 List B，然后是 List C 等等，直到循环回到 再次列出 A ...请记住，可以随时添加/删除列表/队列。

我面临的问题只是将其管理概念化。 我考虑将每个队列存储为一个平面文件并通过关系数据库（mysql）管理轮换。想过反过来做。考虑过使用完全平面文件或完全关系数据库...底线，我很灵活。 无论如何，当我试图无状态地将可变的参与者列表与循环旋转融合在一起时，我的大脑只是蒸汽锁定（我刚从一个短暂的假期回来，我认为我的大脑还没有回家；）

有人做过这样的事吗？ 你是怎么处理的？ 如果必须再做一次，你会改进什么？

欢迎任何和所有提示/建议/建议。

注意：由于来自我们统计引​​擎/工具的每个请求都将相隔很多秒，如果不是几分钟的话，我需要保持这个无状态。

【问题讨论】：

添加信息：1) 当来自特定队列/列表的最后一项被发布到统计引擎时，我们的通知器将被触发，通知用户他们可以查看他们的结果（不需要状态检查..耶！！）。 2) Stat 的引擎采用单个产品，运行 stat 并将它们加载到我们的缓存池中。

【参考方案1】：

列表数据当然应该存储在数据库中。你的 php 端应该有一个显示系统状态的视图，以及添加列表的表单。

由于每个请求都成为自己的队列，并且所有请求队列的优先级都被认为是相同的，因此理想的表数可能是三个。一个列出请求及其相对于另一个的优先级（以确定谁在循环中下一个）和处理状态，另一个列出内容（列表项）尚未处理的每个请求的列表，以及第三个表格，用于列出每个队列中已处理的项目。

您还需要一个执行实际处理的脚本，该脚本不是由用户请求驱动，而是由系统调度的定期执行的作业驱动（根据您的需要调节）。这当然也可以在 PHP 中。您可以在此处设置一次 10 次列表检查和更新。

处理过程如下：

从最高优先级队列中选择下一组最多 10 个项目。 处理它们，在它们完成时更新它们的数据库状态。 更新上述队列的优先级，使其现在是最低优先级。

如果添加新队列，它们将以最低优先级添加。

优先级可以用整数表示。

您的用户需要耐心等待他们的列表得到处理，然后查看或下载结果。您可以在视图页面上为此设置一个自动刷新脚本。

【讨论】：

谢谢一堆 .. 很多组件 R 已经完成了。我面临的障碍只是下一个项目的优先级（不幸的是，一次有 2 B 1）。据我了解你的建议（因为它适用于我的界限），这个想法只是有一个优先级的 tbl .. 我喜欢它 .. 又好又简单 :)。我主要关心的是在处理记录时更新该表 EACH 中 ALL 记录的优先级值。如果我每次都必须为 900 条记录这样做，那不是对资源造成不必要的负担吗？？

为了澄清，使用这种 Priorities Tbl 方法，我将优先考虑队列/列表..然后，一旦我的多路复用器知道接下来要命中哪个列表，它将从该列表/队列中检索下一个项目。

我认为选择 MIN() 优先级同样有效，然后使用 MIN() - 1 更新最高优先级行

【参考方案2】：

听起来您正在尝试实现 Gearman 已经做得很好的东西。对于每个上传/请求，您可以简单地将作业发送到 Gearman 服务器以进行排队。

Gearman 可以配置为持久化（以防万一），这样您就无需在关系数据库中记录请求了。

然后，您可以启动任意数量的工人。我知道您建议串行运行所有作业，您仍然可以这样做，但您也可以并行化工作，这样您的用户就不会像所有作业都以串行方式处理时那样久坐时尚。

【参考方案3】：

睡了一夜好觉后，我现在对自己有了智慧（我希望 :)。 一个简单的解决方案是优先级的平面文件。 有一个文本文件，每行只有一个列表/队列 ID。 馈送 来自 列表的一端，并添加 到 另一端...简单。

欢迎批评;o)

感谢@Trylobot 和@Chris_Henry 的反馈。