有puppeteer一个服务器在服务器上执行授权，它作为对服务的方便授权，提供作为多帐户的机会。简而言之，一项服务补充了另一项无法做到这一点的服务。
有一次通过短信验证码确认的授权，手动输入验证码，然后将帐户添加到数据库中，将来允许从不同设备在一个地方登录。
问题是什么：
在填写原始数据时，需要确认进入，通过短信，原始输入包括用用户数据替换服务，这是异步完成的，需要等待短信确认才能进入。
我通过 RabbitMQ 消息代理组织了这个系统。代理接收消息，然后将这些消息发送到服务器，在那里执行它们。
Broker 中的授权系统分为两部分。
获取原始数据（登录名/密码）。
通过短信代码确认登录。
我制作了两个相互独立地接收数据和代码的队列，因此它们被破坏了。
如何组织系统，以便在输入数据并处理它们之后，服务器正在等待代码？
就我自己而言，我看到了两种解决问题的方法：
在数据监听器内部，创建另一个监听器，它将等待代码并检查是否符合当前数据（因为可能有很多代码，它们将在不同的时间交付给不同的用户）。
创建与授权相同级别的侦听器并创建一个变量，我将在其中放置所有传入代码并在时间过去后将它们从变量中删除。我将通过代理查看此变量，如果找到匹配项，则进一步执行我的操作。
这些选项中哪个更正确？
摆脱这种情况的最佳方法是什么？
我只是想等待我的队列的代码应用该操作，但直接在其中执行或在其中执行一次，这就是问题所在。
您正在尝试在 mode 中使用消息队列，
Запрос-Ответ应避免使用此模式。使用这种模式通常会导致解决不应该出现的问题（在消费者中创建消费者）或在您必须创建Саги以正确制定多阶段流程时使系统过于复杂。相反，запрос-ответ最好使用событийную архитектуруwhen 而不是查询类别，您开始考虑事件类别。在您描述的过程中，事件架构可以描述如下：А- 事件被发送到队列ICredentialsReceived。Б接收事件并执行消费——它检查登录密码，保存并发送临时 SMS 代码，并发布事件ISmsCodeSent。А接收到事件并将用户切换到 SMS 代码输入页面。А发送事件ISmsCodeSubmit。Б接收到事件，检查保存的 SMS 代码，如果一切正确，则发送事件ILoginSucceeded。А接收事件并让用户进入系统。在事件范式中，您不必处理您描述的复杂性。但一切都有其代价——在这种模式下，通常会发生通信过程的轻微复杂性（更多阶段、事件、处理程序）。