业务需求
- 人-项目关系
一个人可以属于多个项目，一个项目可以有多个人加入，通知的时候，可以通知项目内的所有人，也可以通知部分人或者某个责任人。 - 登录互斥
同一个人不允许登录两次(不同浏览器或者不同电脑登)，后面登录的会将前面登录的人挤下线。 - 聊天
可以私聊、也可以创建群聊、上线通知(多个连接的情况) - 文件下载
用户在界面上选择了多个文件，然后选择批量打包下载，后端后台线程进行压缩、压缩完成后通过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 业务实现-服务端 自定义管理组、用户、连接 |
| 源码地址 | 源码 |
| 官方文档 | 官方文档 |
二维码
