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