.net core 3.0 Signalr - 06 業務實現-業務分析

業務需求

1. 人-項目關係

一我的能夠屬於多個項目，一個項目能夠有多我的加入，通知的時候，能夠通知項目內的全部人，也能夠通知部分人或者某個責任人。

1. 登陸互斥

同一我的不容許登陸兩次(不一樣瀏覽器或者不一樣電腦登)，後面登陸的會將前面登陸的人擠下線。

1. 聊天

能夠私聊、也能夠建立羣聊、上線通知(多個鏈接的狀況)

1. 文件下載

用戶在界面上選擇了多個文件，而後選擇批量打包下載，後端後臺線程進行壓縮、壓縮完成後經過signalr通知該用戶(的某個鏈接,好比當前用戶開了多個tab頁，應該只能推送給操做的那個tab頁)

功能設計

名詞解釋: 業務系統:具體業務功能的系統 推送系統:實際的Signalr系統，跟業務系統分開部署

1. 將推送單獨成一個子系統；支持單獨部署，可一臺服務器也能夠多臺，經過redis做爲底板來分發到服務器
2. 推送子系統端自定義管理用戶、鏈接、組，業務系統調用的時候
3. 推送系統開發一個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中指定的用戶)

架構設計

1. 組、用戶、鏈接的關係

• 用戶:[鏈接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 業務實現-服務端 自定義管理組、用戶、鏈接
源碼地址	源碼
官方文檔	官方文檔