我正在寻找SignalR的高频缩放解决方案。我想知道我是否可以使用Azure EventHub。如果我使用EventHub作为SignalR消息的背板，它会成为我的瓶颈吗？
我已经检查了this页面，但没有关于EventHub的内容，因为它很新。
答案 0 :(得分：2)
我无法谈及SignalR的具体细节;但是，原则上你可以使用EventHubs作为背板，但是你需要注意这些限制。
SignalR的背板横向扩展模式假定所有服务器都可以访问所有消息，并假设所有消息都处理完毕。这为单个背板在商用硬件或云端可以执行的操作提供了相当明确的限制。在典型的云中，您可能能够维持100MB / s的数据吞吐量（1 Gb / s nic的良好轮数），商用硬件的上端（以及Azure的HPC机器）1000MB / s（10 Gbit / s nic）。
那么问题是Azure EventHubs可以将您带到吞吐量的这种架构限制吗？
答案就是答案。 100或1000个分区将为您提供足够的写入吞吐量，并为2台服务器提供足够的读取容量。
接下来的问题是，如果每台服务器的背板只需要100MB /秒的读数，那么有多少服务器可以读取数据（例如，如果您正在广播100MB /秒的库存标记，其中数据大小不会增加服务器数量。）
这里的答案是，尽可能多的但是有一些技巧。
EventHubs通过对数据流进行分区来扩展。每个分区的最大读取吞吐量均为2MB / s，并在所有读取器之间共享。但是，您可以将分区数乘以弥补分割（添加超过32需要与Microsoft交谈）。 EventHubs（如Kafka和Kinesis）的设计假设是消费将在机器之间分配，从而避免了前面讨论的背板限制。正在共同阅读流的消费者是消费者群体（Azure似乎甚至需要一个名为CG的直接读者），在这种背板模型中没有逻辑消费者群体，因此问题是如何读取数据。 / p>
最简单的解决方案可能是使用高级自动平衡事件处理器主机，每个服务器都是自己的具有固定名称的消费者组。每个消费者组中只有一个服务器，每个服务器将接收所有分区（10个服务器500个，达到100MB /秒，也就是每月11000美元+ 0.028美元）。
这种方法有一个关键限制：限制为20 consumer groups per event hub。因此，您可以将事件中心链接在一起，或者使用此方法创建一个树来获取任意数字。
另一种选择是使用连接到特定分区的直接客户端。 A single partition in a consumer group can have 5 readers从而减少了将集线器链接5倍的需求，从而将每事件成本降低了5倍（不会降低吞吐量单位要求）。
总之，在任何背板成为瓶颈之前，它不应该成为瓶颈。但是如果你预计它会在流量上超过100MB /秒，那么不要在背板上构建一些东西。
我没有谈论延迟，你需要自己测试一下，但是你可能没有在云端进行HFT，而且实际上游戏通常都是在实例中。