SignalR通过Azure EventHub扩展

我正在寻找SignalR的高频缩放解决方案。 我想知道我是否可以使用Azure EventHub。 如果我使用EventHub作为SignalR消息的背板,它会成为我的瓶颈吗?

我已经检查了这个页面但是没有关于EventHub的内容,因为它是相当新的。

我无法谈及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的直接读者),在这种背板模型中没有逻辑消费者群体,所以问题是如何读取数据。

最简单的解决方案可能是使用高级自动平衡事件处理器主机,每个服务器都是自己的具有固定名称的消费者组。 每个消费者组中只有一个服务器,每个服务器将接收所有分区(10个服务器500个,达到100MB /秒,即每月11美元,每百万个事件0.028美元)。

此方法有一个关键限制: 每个事件中心限制为20个使用者组 。 因此,您可以将事件中心链接在一起,或者使用此方法创建树以获取任意数字。

另一种选择是使用连接到特定分区的直接客户端。 消费者组中的单个分区可以具有5个读取器,从而将链接集线器的需求减少了5倍,从而将每事件成本降低了5倍(不会降低吞吐量单位要求)。

总之,在任何背板成为瓶颈之前,它不应该成为一个瓶颈。 但是,如果您希望它在流量上超过100MB /秒,那么不要在背板上构建一些东西。

我没有谈到延迟,你需要自己测试一下,但是你可能没有在云中进行HFT,而且实际上游戏通常都是在实例中。

Interesting Posts