基於Erlang的聊天（負載均衡和通知分發）

Question

我們將爲我們的使者開發一個後端，所以我有一個想法，我想在這裏描述，也許有人可以給我一個建議。

1）想法：

的Nginx - 重定向請求到隨機節點（輪循） - > 二郎簇 - 重定向到實際節點（我們選擇與進程最小數目節點） - > 握手 - > 升級到WebSocket。

集羣中的每個節點都有ETS表，其中包含每個節點（字段 - 節點，num_processes）的進程數。每個節點每5秒將其進程數發送到羣集中的所有節點。

所以我們不需要有主節點，因爲每個節點都可以做負載均衡。

2）其他問題：

這是個好主意，註冊用戶的活躍WebSocket連接器（PID）在全球範圍與GPROC？我們需要這個列表讓每個用戶通過ws向最終用戶發送通知。

Answer 1

1）是的 - 這是一個很好的計劃。您可以進行的一項改進是每次在將負載平衡到另一個節點時增加遠程節點的負載。這就像保持對遠程節點負載的估計並阻止您一次將所有負載發送到一個節點五秒鐘。每當您收到來自其他節點的廣播時，只需覆蓋您的本地估算值 - 這將修復任何缺失的更新並確保您的估算值保持在實際遠程值的少量範圍內。

2）您可以爲每個WebSocket進程使用一個名爲{Username, true}的gproc屬性 - 這可以讓您在整個集羣中查找用戶的所有WebSocket會話。

我忘記了gproc用於全局註冊的底層協議，以及您在整個羣集中始終註冊/註銷屬性的成本。爲了在分區後支持廉價的名稱查詢和衝突解決方案，我開發了一個非常類似的系統（用戶狀態和會話和多節點負載平衡消息傳遞），最後編寫了ngproc。它可以作爲開源使用，並且可以提供一些可以使用的想法。

Answer 2

有趣：

• 您設計的是什麼樣的用戶數量？
• 在聊天中會發送多少數據？它是用於文字，圖像還是視頻？
• 什麼是負載平衡，即您認爲哪個資源是關鍵資源？
• 如果一個節點死亡，你會發生什麼？