0

我不确定这个问题究竟在哪里(或甚至如何问),所以我希望这里有人能指引我朝着正确的方向前进。开发集群应用程序

我有一个服务,我正在建设。该服务在内存中有不同的对象 - 每个都有自己的状态。每当创建一个对象时,它都会从数据库中加载状态并保存它。对对象进行更改时,它们对数据库也是持久的。

我想扩展这项服务。我研究过诸如akka.net(演员模型)等解决方案,他们有一个集群解决方案。从我读过的内容来看,它将状态与他们称之为“闲话”的事物同步,每个节点将状态发送给另一个节点。我不确定现在真的有可能将我的工作应用程序转换为akka.net。

我想知道集群如何保持不同节点之间的状态同步(我得到八卦概念),如果我有机器A接收到消息并且同时机器B也收到一条消息改变对象的相同状态 - 这会导致状态之间的数据完整性问题。我唯一的想法是锁定一个共享资源,但是这打破了集群的目的。

保持数据库中的状态也不是一种选择,因为数据库成为瓶颈和单点故障。

我似乎无法在网上找到任何相关的阅读材料 - 但我也缺乏我需要关注的技术短语。

如果它是相关的,我使用.NET Core和c#进行开发。

任何人都可以解释群集的概念,它是如何工作的,并确保节点同步?或者可以指向正确的方向?

+0

只是为了澄清,Akka.NET的群集八卦只存在一个标签集群的健康,即:知道何时节点变得可用,当他们死亡等 它*将*不*同步你的任何演员状态。调度消息并确保群集中的角色同步状态将完全是您的责任。 您可以使用不同的方法来实现这一点,IIRC Petabridge有一些关于这个(和其他有用的Akka.NET文章)的博客文章。 – easuter

回答

1

你有一个很大的问题。我认为你对这个问题的思考方式是一个更大的问题。我们来看看一些基础知识。

聚类用于解决大问题,很像“吃大象”问题。你可以解决这个问题,设计一个巨大的嘴巴独特的更大的捕食者。但是历史和古生物学已经向我们表明,大型掠食者并不容易持续(它们在环境上是昂贵的)。

所以要解决你的问题,你可以采取一个更强大的服务器。

或者,您可以使用群集。

集群解决了“吃大象”问题的一种非常不同的方式。相反,发送一个唯一的巨大捕食者与巨大的嘴巴吃大象的,它会使用分布式和共享处理的概念,在同一时间吃一咬。如果做得好,蚂蚁可以吃大象。如果他们够了,情况是正确的。

但是请注意,在我的例子中,蚂蚁非常小...单个蚂蚁将永远不会携带整个大象。如果所有的蚂蚁一起工作,你可以携带整个大象,但是然后你遇到并发和锁定问题(你必须协调蚂蚁)。

蚂蚁已经向我们展示了一个更好的方法来处理这个问题。他们会拿一块大象,用小块处理这个问题。

在你的系统中,你问你如何跨节点同步数据......我的问题是为什么?如果你正在同步数据,那么你正在镜像,你的问题变得更大(你是克隆大象,但只能吃原来的东西)。

解决您的问题的方法是重新考虑解决方案并查看是否可以将问题分解为更小的部分。

在Akka和Actor模式中,处理问题的最好方法是使用更小的“过程”(单个蚂蚁)。虽然这个过程本身几乎是无用的,但当它大规模使用时,它们可能变得非常强大。当架构正确完成后,你会注意到用火焰喷射器蚂蚁不会打败他们...更多的蚂蚁会来,他们将继续解决问题。

复制和同步数据不是你的解决方案,它是群集。你必须拿出你的数据并将其分解到可以将它交给一只蚂蚁的地步。如果你可以做到这一点,那么你可以使用Akka。如果这种方法看起来很可笑,那么Akka不适合你。

但是考虑一下......你显然担心你的数据库后端 - 你不想增加IO并引入单点故障。我不得不同意你的看法。但是你需要重新思考。您可以通过数据库镜像来删除单点故障,但您确信这不会消除瓶颈。因此,让我们说,镜像消除了单点故障......现在让我们攻击瓶颈部分。

如果你可以将你的数据分成足够小的块,蚂蚁可以处理它,那么我会敦促你告诉你的蚂蚁只在数据发生变化时才向数据库报告......你可以在初始化时读取它(你需要一个后端存储,不要欺骗你自己,电力可以很快失去......它必须保存在某个地方),但是如果你告诉你的蚂蚁只保留更改后的数据,那么你将删除所有等式中的查询,转移负载来自哪里。一旦你只有更新,插入和删除处理...整个景观将会简单得多。

集群应该是您的解决方案,但前提是您可以将远离您的想法的镜像概念。

集群节点可以并且会崩溃......但是它们可以在其他节点重新生成其他节点,以便您始终拥有一个快速系统。只有当你处理一个节点/工作进程/蚂蚁的崩溃或损失将必须重新装载数据......

祝你好运......你所概述,我已经看到了软件工程学位的人一个可怕的问题解决失败。