Signalr SQL 横向扩展：使用多个流的缺点？答案

【问题标题】：Signalr SQL scaleout : drawbacks of using multiple streams?Signalr SQL 横向扩展：使用多个流的缺点？
【发布时间】：2016-08-13 07:30:09
【问题描述】：

在SignalR Performance页面，我们可以阅读：

此上下文中的 Stream 是横向扩展使用的缩放单位提供者；如果使用 SQL Server，这是一个表，如果是服务，则是一个主题使用总线，如果使用 Redis，则使用订阅。每个流确保有序的读写操作； 单一流是一种潜力规模瓶颈，因此可以增加流的数量来帮助减少这个瓶颈。如果使用多个流，SignalR 将在这些流中自动分发（分片）消息确保从任何给定连接发送的消息都是有序的方式。

流计数（即 SQL 中的表）可以这样设置：

var connectionString = "(your connection string)";
var config = new SqlScaleoutConfiguration(connectionString) { 
    TableCount = 3,
    MaxQueueLength = 50 };
GlobalHost.DependencyResolver.UseSqlServer(config);

但TableCount 在 SQL 横向扩展中默认为 1。如果这是一个规模瓶颈，为什么默认为 1 ？如果我将其设置为 50 会怎样？

文档没有提供任何线索来决定给出哪个值。我应该将其设置为 1、3、10、1000 吗？ 大值的优缺点是什么？它只会增加延迟吗？

【问题讨论】：

标签： c# signalr signalr-backplane

【解决方案1】：

来自文档：

https://msdn.microsoft.com/en-us/library/microsoft.aspnet.signalr.sqlscaleoutconfiguration(v=vs.118).aspx

桌数
获取或设置要存储消息的表的数量。使用更多表可减少锁争用并可能增加吞吐量。这必须在网络场中的所有节点之间保持一致。默认为 1。

【讨论】：