业务需求
- 人-项目关系
一个人可以属于多个项目,一个项目可以有多个人加入,通知的时候,可以通知项目内的所有人,也可以通知部分人或者某个责任人。 - 登录互斥
同一个人不允许登录两次(不同浏览器或者不同电脑登),后面登录的会将前面登录的人挤下线。 - 聊天
可以私聊、也可以创建群聊、上线通知(多个连接的情况) - 文件下载
用户在界面上选择了多个文件,然后选择批量打包下载,后端后台线程进行压缩、压缩完成后通过signalr通知该用户(的某个连接,比如当前用户开了多个tab页,应该只能推送给操作的那个tab页)
功能设计
名词解释: 业务系统:具体业务功能的系统 推送系统:实际的Signalr系统,跟业务系统分开部署
- 将推送单独成一个子系统;支持单独部署,可一台服务器也可以多台,通过redis作为底板来分发到服务器
- 推送子系统端自定义管理用户、连接、组,业务系统调用的时候
- 推送系统开发一个api,给业务系统直接调用(当然这不是最佳选择,可以通过消息队列,支持重试、优先级等,性能会比http形式好很多)
业务系统调用推送系统的时候传递参数包括,组、用户、推送数据对象,比如如下代码
var send = new Send()
{
// 推送的组,多个用,隔开
GroupId = GroupId,
// 关联的UserId 多个用,隔开
UserIds= UserIds,
// 是否排除用户
ExcludeUsers=ExcludeUsers,
// 实际推送的对象
NotifyObj = new NotifyObj()
{
Data = Data,
NotifyType = NotifyType,
OpType= OpType
},
};
-
有GroupId
-
ExcludeUsers=true
推送给指定的组中所有用户(排除掉UserIds部分) -
ExcludeUsers=false
推送给组中指定(UserIds中指定的)的这些用户
-
-
无GroupId
-
ExcludeUsers=true
推送给当前所有连接(排除掉UserIds部分的用户) -
ExcludeUsers=false
推送给指定用户(UserIds中指定的用户)
-
架构设计
- 组、用户、连接的关系
- 用户:[连接Id]
一个用户用多个连接、以Set形式存redis中 - 组:[连接Id:用户Id]
以Redis中的Hash格式存储,以Group为Key,以连接Id为Name,以UserId为值,一个用户在组中可能多个连接(开多个浏览器tab页),这样设计的好处是可以满足以下的几种情况- 给某个人推送
从redis中直接根据该用户的UserId查询该用户的所有连接,然后通过连接推送即可 - 给某个组推送
从redis中根据组名查询出所有的连接Id,通过连接直接推送 - 给某个组中的某些人推
这个时候不能根据人查连接Id,需要先根据组得到组中的人、连接Id,然后只给组中这些人对应的连接推送 - 用户上线的时候
在redis中存储一份用户与连接的关系;如果有组的情况,同时以Hash形式存储组、连接Id、用户Id - 用户再开一个浏览器tab页
在redis中该用户对应的连接中增加新的连接Id;如果有组的情况,同时以Hash形式存储组、连接Id、用户Id(因为是一连接Id为name的,然而连接Id是不重复的,所以是可以存着同一个组、同一个用户不同连接这种情况的) - 用户退出页面
在redis中找到该用户,从redis中删除改用户的找个连接Id,组的情况同样处理 - 给某个用户的某个连接Id推送
比如:用户点击打包下载,服务器端后台线程进行打包、压缩,完成后推送给指定的连接Id,前端界面再进行处理下载
- 给某个人推送
至此,业务分析完毕,更多内容请通过快速导航查看下一篇
快速导航
标题 | 内容 |
---|---|
索引 | .net core 3.0 Signalr - 实现一个业务推送系统 |
上一篇 | .net core 3.0 Signalr - 05 使用jwt将用户跟signalr关联 |
下一篇 | .net core 3.0 Signalr - 07 业务实现-服务端 自定义管理组、用户、连接 |
源码地址 | 源码 |
官方文档 | 官方文档 |