在Pub-Sub架构中发送响应

Question

目前，我有一个AWS EC2实例，可处理所有传入的http客户端请求。它分析每个请求，然后决定哪个后端工作服务器应该处理请求，然后对所选服务器进行http调用。然后，后端服务器在处理请求时进行响应。然后，前端服务器将响应客户端。前端服务器实际上是负载均衡器。

我现在想要使用Pub-Sub架构而不是前端服务器将请求推送到后端实例。前端服务器将执行一些基本处理，然后简单地将请求放入SNS队列，后端服务器应该处理请求的逻辑留给后端服务器本身。

我的问题是这个模型让后端服务器通知前端服务器他们处理了请求的最佳方法是什么？以前他们刚刚回复了前端服务器发送的http请求，但现在没有直接请求，只有一个工作项被发布到队列，后端实例将其从队列中删除。

Answer 1

Pubsub架构不太适合回复/确认。他们的“即发即忘”广播模式将发布者和订阅者分离：发布者不知道是否有多少订阅者，订阅者不知道哪个发布者生成了消息。此外，由于网络通信的性质和消息的处理可能需要不同的时间等，因此很难保证响应的顺序，它们不一定与消息序列匹配。因此每个消息需要确认需要订阅者可以在其响应中包含的唯一ID，以便发布者可以将响应与发送的消息进行匹配。例如：

1. 发布者发送消息“新事件”并为其提供UUID 事件
2. 许多订阅者收到消息;有些可能是处理程序 请求，但其他人可能是观察员，记录器，分析等
3. 如果只有一个订户处理该消息（例如第一个） 订户从某处获得密钥），该订户生成一个 消息“处理新事件”并提供UUID
4. 原作 发布者以及任何其他订阅者都可以获得 信息;
5. 原始发布商看到的ID是 在其缓存中作为未经证实的消息，现在将其标记为 确认
6. 如果在没有收到的情况下经过了一定的时间 具有给定ID的确认，原始出版商重新发布 原始邮件，带有新ID，并从缓存中删除旧ID。

在步骤3中，如果许多订阅者处理的是消息而不是一个消息，那么它就是 不太明显原始出版商应如何处理“回应”：它是如何处理的 知道有多少订阅者处理消息，有些订阅者可能会失败或 太忙无法回应，或者有些人可能正在按时回应 原始出版商确定“没有足够的处理程序 回答”。

发布 - 订阅体系结构应设计为不请求任何响应，而是检查由于正在处理的命令而应该发生的某些情况，例如生成的缩略图（它可以假设为结果）消息的处理程序）。