24

我使用 ASP.NET MVC 和 C#。我发现 SignalR 用于实时传输数据,但 signalR 有一些限制。

根据这个问题

使用背板,最大消息吞吐量低于客户端直接与单个服务器节点对话时的最大消息吞吐量。那是因为背板将每条消息转发到每个节点,因此背板可能成为瓶颈。此限制是否存在问题取决于应用程序。例如,以下是一些典型的 SignalR 场景:

  • 服务器广播(例如股票行情):背板在这种情况下工作得很好,因为服务器控制发送消息的速率。
  • 客户端到客户端(例如,聊天):在这种情况下,如果消息数量随客户端数量增加,那么背板可能会成为瓶颈;也就是说,如果消息的速率随着更多客户端的加入而按比例增长。
  • 高频实时(例如实时游戏):不建议在这种情况下使用背板。

我的项目需要高频实时(例如实时游戏)。

我也需要实时视频聊天

我的场景:

我有一个主服务器和多个从服务器,客户端连接到从服务器,从服务器连接到主服务器。

示例:服务器 Slave-1 和服务器 Slave-2 连接到主服务器,客户端 A 和客户端 B 连接到 Slave-1,客户端 C 和客户端 D 连接到 Slave-2,

客户端-A 发送消息或数据或与客户端-D 进行实时聊天

我怎样才能实现这个场景?

[更新-1]

如果我不使用 signalR 解决该问题,那么我应该使用什么?

[更新-2]

在我的场景中,主服务器就像一个路由器,从服务器就像一个交换机。客户端连接到交换机,交换机连接到路由器。如果客户端-A向客户端-C发送数据包,数据包应该被发送到路由器并且路由器处理数据包。超过2000个可能的从服务器数量和每个服务器的用户数量超过10,000。

谢谢。

4

1 回答 1

28

背板会在消息传递中引入延迟,这对于低延迟工作来说效果不佳。如果您绝对必须有多个服务器来处理您的客户端,并且您绝对必须具有最小的延迟,那么背板可能不适合您。

但是,请查看ASP 论坛上的此对话。发布者看到一台服务器上3,000 个连接的客户端每秒发送 60,000 条消息的平均延迟约为 25 毫秒。

通常情况下,这里的权衡是在延迟和复杂性之间。最佳解决方案是将消息仅路由到包含目标客户端的服务器。为了实现这一点,您需要一种方法来跟踪每个客户端连接,处理与不同服务器的重新连接等。您可能可以通过数十小时的艰苦编程来解决这个问题,但这样做会破坏大部分是什么让 SignalR 有用。

对于替代方案,首先想到的是ZeroMQ。更多的工作,特别是如果您的客户端是基于浏览器的,但低延迟和高吞吐量是 ZeroMQ 的项目目标。不过,您需要自己处理横向扩展......并且您将返回跟踪跨多个服务器的连接点并重新连接。

如果这些都不能解决你的问题,那么你可能不得不考虑改变你的架构。MMO 的一种常见方法是让相关客户端连接到相同的服务器,以减少服务器间的通信需求。合法需要传输实时数据的客户端被放在一个服务器上,无需担心背板问题。然后,该服务器仅将维持世界状态所需的内容与“主”服务器通信,依此类推。

计划您的架构以在问题开始之前减少它们……但不要花费数周时间来处理可能没有必要的事情。在深入深渊之前,对 SignalR 进行一些测试,看看背板对延迟的实际影响。

于 2013-11-05T23:12:57.317 回答