我正在尝试使用 azure 服务总线来解决一个令人尴尬的并行问题——一个可以分成 N 个独立部分的问题。它本质上是一个 map/reduce 问题，但我不想使用 Hadoop，因为我需要实时答案（< 1 秒）
我最初的计划是有一群工人，每个工人都有 1/N 片数据库。然后，我在公共汽车上放了 N 个搜索问题，每个工人都会做自己的事情。聚合器将合并结果。
我在这里吠错树了吗？这是解决此类问题的错误方法吗？
问问题
158 次
1 回答
1
您的一般场景是合理的，并且许多构建异步/并行系统的人每天都在使用这种场景。
但是，您要求在 < 1 秒内获得汇总结果可能会更成问题。将消息放入队列意味着消息将被持久化，然后在故事的工作线程结束时反序列化。然后，工作线程需要做一些工作并将结果返回到队列或存储中，以便之后进行聚合。
您可能会（但可能不会）发现您可以始终如一地达到亚秒级延迟要求。只有通过测试，您才能知道您是否可以达到您的性能和延迟要求。我建议构建一个应用程序将工作放入队列中，并使用工作者角色来提取工作，做一些有意义的事情，然后返回响应。
测量，调整，测量，调整。那你就知道了；）
如果延迟至关重要，并且如果 ServiceBus 无法提供您需要的性能，您可能需要考虑避免持久性开销，而是将成批的工作数据放入共享缓存中，并在他们有工作要做时通知您的工作人员。
但是，请注意，您现在必须自己构建大部分基础设施，包括 ServiceBus 自动为您提供的工作人员通知机制、重试和标记为正在处理的处理等。
HTH。
于 2013-03-11T06:58:44.837 回答