SignalR毫無疑問是.Net中很好使的實時消息處理系統(tǒng)。在我之前的公司的聊天功能就是用SinglaR進(jìn)行廣播推送的。不過他們沒有用到Group的概念。用的最多的就是All廣播推送。甚至部分Client方法都是用All的形式去推送。在前端用cookie判斷id選擇是否展示。毫無疑問這種寫代碼的方式雖然可以完成功能，但是性能極其差勁。為什么我要說是之前的公司呢，因為一些原因，我和我的直系領(lǐng)導(dǎo)鬧的很不愉快。在他要T我的時候，我要求合理的賠償。他竟然把自己代碼的問題甩鍋到我頭上，還說出了這樣的事。客戶都跑了沒有讓我賠償就不錯了。我真的是氣笑了。

具體到底是什么事呢。在我公司的系統(tǒng)里。有多套子房間的概念。客戶的需求是想要子房間的消息匯總到子房間或者全部互通。也有可能是部分匯總或者部分互通。很簡單的一個需求對不對？那么為什么會出問題呢？在SignalR的擴展上，MSDN有三種推薦方式。一是用Azure的SignalR服務(wù)。二是用SQL Server的MQ。三是用Redis的做底板。由于方案1要錢。方案2則是因為我們使用的是mysql。所以我最初的時候是選擇了redis方案。一開始他們的需求是子房間消息匯總到主房間。我只需要做一個很簡單的配置。就可以讓所有的web站點都能收到任意一個站點發(fā)出的消息。這就解決了這個問題。但是當(dāng)天晚上剛開始的時候經(jīng)理發(fā)現(xiàn)服務(wù)器的資源使用情況過高。也沒有如何排插問題就把我的代碼改了。選擇了暴露一個接口。然后子房間去調(diào)用主房間的消息接口。再由接口調(diào)用主房間的廣播已達(dá)到匯總的功能實現(xiàn)。當(dāng)時看到這個我已經(jīng)嚇尿了，這是什么神仙操作？但是由于后續(xù)沒什么問題，加上位卑言輕我也沒再說什么了。后來客戶的需求改了，想要把匯總改成互通。這按照他原先的設(shè)計。就要在子房間1發(fā)言的同時去調(diào)用所有房間的接口。再由每個房間分別去調(diào)用屬于自己站點的Signalr實現(xiàn)廣播。在這里我已經(jīng)聞道了代碼腐敗的味道了。接著客戶又改需求了。要實現(xiàn)部分房間互通。部分房間不互通。按照他的設(shè)計這里就需要維護(hù)一個互通列表。可惜他的做法真的是讓我捧腹大笑。

值得一提的是。這里所有的房間都是公用一套資源站點的。他這里不選擇后臺去控制廣播。反而選擇讓前臺來控制渲染。就是說不管怎么樣廣播都會發(fā)出。只是前端選擇是否展示而已。然后他就單獨的把不互通的站點再搞了一個資源站點。專門處理不互通的。我的天啊。這都是什么和什么啊。這些操作在我改了之后。我就再也沒有碰過了。后面可能是他們弄的太復(fù)雜了把自己都繞暈過去了，經(jīng)常出現(xiàn)一些問題。然后客戶跑了。他把這個問題怪在我身上，原因是這個問題本來是讓我解決的。所以這以后出的問題都是在我賬上的。我說你自己改掉了都沒有通知我。他竟然說不放心讓我改代碼。我真覺得我的領(lǐng)導(dǎo)是培訓(xùn)出來的。然后隨隨便便抄一些代碼。混一些年份就撈個職位出來騙錢了。

抱怨完了，進(jìn)入今天的主題。

轉(zhuǎn)載于:https://www.cnblogs.com/dbdn/p/11389733.html

總結(jié)

以上是生活随笔為你收集整理的.NET Core SignalR Redis底板详解（前言）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。