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

Question

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

我将使用：

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

后端必须负责：

1. 接收来自UI的请求(PDF有效载荷(
2. 生成新作业id
   1. 将其发送回UI
   2. 为UI提供HTTP资源以询问作业状态
3. 制作Puppeter的新实例，将收到的PDF和作业id传递给它
4. 等待Puppeteer完成，接收存档文件(Excalibur将表格的每一页放在一个单独的CSV文件中(
5. 解压缩存档的CSV文件
6. 用transformer将其规范化(用https://www.npmjs.com/package/mississippi)
7. 将响应发送到UI(客户端(

将出现的问题：

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

正如你所看到的，有很多事情要做。我不想讨论决定(例如为什么Puppeteer和不直接访问Excalibur API(。这是第一个粗糙的版本。我以后有很多改进这个系统的想法。

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

Answer 1

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

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

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

Answer 2

AMQP、SQS或Azure队列在大型有效载荷下并不能很好地工作。此外，它们本身并不是一个就业引擎。例如，一个作业引擎，你可以查询作业进度、取消作业等。这样的队列主要用于在系统中打乱和缓冲许多较小的消息，或者通知系统的其他部分。

因此，也许取决于文本识别作业的计算时间(我不知道(，队列将帮助您缓冲负载，并且如果这对于提供一定量的"；公平；在你的租户中。也就是说，一个租户提交了整个图书馆进行扫描，其他租户必须等待一两周才能使用您的系统来扫描一行文本。

但是为了向用户报告状态；工作完成10%"；等等，你可能会发送一些websocket消息，但最终你可能会想把每个作业的进度信息存储在数据库中，如果它们需要几秒钟以上的时间才能完成。