【问题标题】:How to solve limitations of SignalR in scaleout for backplane如何解决 SignalR 在背板横向扩展中的限制
【发布时间】:2013-11-16 22:08:26
【问题描述】:

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

according to the issue for this

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

  • 服务器广播(例如,股票行情):背板适用于此 场景,因为服务器控制消息的速率 已发送。
  • 客户端到客户端(例如聊天):在这种情况下,背板可能 如果消息的数量与 客户;也就是说,如果消息的速率按比例增长 更多客户加入。
  • 高频实时(例如,实时游戏):背板不是 推荐用于这种情况。

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

我还需要实时视频聊天

我的场景:

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

示例: 服务器 Slave-1 和服务器 Slave-2 连接到 Master 服务器,client-A 和 client-B 连接到 Slave-1,client-C 和 client-D 连接到 Slave-2,

client-A 发送消息或数据或与 client-D 实时聊天

我如何实现这个场景?

[Update-1]

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

[Update-2]

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

谢谢。

【问题讨论】:

  • 不要使用 signalR 解决这个问题?
  • 那我应该用什么?
  • 嗨,阿米尔,我正在研究如何做到这一点。你愿意通过 github 分享任何示例代码吗?

标签: c# asp.net .net real-time signalr


【解决方案1】:

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

不过,请在 ASP 论坛上查看 this conversation。发帖者看到 一台服务器上上 3,000 个连接的客户端每秒 60,000 条消息的平均延迟约为 25 毫秒。

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

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

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

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

【讨论】:

    猜你喜欢
    • 2015-12-14
    • 1970-01-01
    • 2017-06-19
    • 2023-04-10
    • 2018-03-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多