服務器廣播實現中的SignalR擴展/背板 - 是否不會導致客戶端重複消息？

SignalR文檔稱，在服務器廣播類型的加載/實現情況下，擴展/背板運行良好。不過，我懷疑在純服務器廣播的情況下，它會導致重複的消息被髮送到客戶端。考慮以下情況：服務器廣播實現中的SignalR擴展/背板 - 是否不會導致客戶端重複消息？

我有兩個我的集線器實例坐在我的Web服務器上負載均衡器後面的兩個Web服務器上。
每個服務器上的集線器都實現了一個定時器，用於數據庫輪詢以獲取一些更新並將其廣播到組中的客戶端，並按主題ID分組。
組/主題的客戶端可能會在兩臺服務器之間劃分。
兩個集線器實例都將從數據庫中獲取相同或重疊的更新。
現在，當每個集線器通過背板向客戶端發送更新時，它是否不會導致發送到客戶端的重複更新？

請建議。

2015-04-04 Nagesh Chopra

爲什麼你需要一段時間？你可以使用sql update notifier或手動觸發方法。你可以看看這個https://github.com/anik123/Chat-With-Angularjs-Signalr-Web-Api---Sql-server – 2015-04-05 01:56:48

@AnikIslamAbhi：我的應用程序是實時通信性質，並將有非常高的更新頻率，我不想被更新通知器或觸發器淹沒。相反，我想要的是一個間隔池來獲取併發送更新到客戶端，而不會導致從接收端到數據庫的大量連接。 – 2015-04-07 05:58:22

通過說手動觸發我想表示通知用戶操作，如用戶插入的東西。然後發送更新通知給大家 – 2015-04-07 06:05:32

問題不在於SignalR，而是您的數據庫輪詢生活在您的集線器中。背板可以正確處理廣播複製，但是如果您將其他責任添加到集線器，那麼情況就不同了。這是複製消息的部分，而不是SignalR，因爲現在您有N個輪詢器在所有服務器實例中進行廣播。

例如，您可以將集線器中的邏輯從集線器移到其他位置，並讓服務器應用程序的一個實例使用此新集合，以便通過輪詢來生成消息，也可能使用一個配置決定哪一個。這樣你只能從那裏發送消息，而SignalR的背板將負責複製。這只是一個非常基本的建議，它可以以不同的方式完成，但關鍵在於您的輪詢器不應該被複制，並且與SignalR沒有直接關係。

投票可能不是處理您的情況的最佳方式，但IMO會回答不同的問題，這也是事實。

來源

2015-04-05 17:06:27 Wasp

這是有道理的。我實際上有這個想法，但我擔心如果指定負責獲取和廣播更新的額外責任的一臺服務器將關閉，則應用程序將停止。這可能意味着實施單獨的邏輯來監視第一臺服務器和第二臺服務器的活動，以便跟蹤它，這樣如果第一臺服務器停機，它可能需要輪流承擔額外的責任。 – 2015-04-07 06:13:35

我大概也可以實現客戶端到客戶端場景而不是廣播。但我很想知道，如果廣播責任只能分配給一臺服務器，那麼在Web農場中SiganlR背板的廣播場景真的有意義嗎？ – 2015-04-07 06:13:53

這對任何客戶端發起的廣播都很有意義（想想聊天系統，其中一個用戶想向每個人說「你好」）。如果你有N個服務器，它們不僅僅是做SignalR的東西，而且它們中的任何一個都可以在負載均衡器後面做傳統的HTTP，在這種情況下你可能會有一個HTTP POST命中一個特定的服務器併產生一個廣播。您遇到的問題與您的案例有關，您的意見是有道理的，但還有許多其他情況下廣播是從系統外部啓動的，而且它們在背板上工作得很好。 – Wasp 2015-04-07 06:34:50

服務器廣播實現中的SignalR擴展/背板 - 是否不會導致客戶端重複消息？

回答

相關問題