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

Question

我正在尝试使用天蓝色服务总线来解决一个令人难以置信的并行问题 - 可以将其划分为N个独立的部分。它本质上是一个map / reduce问题，但我不想使用Hadoop，因为我需要实时答案（<1秒）

我最初的计划是拥有一堆工人，每个工人都有1 / N的数据库片段。然后，我在公交车上放了N个搜索问题，每个工人都会做。聚合器将结合结果。

我在这里咆哮错误的树吗？这是解决这类问题的错误方法吗？

Answer 1

您的一般情况是合理的，许多构建异步/并行系统的人每天都会使用它。

但是，您要求汇总结果为＆lt; 1s可能更成问题。将消息投入队列意味着消息将被持久化，然后在故事的工作线程末端反序列化。然后，工作线程需要做一些工作并将结果返回到队列或存储中，以便之后进行聚合。

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

测量，调整，测量，调整。然后你会知道;）

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

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

HTH。