Performance 具有负载平衡和冗余的RavenDb拓扑

我们正试图找到合适的RavenDb拓扑结构，使我们能够平衡负载并具有容错能力。 似乎更好的负载平衡方法应该是使用本机分片，我们可能会转而使用它，但由于域的特殊性，在这一点上它不是微不足道的。 为了实现冗余，我们只需在每个组中设置2个ravendb节点，并在其中设置主/主复制，因此，如果其中一个节点出现故障，ravendb客户端将自动切换到另一个节点。 我们有索引“组件”，它是唯一一个将写入数据库的组件，因此它将写入一个节点，我们希望这些更改最终会被分发。我们将在两组ravendb节点之间设置主/主复制，这样，如果索引组件最终返回到组1，则应将更改复制到第二组

因此，冲突的风险似乎很低，因为我们只有一个玩家向数据库写入数据（一分钟一次，使用束）。有关此设置的几个问题：

RavenDb有这么多大师/大师是典型的吗 复制品

这个问题能更容易地解决吗

如何配置客户端的回退约定，以使每个web节点在失败之前先失败到其组中的另一个节点 另一组的RavenDb节点

如果我们在每个web节点上嵌入简单的循环读取逻辑（web节点1将从 两者：RavenDb1_01和RavenDb1_02）？它会成为标准的RavenDb吗 回退行为会变得疯狂吗

1） 是的，在这样一个集群中有许多节点是很常见的。请注意，您需要设置要在此类拓扑中更改和复制的复制

2） 通常，拥有完全连接的拓扑比拥有此处的图层更容易

3） 故障切换始终基于客户端的主节点目标顺序。换句话说，如果节点2有目的地（节点1，节点3），而节点1有目的地（节点3，节点2）。 最初连接到节点2的客户端将转到节点1，然后转到节点3 在故障转移时，最初连接到节点1的客户端将转到节点3，然后在故障转移时转到节点2

4） 循环和故障转移分别运行