标签：
1.选用Signalr的原因
Signalr内部给我们做了很多封装。当服务器或者浏览器不支持websoket协议的时候就使用长连接方式 不支持长连接再选用轮询的方式获取消息
websoket：与服务器保持长连接 服务器和客户端可以进行双工通讯而不用建立新的链接
长连接：服务器与客户端保持长连接 。每隔一段时间客户端询问服务器 而不用建立新连接
轮询：客户端定期向服务器发送请求询问 每次都会建立新的链接(建立新的链接使非常耗时的)
2.集群情况下的遇到的难点
当一个一台服务器的给某个用户发送了一个消息如果判断用户是否在线(单台服务器很容易就实现了 但是用户在其他服务器登陆也是在线状态)
3.安装signalr
(1) 通过NUGET搜索Signalr点击安装安装
(2)安装会自动引入signalr的依赖类库和js
4.配置signalr
(1)页面配置(模板页和推送页面)
(2)服务器端配置
添加一个启动类
添加一个PushHub类 继承Hub类
现在我们看看AddUser方法的处理逻辑
再看看RemoveUser的处理逻辑
这时还需要在Push类里面增加几个方法
准备一个api接口用于集群情况下的消息推送
这个时候我们的站点就部署好了。。
还需要一个类似中转站的api 当服务器发送消息就发送到这个api 这个api再调用每台服务器上面这个接口 如果其中一个返回true则表示已经推送了 不做任何处理 如果都返回false 则存入他的离线消息池(我项目里面用的是redis)
下面用一张图来展现集群情况下消息推送的设计思路
部署signalr可能遇到的错误
1.发布到正式后signarl/Hub 请求虚拟js 404
可能是路径解析问题。而不是当做请求的一个虚拟js来处理 解决方法
在Nuget 输入这段命令：Install-Package Microsoft.AspNet.SignalR.Utils 安装成功后 会在项目的packages\Microsoft.AspNet.SignalR.Utils.2.2.0\tools 文件下有个exe 在项目中新建一个文件夹复制进去
$(ProjectDir)signalr\signalr.exe ghp path:$(TargetDir) /o:$(ProjectDir)Scripts/hubs.js
这样我们每当我们重新生成或者编译的时候就会自动更新Scripts下的hubs.js了
然后前端页面的那个路径就可以改了
标签：
原文地址：http://www.cnblogs.com/LQBlog/p/5241507.html
