2014-05-15 161 views
2

出於測試目的,我想創建一個套接字服務器,它將包含1000多個並行套接字連接,它們遍佈在AWS上的X個ec2實例上(仍然使用JXCore,Java或Erlang來決定node.js)。這些套接字將每隔10秒將消息隨機發送到另一個套接字。我只是無法理解如何有效地存儲和讀取這些套接字。存儲大量插座的最佳做法是什麼?

我可以看到的兩個選項是將套接字對象存儲在應用程序本身中的地圖中,或將套接字存儲在快速數據庫(如Redis)中。將套接字存儲在應用程序內部的數據結構中的問題是它將能夠擴展,變得健壯,以及當數百萬套接字需要找到另一套時,讀取性能如何。如果我將它們存儲在像redis這樣的數據庫中,每次都必須有一個網絡調用,因爲Socket A需要知道Socket B發送消息的位置。我擔心這會大大降低性能。

我在想可擴展套接字服務器的最佳做法是什麼,因爲我無法在互聯網上找到任何回答此問題的東西。我在網上找到的每個套接字服務器都簡單地向每個其他套接字廣播,而不是具有特定的套接字,只包含10個套接字。

+0

您需要調查非阻塞IO解決方案;沒有什麼會處理你想要的套接字連接的數量。 – spudone

+0

非阻塞解決方案?您需要調查服務器場。 –

+0

他沒有說他的ec2實例的X是什麼,但我敢打賭,足夠投入來處理10mil的插座可能不是他想要的解決方案。 – spudone

回答

0

如果您希望此應用程序分佈在多個節點上,則需要有一種方法來至少確定目標節點。如果它可能是源和當前數據包的純函數,則不需要中央存儲器,這是最好的解決方案。

在其他情況下,中央存儲是不可避免的,但可能會應用一些優化來減少對其的訪問。本地套接字可以很容易地存儲在本地地圖中(erlang中的ets或mnesia,其他語言中的共享singleton地圖)並首先檢查。可能會要求源緩存目標地址,以便數據包將包含所有必要的信息。或者,目標緩存可以存儲在源套接字節點上,而不依賴於客戶端行爲。該緩存可用於路由,並且只有在路由操作不成功時纔可訪問中央存儲。

這可能是一些其他的優化,這取決於你的情況。

相關問題