SignalR ScaleOut DependencyResolver UseSqlServer底层工作原理问询

1. SQL背板在SignalR应用中的工作机制（SQL Server内部细节） #

当你在Startup中配置UseSqlServer后，SignalR会自动在指定的SQL数据库中创建3个核心表（若不存在）：

• Messages：存储所有跨节点传递的SignalR消息，核心字段包括Id（自增主键）、Payload（序列化后的SignalR消息内容）、Topic（消息所属主题，如Hub名称、用户组标识）、CreatedAt（消息创建时间）。
• Messages_DeadLetter：存放处理失败的消息（如反序列化错误、重复处理失败），避免这类消息阻塞正常消息队列。
• Topics：记录所有活跃的消息主题，用于优化订阅查询效率。

SQL内部的核心操作围绕这三张表展开：节点发送消息时执行INSERT写入Messages表；节点接收消息时执行SELECT查询未处理的新消息，处理完成后不会删除消息（默认保留，可配置清理策略），而是由每个节点自行跟踪已处理的最大消息ID。

2. 组件背后的架构设计 #

SignalR的ScaleOut能力基于IMessageBus抽象接口，SQL Server背板的核心实现是SqlMessageBus，它依赖两个子组件：

• SqlSender：负责将本地节点产生的SignalR消息（如Hub推送、客户端调用）序列化后写入SQL的Messages表。
• SqlReceiver：负责后台监控Messages表的新消息，拉取后分发给本地节点的SignalR管道，最终推送给连接到当前节点的客户端。

在Startup中调用DependencyResolver.UseSqlServer，本质是将SqlMessageBus注册为IMessageBus的实现，替代默认的本地消息总线，让所有节点共享SQL数据库作为消息中转层。

3. 消息的排队与交换实现 #

• 消息排队：Messages表本身就是一个有序队列，依靠Id自增主键和CreatedAt字段保证消息的处理顺序。当多个节点同时写入消息时，SQL的事务机制会确保消息插入的原子性，不会出现乱序。处理失败的消息会被移入Messages_DeadLetter表，单独留存以便排查。
• 消息交换：
  1. 节点A的客户端触发消息（如调用Hub方法），本地SignalR管道将消息传递给SqlSender；
  2. SqlSender序列化消息并插入Messages表；
  3. 集群中的其他节点（如节点B、C）的SqlReceiver会拉取这条新消息；
  4. 消息被反序列化后，通过本地IMessageBus分发给对应的Hub、用户组或客户端。

4. 消息队列表变化的触发机制 #

SignalR并没有依赖SQL的触发器或事件通知，而是通过定时轮询实现：

• SqlReceiver在节点启动时会启动一个后台任务，默认每隔500ms（可通过配置调整）执行一次查询，检查Messages表中是否存在Id大于当前节点已处理的最大消息ID的记录。
• 一旦查询到新消息，就会拉取这些消息并处理，同时更新本地记录的最大消息ID。
• 这就是为什么只需要在Startup中配置一次，后续无需额外代码——SqlMessageBus初始化时会自动启动轮询任务。

5. 不使用Service Broker的消息传递实现 #

微软文档提到的无Service Broker实现，核心是基于自增ID的轮询机制：

• 每个节点维护自己的LastProcessedMessageId状态（存储在内存或本地配置中）；
• 每次轮询时，执行SELECT * FROM Messages WHERE Id > @LastProcessedMessageId获取新消息；
• 处理完消息后，更新LastProcessedMessageId为本次处理的最大消息ID。
• 这种方式不需要依赖Service Broker的异步通知能力，仅通过普通的SQL查询和定时任务实现跨节点的消息同步，兼容性更强（支持更多SQL Server版本）。

多客户端集群环境下的消息交换示意图 #

┌─────────────────┐        ┌────────────────────────┐        ┌─────────────────┐
│ SignalR节点A    │        │ SQL Server 背板数据库  │        │ SignalR节点B    │
│ ┌─────────────┐ │        │ ┌───────────────────┐  │        │ ┌─────────────┐ │
│ │ 客户端1      │ │───┐   │ │ Messages表        │  │   ┌───│ │ 客户端3      │ │
│ └─────────────┘ │   │   │ │ (存储跨节点消息)   │  │   │   │ └─────────────┘ │
│ ┌─────────────┐ │   │   │ └───────────────────┘  │   │   │ ┌─────────────┐ │
│ │ 客户端2      │ │   │   │ ┌───────────────────┐  │   │   │ │ 客户端4      │ │
│ └─────────────┘ │   └──▶│ │ Messages_DeadLetter│  │◀──┘   │ └─────────────┘ │
└─────────────────┘        │ └───────────────────┘  │        └─────────────────┘
                           │ ┌───────────────────┐  │
                           │ │ Topics表          │  │
                           │ └───────────────────┘  │
                           └────────────────────────┘

• 节点A的客户端发送消息后，消息被写入SQL Messages表；
• 节点B的轮询任务发现新消息，拉取后推送给节点B的客户端；
• 所有节点通过读写共享的SQL表，实现消息的跨节点广播与同步。

内容的提问来源于stack exchange，提问作者mrRobot