沒有中央控制點的冗餘？

Question

如果可以向多個客戶端提供服務，如果提供此服務的服務器出現故障，則另一個服務器將其佔用，而不需要某種集中的「控制」，它可檢測主服務器是否已關閉並重定向客戶端到新的服務器？

有沒有可能沒有一個集中的接口/網關？

換句話說，它有點像問你能不能設計一個節點平衡器而沒有集中控制來指導客戶端？

Answer 1

此答案是網絡應用程序高可用性的一般概述，不是Erlang特有的。我不太瞭解OTP框架中可用的內容，因爲我對這種語言很陌生。

---

這裏有幾個不同的問題：

1. 客戶端的連接必須移動到備份機
2. 會話可能包含狀態數據
3. 如何檢測碰撞

問題1-移動客戶端連接
這可以通過許多不同的方式在網絡架構的不同層上解決。最簡單的方法是直接將代碼寫入客戶端，以便在連接丟失時重新連接到另一臺計算機。

如果你需要網絡透明你可以使用一些技術來同步不同的機器之間的TCP狀態，然後重新路由所有流量的新機，這可能是客戶端完全無形。這比第一個建議要難得多。

我確定這兩者之間有很多事情要做。

問題2 - 國家數據
你顯然需要會話狀態從墜毀機對備用機轉移。這很難以可靠的方式完成，並且您可能會丟失最後幾筆交易，因爲崩潰的計算機可能無法在崩潰前發送最後一個狀態。您可以使用這種方式同步調用是真正肯定沒有失去狀態：從客戶端

1. 交易/消息進入該主機。
2. 主機更新了一些狀態。
3. 新狀態發送到備份機。
4. 備份機器確認新狀態的到來。
5. 主機確認客戶端成功。

在某些情況下，這可能會很昂貴（或者至少沒有足夠響應），因爲在甚至向客戶端確認任何內容之前，依賴於備份計算機及其連接（包括延遲）。爲了使它更好地執行，您可以讓客戶端在連接時檢查備份計算機收到的事務，然後重新發送丟失的事務，使客戶端負責排隊工作。

問題3 - 檢測碰撞
這是一個有趣的問題，因爲在崩潰並不總是明確。有事真的崩潰了嗎？考慮一個網絡程序，它關閉客戶端和服務器之間的連接，但兩者仍然連接並連接到網絡。或者更糟糕的是，使得客戶端在沒有服務器注意的情況下從服務器斷開。這裏有一些需要考慮的問題：

• 客戶端應該連接到備份機器嗎？
• 如果主服務器更新某些狀態並將其發送到備份機器而備份連接了真實的客戶機時會發生什麼情況？會出現數據競爭嗎？
• 主機和備機能同時啓動還是需要關閉其中一個工作並移動所有會話？
• 您是否需要某種權限在這個問題上，一些協議來決定哪一個是主人和哪一個是奴隸？誰是那個權威？你如何分散它？
• 如果您的節點失去它們之間的連接，但兩者都能按預期繼續工作（稱爲網絡分區），該怎麼辦？

Answer 2

那麼，你沒有提供關於你所詢問的「服務」的很多信息，所以我將以的通用方式回答。

對於我答案的第一部分，我假定你正在談論涉及IP地址的「集中接口/網關」。爲此，有CARP（通用地址冗餘協議），從wiki引：

的通用地址冗餘協議或CARP是一種協議，它 允許同一本地網絡上的多臺主機共享一組IP 的地址。其主要目的是提供故障轉移冗餘， ，尤其是與防火牆和路由器一起使用時。在一些 配置CARP也可以提供負載平衡功能。它是 是一個免費的，非專利保護的思科HSRP替代品。 CARP主要是在BSD操作系統中實現的 。

引述NetBSD的「Introduction to CARP」：允許一組在同一網段的主機到 共享一個IP地址

CARP作品。這組主機被稱爲 「冗餘組」。該冗餘組被分配了在組成員之間共享的IP地址 。在組內，一臺主機 被指定爲「主」，其餘爲「備份」。主控主機 是當前「擁有」共享IP的主控主機;它會響應任何指向它的流量或ARP請求。每個主機一次可能屬於多個冗餘組。

這可能會解決您的問題在網絡級別，通過讓奴隸順序接管IP地址，沒有單點故障。

現在，對於答案（應用程序級別）的第二部分，使用分佈式erlang，可以有幾個節點（一個集羣），它們會爲您提供容錯和冗餘（因此您不會在此處使用IP地址，但是「分佈式erlang」 - 一個erlang節點集羣）。

您將有很多節點隨着Distributed Applciation的啓動而停滯，並且您的應用程序資源文件將包含應用程序可運行的節點列表（已排序）。

Distributed erlang將控制哪些節點是「主」，並且會自動啓動和停止不同節點中的應用程序，因爲它們會上下移動。

引用（儘可能少）從http://www.erlang.org/doc/design_principles/distributed_applications.html：

在分佈式系統中具有若干Erlang節點，可能存在需要 控制以分佈式方式應用。如果節點，其中 某個應用程序正在運行，出現故障時，應用程序應該是 在另一個節點重新啓動。

該應用程序將在第一節點處被啓動，由 分佈式配置參數，這是啓動和運行指定。 應用程序照常啓動。

爲了使應用程序控制分配正常工作，分佈式應用程序可以運行的節點 必須彼此聯繫並且 協商啓動應用程序的位置。

啓動時，節點將等待由 指定的所有節點sync_nodes_mandatory和sync_nodes_optional出現。當所有 節點都上來了，或者當所有強制的節點都拿出了和sync_nodes_timeout指定的 時間已經過去，所有的應用程序 將啓動。如果不是所有的強制節點都上來了，節點 將終止。

如果其中運行應用程序的節點出現故障， 應用在第一 節點重新啓動（在指定的超時之後），通過分佈式配置參數，這是 啓動並運行指定。這被稱爲故障轉移

分佈式= [{應用，[超時，] NodeDesc}]

如果一個節點被啓動，它具有較高的優先級，根據 分佈，比節點，其中一個分佈式應用 當前正在運行，應用程序將在新的節點 重新啓動，停在舊節點。這被稱爲收購。

好吧，這本來是作爲一般瞭解，因爲它可以是一個長期的話題:)

對於具體的細節，強烈建議閱讀learnyousomeerlang的Distributed OTP Applications章（和當然的了以前的鏈接：http://www.erlang.org/doc/design_principles/distributed_applications.html）

此外，您的「服務」可能依賴於其他外部系統（如數據庫），因此您應該考慮容錯和冗餘。整個體系結構需要容錯併爲「服務」分配以這種方式工作。

希望它有幫助！

Answer 3

查看Google的論文"Chubby lock server" (PDF)和"Paxos made live" (PDF)以獲得想法。

簡而言之，此解決方案涉及使用共識協議來選擇處理所有請求的一組服務器中的主服務器。如果主設備發生故障，則該協議再次用於選擇下一個主設備。

此外，請參閱gen_leader作爲領導選舉中的一個示例，它可以檢測故障並轉移服務所有權。