我应该使用队列系统来处理多租户系统中的 PDF 文本识别吗？
Should I use queue system to handle PDF text recognition in multitenant system?
我正在构建一个系统，允许我们的客户将 PDF 银行报表（来自许多不同的银行）转换为更好的 CSV 格式（更好，因为它可以导入到会计应用程序中）。它将在 PDF 页面上找到 tables 并将它们转换为 CSV 文件。
我要使用：
- 带有 HTML 表单的简单静态网页，用于上传 PDF 并选择要处理的银行。它还将显示作业状态并允许下载转换结果（CSV 文件）。它应该在没有用户身份验证的情况下运行。
- NodeJS 上的后端 运行（稍后会详细介绍）
- 神剑
- 傀儡师（操作 Excalibur）
后端必须负责：
- 正在接收来自 UI 的请求（PDF 负载）
- 生成新的作业 ID
- 发回 UI
- 为 UI 提供 HTTP 资源以询问工作状态
- 创建 Puppeteer 的新实例，将接收到的 PDF 和作业 ID 传递给它
- 等待 Puppeteer 完成，接收存档文件（Excalibur 将 table 的每一页放在单独的 CSV 文件中）
- 解压缩存档的 CSV 文件
- 用转换器规范化（用https://www.npmjs.com/package/mississippi编写）
- 将响应发送到 UI（客户端）
会出现的问题：
- 多租户 - 多个用户同时访问系统（我习惯了 PHP 它在一个用户会话的上下文中运行，我知道 NodeJS 驻留在内存中，将解决它使用 'continuation-local-storage' 包）
- 沟通 FE<->BE，处理大型 PDF 文件（这将花费大量时间）和向用户提供反馈存在挑战。这就是为什么我需要某种工作 ID 来识别客户。
- 禁用 Excalibur 数据库 - 我的解决方案不需要保存任何状态。
如您所见，有很多事情要做。我不想讨论决定（例如，为什么使用 Puppeteer 而不是直接访问 Excalibur API）。这是第一个粗略的版本。我有很多想法可以在以后改进这个系统。
我的问题是：我是否应该使用消息队列系统来简化（使其更具可读性）这个系统？该系统如何从使用诸如 AMQP 或 Azure 队列或简单地 MongoDB 作为队列的队列中获益？使用消息队列时，此类系统的简单设计（框图）看起来如何？我以前没有消息队列的经验，我从未使用过它们，但我觉得消息队列可以帮助我设计这个系统的更好的结构。
一般来说，排队不是用来简化系统的。最简单的方法是在收到消息时进行翻译并立即响应结果。队列的主要功能是在数据消费者和数据生产者之间添加一层隔离，支持消息的动态有序积压工作。在以下情况下使用队列很有用：
- 不需要处理传入的消息real-time。
- 消息生产率可能暂时超过消费率。
- 消息消费者不依赖于消息生产者。
- 消息的处理顺序很重要。
鉴于将 PDF 文件转换为 csv 是一项相对昂贵的操作，并且不需要立即完成，将传入请求写入队列并使用作业 ID 进行响应是一种合理的方法。
AMQP、SQS 或 Azure 队列在处理大负载时效果不佳。此外，它们本身并不是工作引擎。 IE。一个作业引擎，您可以查询作业进度、取消作业等。此类队列主要用于在系统中随机播放和缓冲大量较小的消息，或通知系统的其他部分。
因此，也许取决于文本识别作业的计算时间（我不知道），队列可以帮助您缓冲负载，并且如果这对于提供一定程度的“公平性”很重要，则可能每个租户使用一个工人“在你的租户中。 IE。一个租户提交整个图书馆进行扫描，而其他租户必须等待一两周才能使用您的系统来扫描一行文本。
但是，为了向用户报告状态“工作已完成 10%”等等，您可能可以发送一些网络套接字消息，但最终您可能想要存储有关每项工作进度的信息在数据库中，如果他们需要超过几秒钟才能完成。
我正在构建一个系统，允许我们的客户将 PDF 银行报表（来自许多不同的银行）转换为更好的 CSV 格式（更好，因为它可以导入到会计应用程序中）。它将在 PDF 页面上找到 tables 并将它们转换为 CSV 文件。
我要使用：
- 带有 HTML 表单的简单静态网页，用于上传 PDF 并选择要处理的银行。它还将显示作业状态并允许下载转换结果（CSV 文件）。它应该在没有用户身份验证的情况下运行。
- NodeJS 上的后端 运行（稍后会详细介绍）
- 神剑
- 傀儡师（操作 Excalibur）
后端必须负责：
- 正在接收来自 UI 的请求（PDF 负载）
- 生成新的作业 ID
- 发回 UI
- 为 UI 提供 HTTP 资源以询问工作状态
- 创建 Puppeteer 的新实例，将接收到的 PDF 和作业 ID 传递给它
- 等待 Puppeteer 完成，接收存档文件（Excalibur 将 table 的每一页放在单独的 CSV 文件中）
- 解压缩存档的 CSV 文件
- 用转换器规范化（用https://www.npmjs.com/package/mississippi编写）
- 将响应发送到 UI（客户端）
会出现的问题：
- 多租户 - 多个用户同时访问系统（我习惯了 PHP 它在一个用户会话的上下文中运行，我知道 NodeJS 驻留在内存中，将解决它使用 'continuation-local-storage' 包）
- 沟通 FE<->BE，处理大型 PDF 文件（这将花费大量时间）和向用户提供反馈存在挑战。这就是为什么我需要某种工作 ID 来识别客户。
- 禁用 Excalibur 数据库 - 我的解决方案不需要保存任何状态。
如您所见，有很多事情要做。我不想讨论决定（例如，为什么使用 Puppeteer 而不是直接访问 Excalibur API）。这是第一个粗略的版本。我有很多想法可以在以后改进这个系统。
我的问题是：我是否应该使用消息队列系统来简化（使其更具可读性）这个系统？该系统如何从使用诸如 AMQP 或 Azure 队列或简单地 MongoDB 作为队列的队列中获益？使用消息队列时，此类系统的简单设计（框图）看起来如何？我以前没有消息队列的经验，我从未使用过它们，但我觉得消息队列可以帮助我设计这个系统的更好的结构。
一般来说，排队不是用来简化系统的。最简单的方法是在收到消息时进行翻译并立即响应结果。队列的主要功能是在数据消费者和数据生产者之间添加一层隔离，支持消息的动态有序积压工作。在以下情况下使用队列很有用：
- 不需要处理传入的消息real-time。
- 消息生产率可能暂时超过消费率。
- 消息消费者不依赖于消息生产者。
- 消息的处理顺序很重要。
鉴于将 PDF 文件转换为 csv 是一项相对昂贵的操作，并且不需要立即完成，将传入请求写入队列并使用作业 ID 进行响应是一种合理的方法。
AMQP、SQS 或 Azure 队列在处理大负载时效果不佳。此外，它们本身并不是工作引擎。 IE。一个作业引擎，您可以查询作业进度、取消作业等。此类队列主要用于在系统中随机播放和缓冲大量较小的消息，或通知系统的其他部分。
因此，也许取决于文本识别作业的计算时间（我不知道），队列可以帮助您缓冲负载，并且如果这对于提供一定程度的“公平性”很重要，则可能每个租户使用一个工人“在你的租户中。 IE。一个租户提交整个图书馆进行扫描，而其他租户必须等待一两周才能使用您的系统来扫描一行文本。
但是，为了向用户报告状态“工作已完成 10%”等等，您可能可以发送一些网络套接字消息，但最终您可能想要存储有关每项工作进度的信息在数据库中，如果他们需要超过几秒钟才能完成。