我試圖設計一個實時羣聊應用程序,專門針對大羣體(> 50個用戶)在每個聊天室中。並非所有的用戶都會一次積極地聊天,但是人們可以期望很多用戶只需閒聊/收聽聊天,並在聊天室聊天時收到更新。設計後端(雲)服務器以避免「熱點」場景
我制定了一個不是面向雲的原型,並且正在爲基於雲的系統重新設計。
我希望有一個重定向/負載平衡服務器(LBServer)重定向到一系列後端「聊天」服務器(CServer)。當用戶請求從客戶端加入特定的聊天室時,客戶端將連接到LBServer,並且LBServer將回復一個特定的CServer的連接信息,該信息在內存中維護聊天室的一個實例。然後客戶端將從LBServer斷開並連接到CServer。只要用戶留在聊天室中,與CServer的連接就會持續。 CServer負責更新後臺數據庫,以記錄聊天室狀態,並通知聊天室中連接到自己的其他客戶端更新。
您可以想象一個聊天室中是否存在太多用戶(因此一個CServer必須與所有這些用戶保持持續連接),如果房間中的活動增加超過CServer的閾值,「熱點」方案將會展開處理速度跟上所有更新。
在這一點上,我想出了一個天真的解決方案,以便我的系統仍然可以擴展。我可以加載一個較大的CServer實例,複製聊天室的狀態,並請求「熱」CServer中的所有用戶重新連接到新的較大實例。我不認爲這是處理這種系統可擴展性的正確方法。
我有幾個問題:
鑑於我想聊天的實時性,有沒有設計我的後端系統,以避免必須堅持到一個服務器實例連接的更合適的方法?
當我正在跟蹤數據庫中的狀態時,我是否甚至需要打擾隔離每個聊天室的處理以發生在一個CServer上?我想留下空間讓用戶能夠同時參加多個聊天室。如果我們使用當前的模型,客戶端將不得不保持與我的雲的多個連接(每個用戶所在的聊天室都有一個連接)。這很糟糕的客戶端。作爲一項修訂,我設想客戶端保持與'通用'CServers的連接,該服務器將監聽用戶當前正在訪問的聊天室中的更改並相應地更新它們。
所有的反饋和意見都會非常感謝,並且我會很樂意詳細說明任何不清楚的事情。謝謝。
什麼是你想要的廣播和接收之間實現延遲?爲什麼沒有現成的東西呢? – Ron 2011-06-04 00:25:52