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

Question

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

我将使用：

1. 简单静态网页与HTML表单，以上传PDF和选择银行处理。它还将显示作业状态并允许下载转换结果(CSV文件)。它应该在不运行用户authentication.
2. Backend的情况下在NodeJS上运行(更多关于那个later)
3. Excalibur
4. Puppeteer (要操作)

)。

后端必须负责：

从UI接收请求(PDF payload)

• Generate新作业id

1. ，将其发送回UI
2. )为UI提供HTTP资源以请求作业status

files

• Normalize

1. 创建新的
   1. 实例，传递给它接收到的PDF和工作id
   2. 等待Puppeteer完成，接收归档文件(
      1. 将表的每一页放在一个单独的CSV文件中)
      2. 用变压器解压缩存档的CSV它(用https://www.npmjs.com/package/mississippi)
      3. Send响应UI (客户端)

      编写)

将要发生的问题：

1. Multi-tenancy --多个用户将同时访问系统(我习惯于在一个用户会话的上下文中运行NodeJS，并且我知道NodeJS驻留在内存中，将通过‘延续-本地存储’package)
2. Communication FE<->BE来解决它，在处理大型PDF文件(将花费大量时间)并向用户提供反馈方面有一个挑战。这就是为什么我需要某种工作id来识别clients.
3. Disabling的

数据库--我的解决方案不需要保存任何状态.

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

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

Answer 1

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

real-time.

• Message producers.

• Processing传入的消息不需要处理，产生率可能暂时超过消费速率。

1. 消息使用者不依赖消息的顺序。

非常重要。

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

Answer 2

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

因此，可能取决于文本识别作业的计算时间(我不知道)，队列将帮助您缓冲负载，如果这对于在租户之间提供一定量的“公平”非常重要，则可能会为每个租户使用一个工人。也就是说，一个租户提交一个完整的库进行扫描，而其他租户则需要等待一两个星期才能将您的系统用于一行文本。

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