開發集羣應用程序

Question

我不確定這個問題究竟在哪裏（或甚至如何問），所以我希望這裏有人能指引我朝着正確的方向前進。

我有一個服務，我正在建設。該服務在內存中有不同的對象 - 每個都有自己的狀態。每當創建一個對象時，它都會從數據庫中加載狀態並保存它。對對象進行更改時，它們對數據庫也是持久的。

我想擴展這項服務。我研究過諸如akka.net（演員模型）等解決方案，他們有一個集羣解決方案。從我讀過的內容來看，它將狀態與他們稱之爲「閒話」的事物同步，每個節點將狀態發送給另一個節點。我不確定現在真的有可能將我的工作應用程序轉換爲akka.net。

我想知道集羣如何保持不同節點之間的狀態同步（我得到八卦概念），如果我有機器A接收到消息並且同時機器B也收到一條消息改變對象的相同狀態 - 這會導致狀態之間的數據完整性問題。我唯一的想法是鎖定一個共享資源，但是這打破了集羣的目的。

保持數據庫中的狀態也不是一種選擇，因爲數據庫成爲瓶頸和單點故障。

我似乎無法在網上找到任何相關的閱讀材料 - 但我也缺乏我需要關注的技術短語。

如果它是相關的，我使用.NET Core和c＃進行開發。

任何人都可以解釋羣集的概念，它是如何工作的，並確保節點同步？或者可以指向正確的方向？

Answer 1

你有一個很大的問題。我認爲你對這個問題的思考方式是一個更大的問題。我們來看看一些基礎知識。

聚類用於解決大問題，很像「吃大象」問題。你可以解決這個問題，設計一個巨大的嘴巴獨特的更大的捕食者。但是歷史和古生物學已經向我們表明，大型掠食者並不容易持續（它們在環境上是昂貴的）。

所以要解決你的問題，你可以採取一個更強大的服務器。

或者，您可以使用羣集。

集羣解決了「吃大象」問題的一種非常不同的方式。相反，發送一個唯一的巨大捕食者與巨大的嘴巴吃大象的，它會使用分佈式和共享處理的概念，在同一時間吃一咬。如果做得好，螞蟻可以吃大象。如果他們夠了，情況是正確的。

但是請注意，在我的例子中，螞蟻非常小...單個螞蟻將永遠不會攜帶整個大象。如果所有的螞蟻一起工作，你可以攜帶整個大象，但是然後你遇到併發和鎖定問題（你必須協調螞蟻）。

螞蟻已經向我們展示了一個更好的方法來處理這個問題。他們會拿一塊大象，用小塊處理這個問題。

在你的系統中，你問你如何跨節點同步數據......我的問題是爲什麼？如果你正在同步數據，那麼你正在鏡像，你的問題變得更大（你是克隆大象，但只能吃原來的東西）。

解決您的問題的方法是重新考慮解決方案並查看是否可以將問題分解爲更小的部分。

在Akka和Actor模式中，處理問題的最好方法是使用更小的「過程」（單個螞蟻）。雖然這個過程本身幾乎是無用的，但當它大規模使用時，它們可能變得非常強大。當架構正確完成後，你會注意到用火焰噴射器螞蟻不會打敗他們...更多的螞蟻會來，他們將繼續解決問題。

複製和同步數據不是你的解決方案，它是羣集。你必須拿出你的數據並將其分解到可以將它交給一隻螞蟻的地步。如果你可以做到這一點，那麼你可以使用Akka。如果這種方法看起來很可笑，那麼Akka不適合你。

但是考慮一下......你顯然擔心你的數據庫後端 - 你不想增加IO並引入單點故障。我不得不同意你的看法。但是你需要重新思考。您可以通過數據庫鏡像來刪除單點故障，但您確信這不會消除瓶頸。因此，讓我們說，鏡像消除了單點故障......現在讓我們攻擊瓶頸部分。

如果你可以將你的數據分成足夠小的塊，螞蟻可以處理它，那麼我會敦促你告訴你的螞蟻只在數據發生變化時才向數據庫報告......你可以在初始化時讀取它（你需要一個後端存儲，不要欺騙你自己，電力可以很快失去......它必須保存在某個地方），但是如果你告訴你的螞蟻只保留更改後的數據，那麼你將刪除所有等式中的查詢，轉移負載來自哪裏。一旦你只有更新，插入和刪除處理...整個景觀將會簡單得多。

集羣應該是您的解決方案，但前提是您可以將遠離您的想法的鏡像概念。

集羣節點可以並且會崩潰......但是它們可以在其他節點重新生成其他節點，以便您始終擁有一個快速系統。只有當你處理一個節點/工作進程/螞蟻的崩潰或損失將必須重新裝載數據......

祝你好運......你所概述，我已經看到了軟件工程學位的人一個可怕的問題解決失敗。