多数情况下,客户端和服务端的关系就像一对朋友,通过请求–响应方式你来我往,客户端无论是刷新页面还是发送请求,服务端有求必应。SignalR让客户端和服务端之间建立了全双工通讯,两者又似乎成了家人,你中有我我中有你,客户端可以调用服务端的方法,反之亦然。于是我们在股票金融、物联网设备、多人协作等需要实时显示数据的场景中看到了SignalR的身影。
本周,在"青岛微软技术交流"群里,Darren提出了一个SinglaR
连接数受限的问题,经过大家的群(七)策(嘴)群(八)力(舌),Darren最终在项目中避开了连接数限制问题,取得了很好的实时效果。本篇侧重于对整个过程的复盘,不涉及SignalR
的基本面。
在Darren的项目中,设备的实时数据指向到了MVC中的一个控制器(DataReceiverController
)方法,局域网内的设备每隔几秒向该控制器方法发送实时数据一次,在其中进行处理并按设备号(设备号具备唯一性)异步保存到Redis
缓存,最终在视图页中展示某个区域的、比如10台设备的实时数据。
首先的一个思路是:当打开某个区域内包含10台设备的视图页,让它每隔几秒就到Hub
取数据,而Hub
负责把Redis
缓冲中的各个设备的数据收集上来转换成视图页所需要的格式。大致如下:
这样做能实现实时性,但是存在的问题是:由于每个设备中包含了多路数据,当设备中的某个线路数据发生变化,视图页需较长的时间才能反应过来。
代码方面,在依赖倒置容器、请求管道中的配置大致如下:
以上的MyHub
是SignalR
中最核心的部分。
有了Hub
,视图页就每隔几秒向Hub
请求一次。
以上,视图页每次向Hub
请求数据,Hub
就会调用视图页的broadcast
方法把数据加载到页面。
既然视图页加载10台设备的所有路数据实时反应不够理想,如果分而治之会怎样呢?如果在视图页配上10个iframe
,通过其src
属性加载各个设备的视图页呢?大致如下:
此时的Hub
需要根据设备号到缓存取数据再交给视图页。
运行下来会报错:cannot send data if the connection is not in the 'Connected' state。
原因在于:
每个客户端将同时具有大约6个连接的HTTP连接限制。当SignalR
使用长轮询或服务器发送事件时,很快就会达到限制。甚至WebSockets
也限制了大约50个连接。
于是Darren把问题抛给了群里。有说可以通过Stream
的方式来做,也有从设备通讯协议的角度给出建议。最后,"独火"建议只把数据变化交给客户端,Darren尝试了这种方式。
SignalR提供了IHubContext<T>
接口,可以把它注入到控制器,每当设备数据过来,把现有数据和缓存中的数据进行比对,如果有变化直接使用IHubContext<T>
调用视图页方法。
这样一来,在DataReceiverController
中获取到实时数据,与缓存数据进行比对,只把变化交给视图页。用这种方式实时反应明显提升,并且避开了SignalR
连接数限制的问题。
以上 .NET Core的运行时是2.0,各个运行时下使用的方式略有不同。