我应该使用队列系统来处理多租户系统中的 PDF 文本识别吗？

Question

我正在构建一个系统，以允许我们的客户将 PDF 银行对帐单（来自许多不同的银行）转换为更好的 CSV 格式（更好，因为它可以导入到会计应用程序中）。它会在 PDF 页面上查找表格并将其转换为 CSV 文件。

我将使用：

1. 带有 HTML 表单的简单静态网页，用于上传 PDF 并选择要处理的银行。它还将显示作业状态并允许下载转换结果（CSV 文件）。它应该在没有用户身份验证的情况下运行。
2. 在 NodeJS 上运行的后端（稍后会详细介绍）
3. 神剑
4. 傀儡师（操作神剑）

后端必须负责：

1. 从 UI 接收请求（PDF 有效负载）
2. 生成新的作业 ID
   1. 将其发送回 UI
   2. 为 UI 提供 HTTP 资源以询问作业状态
3. 制作 Puppeteer 的新实例，将收到的 PDF 和作业 ID 传递给它
4. 等待 Puppeteer 完成，接收存档文件（Excalibur 将表格的每一页放在单独的 CSV 文件中）
5. 解压存档的 CSV 文件
6. 使用转换器对其进行规范化（使用https://www.npmjs.com/package/mississippi 编写）
7. 向 UI（客户端）发送响应

会出现的问题：

1. 多租户 - 多个用户同时访问系统（我习惯于在一个用户会话的上下文中运行的 PHP，并且我知道 NodeJS 驻留在内存中，将使用 'continuation-local-存储'包）
2. 通信 FEBE，处理大型 PDF 文件（需要大量时间）和向用户提供反馈存在挑战。这就是为什么我需要某种工作 ID 来识别客户。
3. 禁用 Excalibur 数据库 - 我的解决方案不需要保存任何状态。

如您所见，有很多事情要做。我不想讨论决定（例如为什么要使用 Puppeteer 而不是直接访问 Excalibur API）。这是第一个粗略的版本。我有很多想法可以在以后改进这个系统。

我的问题是：我是否应该使用消息队列系统来简化（使其更具可读性）这个系统？该系统如何从使用 AMQP 或 Azure 队列之类的队列或仅将 MongoDB 作为队列中受益？使用消息队列时，这种系统的简单设计（框图）会是什么样子？我以前没有消息队列的经验，我从来没有使用过它们，但我觉得消息队列可以帮助我设计更好的系统结构。

Answer 1

一般来说，排队不是用来简化系统的。最简单的方法是在收到消息时进行翻译，并立即回复结果。队列的主要功能是在数据消费者和数据生产者之间添加一层隔离，支持动态有序的消息积压工作。在以下情况下使用队列很有用：

1. 不需要实时处理传入的消息。
2. 消息生产速率可能会暂时超过消费速率。
3. 消息消费者不依赖于消息生产者。
4. 消息的处理顺序很重要。

鉴于将 PDF 文件转换为 csv 是一项相对昂贵的操作，并且不需要立即完成，因此将传入请求写入队列并使用作业 ID 进行响应是一种合理的方法。

Answer 2

AMQP、SQS 或 Azure 队列在处理大型负载时效果不佳。此外，它们本身并不是工作引擎。 IE。一个作业引擎，您可以查询作业进度、取消作业等。此类队列主要用于在系统中随机播放和缓冲大量较小的消息，或通知系统的其他部分。

因此，也许取决于文本识别作业的计算时间（我不知道），队列可以帮助您缓冲负载，并且如果这对于提供一定程度的“公平性”很重要，那么每个租户可能使用一个工作人员你的租户。 IE。一个租户提交整个库进行扫描，而其他租户必须等待一两个星期才能使用您的系统来获取一行文本。

但是，为了向用户报告状态“作业已完成 10%”等等，您可能可以发送一些 Web 套接字消息，但最终您可能希望将有关每个作业的进度信息存储在如果他们需要超过几秒钟才能完成数据库。