使用pub/sub处理大型同时工作负载

我正在处理一个问题，即必须根据事件同时启动大量操作。例如，用户键入目的地和日期，并想要200〃以上的最佳报价；旅行伙伴"；。

为了满足这一点，我正在计划一个事件驱动的体系结构，在用户提供适当的输入后，会向某个主题发布一条消息，该主题的工作人员订阅了该消息，从而生成额外的事件，每个旅行伙伴都可以获得一个活动。

所以本质上：

(1)在提供用户输入后将消息发布到主题"TRAVEL_DESTINATION_REQUEST"
(2) 工作人员订阅了此主题
(3) worker在(2)，对于系统中的每个旅行伙伴，将带有数据{date:..., destination:...,travel_partner_id: ...etc}的事件发布到主题FIND_OFFER
(4) 订阅了CCD_ 4的工作人员查询CCD_

因此，如果您有200个旅行伙伴，上面将向FIND_OFFER主题推送200个事件，供工作人员处理每个用户的查询。

这就是你解决问题的方式吗？如果没有，你会怎么做？顺序显然是不可能的，因为我们不能让用户座位在那里等待，旅行伙伴api调用的响应时间可能不同。。。

在GKE的世界里，pub/sub是这样一种方法的好候选者吗？有人知道pod负载平衡是否会导致该模型出现任何问题吗？

我之所以对此做出回应，是因为在过去的两天里没有人做出回应，而不是因为我是这方面的专家。所以考虑到这一点。。。

一定要牢记用户体验。是否要向用户提供200个结果？我不确定我是否会看到200个结果，即使用户体验非常流畅。

基本上，您需要某种编排来协调步骤2、3&4-不仅发出请求，还处理返回的数据。这种编排的一个关键方面是决定在"；雨天；场景，特别是那些涉及错误或延迟的场景：

如果你能在脑海中(和图表中)描绘出这一点，那么这个思考过程应该会对你有所帮助。

以事件为中心的解决方案&工具应该善于帮助协调结果，例如帮助您决定何时将内容返回到UI。大体上看一下事件/异步设计模式，如果你已经有了特定的技术，看看他们有什么模式/参考思想。

免责声明：我刚刚加入StackOverflow，是EDA领域的先驱Solace的成员；事件启用空间。

这是一个经典的pubsub问题，使用任何JMS Broker或Solace或Kafka Broker都可以很好地解决这个问题，以获得更好的QoS。

几乎不做假设——请求是从UI触发的，期望在合作伙伴收到响应时近乎实时地呈现响应。UI刷新可以由您选择的一个好的前端框架/堆栈单独处理——问题的关键在于如何在后端处理。

事件驱动的设计将非常适合这一需求——流程如下：

将请求消息发布到主题TRAVEL_DESTINATION_request；回复"；设置为队列TRAVEL_DESTINATION_RESPONSE
订阅者(合作伙伴)订阅主题TRAVEL_DESTINATION_REQUEST并将他们的响应发送到"；回复"；目的地
Publisher并行运行一个线程(或回调)，检查TRAVEL_DESTINATION_response队列上响应消息的到达情况，并采取适当的操作(将其推送到客户端、保存在DB中或类似的操作)，确保所有响应都得到处理

几乎任何Broker都可以处理此用例-但是，当您希望同时处理多个此类请求而不混合响应、不扩散主题、队列和使用服务，从而导致资源溢出和管理开销时，就会出现复杂性。

以下是一个使用Solace作为EDA Broker的可能解决方案。Solace的TOPIC方案是独一无二的，非常适合这一要求。主题不仅仅是一个名称，而是一个方案，它可以将动态详细信息编码为主题名称中的级别，这在处理消息时非常有用。解决方案主题是分层的，允许使用通配符根据主题中的不同级别进行筛选。

有了Solace及其分层主题，我们可以如下管理：

最后一步(3)是主题层次结构发挥最大作用的地方。您可以创建到队列RESPONSE_queue的多个同时的客户端连接，并为每个连接创建一个不同的订阅-这就像为每个发布的请求id生成一个消费者服务，然后连接到队列并订阅一个响应主题TRAVEL_DESTINATION_RESPONSE/。

经过一段时间或逻辑条件后，这些使用者服务可以退出，标志着请求处理完成。至于这个服务内部发生了什么，这是业务逻辑——将其持久化到DB中，或者将其推送到前端或其他地方。

希望这能为您的需求提供一种使用Solace作为经纪人的方法。我确信，其他选项是可用和有效的，我只是在分享一种基于Solace Broker的有效方法。

相关内容