你有一个大问题。我认为你思考问题的方式是一个更大的问题。让我们来看看一些基础知识。
聚类用于解决大问题，很像“吃大象”的问题。你可以设计一个独特的、大嘴巴的捕食者来解决这个问题。但是历史和古生物学向我们表明，大型捕食者不容易维持（它们对环境的代价很高）。
因此，要解决您的问题，您可以使用更大更强大的服务器。
或者，您可以使用集群。
聚类以一种非常不同的方式解决了“吃大象”的问题。它不会派出一只独特的巨大的捕食者来吃掉大象，而是使用分布式和共享处理的概念，一次吃一口。如果处理得当，蚂蚁可以吃掉大象。如果它们足够多并且情况正确。
但请注意，在我的示例中，蚂蚁非常小……一只蚂蚁永远无法承载整只大象。如果所有蚂蚁一起工作，你可以扛起整头大象，但是你会遇到并发和锁定问题（你必须协调蚂蚁）。
蚂蚁向我们展示了一种更好的方法来处理这个问题。他们会从大象身上分一杯羹，分小块处理问题。
在您的系统中，您问如何跨节点同步数据......我的问题是为什么？如果您正在同步数据，那么您正在镜像并且您的问题变得更大（您正在克隆大象，但只能吃原始数据）。
解决问题的方法是重新考虑解决方案，看看是否可以将问题分解成更小的部分。
在 Akka 和 Actor 模式中，处理问题的最佳方法是使用更小的“进程”（单个 ant）。虽然这个过程本身几乎没有用，但当大规模使用时，它们会变得非常强大。当架构正确完成时，您会注意到对蚂蚁使用火焰喷射器不会打败它们......更多的蚂蚁会来，它们会继续解决这个问题。
复制和同步数据不是您的解决方案，集群才是。您必须获取数据并将其分解到可以将其提供给单个蚂蚁的程度。如果你能做到这一点，那么你可以使用 Akka。如果这种方法看起来很可笑，那么 Akka 不适合你。
但是考虑一下……您显然对数据库后端有顾虑——您不想增加 IO 并引入单点故障。我不得不同意你的看法。但是你需要重新考虑事情。您可以使用数据库镜像来消除单点故障，但您是正确的，这不会消除瓶颈。所以假设镜像消除了单点故障......现在让我们攻击瓶颈部分。
如果您可以将数据拆分成蚂蚁可以处理的足够小的块，那么我会敦促您告诉蚂蚁仅在数据更改时向数据库报告...您可以在初始化时读取一次（您需要一个后端存储，不要自欺欺人，电力很快就会丢失......它必须保存在某个地方）但是如果你告诉你的蚂蚁只保留更改的数据，那么你将从等式中删除所有查询，这将大大改变负载的位置来自。一旦你只需要处理更新、插入和删除……整个环境就会简单得多。
集群应该是您的解决方案，但前提是您可以将镜像的概念从脑海中移开。
集群节点可以并且将会崩溃......但是它们可以在其他节点的其他地方重生，这样您就可以始终拥有一个快速的系统。只有当您处理节点/工作进程/蚂蚁的崩溃或丢失时，您才需要重新加载数据......
祝你好运……你概述了一个我见过拥有软件工程学位的人无法解决的棘手问题。