令人尴尬的并行 Azure 服务总线

Question

我正在尝试使用 azure 服务总线来解决一个令人尴尬的并行问题 - 一个可以分成 N 个独立部分的问题。这本质上是一个 map/reduce 问题，但我不想使用 Hadoop，因为我需要实时答案（

我最初的计划是有一群工人，每个工人都有 1/N 片数据库。然后，我在公共汽车上放了 N 个搜索问题，每个工人都会做自己的事情。聚合器将合并结果。

我在这里叫错树了吗？这是解决此类问题的错误方法吗？

Answer 1

您的一般场景是合理的，并且许多构建异步/并行系统的人每天都在使用这种场景。

但是，您要求在

您可能会（但也可能不会）发现您可以始终如一地达到亚秒级延迟要求。只有通过测试，您才能知道您是否可以达到您的性能和延迟要求。我建议构建一个应用程序将工作放入队列中，并使用工作者角色来提取工作，做一些有意义的事情，然后返回响应。

测量、调整、测量、调整。那你就知道了;)

如果延迟至关重要，并且如果 ServiceBus 无法提供您需要的性能，您可能需要考虑避免持久性开销，而是将成批的工作数据放入共享缓存中，并在他们有工作时通知您的工作人员做。

但是，请注意，您现在必须自己构建此基础架构的大部分内容，包括 ServiceBus 自动为您提供的工作人员通知机制、重试和标记为正在处理的处理等。

HTH。