我期望通过使用分布式数据系统来创build高可用性，可伸缩的networking解决scheme。 这里的一个节点描述了一个可以控制一个数据副本的networking。 这些节点可能包含多台机器，但有一个数据副本。
节点将包含可以处于使用状态或未使用状态的数据logging。 客户可以请求logging的转换从未用完状态转换为已用状态（请求花费）。 如果他们能够不止一次成功地做到这一点，就有安全风险。
如果一个节点与所有其他节点有连接，则单个节点可以告诉节点已经请求花费，并且可以确保没有其他节点想要访问该数据并且支出尚未发生。 节点可以将数据的状态改变为花费，其他节点不会这样做，因为他们知道其中一个节点正在更新它并处理花费。 所有节点都将更改数据，因此logging处于已用状态。
如果一个节点不能到达另一个节点，它可以假设另一个节点closures，并且将继续与其他节点一起工作，直到另一个节点恢复。 在这种情况下，节点将把所有更新发送到备份的节点。 如果这个失败的节点正处于当时不完整的花费操作的中间，那么它可以完成它。 这会造成一些操作的轻微停机时间。 这是在一个节点告诉其他节点它将花费，然后在它可以完成花费过程之前失败的情况。 在这种情况下，其他节点被阻止更新，因此失败的节点需要重新联机才能完成。
问题是，花费的处理只能发生一次。 如果networking被分区，攻击者知道这可能会要求在一个分区和另一个分区上花费。 networking的每个分区都会假定另一个分区被closures，所以会独立运行。 这可能会导致花费不止一次的处理。
如果networking双方的请求在分区的时候没有被提出，这不会成为问题。 当连接重新build立时，networking将变得最终一致。 如果攻击成功，则节点将在重新build立连接时了解攻击，因为networking的两侧将宣布相同的更改。
所以这是可以检测到的攻击，但实际上可能吗？
攻击者需要刻意去做这件事。 该软件的devise目的不是要一次进行多个支出请求。 攻击有一定的时间成本。 如果攻击者失败了，需要时间才能重新创build未使用的logging。 创build未使用的logging需要钱。 更多的钱将需要在一次攻击中使用，以获得更高的利益。 有一个时间成本的原因是，它需要一段时间才能收回钱重试。 他们可以承受许多较小的攻击，那么对他们的好处就会less一些，造成的损害也较less。
当然，分区自然是非常罕见的，如果攻击者随时都有攻击，那么攻击者必须有可笑的胜利。
如果连接自然丢失，则节点可以停止所有操作并尝试重新连接。 使用较低的超时连接到节点意味着它不必造成任何停机时间（可能只有极less的增加的延迟）。 如果重新连接失败，它将继续尝试，但随后重新启动操作（假设节点closures）。 会这样的事情，以防止偶尔的连接错误？
那么攻击者是否能够在networking中检测/导致分区？ 分区发生的可能性和多久？ 如果可能的话，哪些方法可以解决问题？
谢谢。
在处理群集场景中的类似问题之后，我熟悉你描述的情况。 这样的系统通常具有法定数量的概念，这就是为什么这样的系统需要奇数个成员节点。 法定人数是用来确定大多数和less数分区。
法定人数是大于一半的数字，它定义了提供服务时需要提供的可用节点的最小数量。 如果networking分区发生只有一个分区将有法定人数，另一个停止服务，直到分区消失。 如果发生多分区事件，则可能导致根本没有提供服务。 但是，它确保只有一个节点正在服务，这就是如何提供一致性。
至于分区的可能性，这取决于您的基础设施，以及您的节点如何相互通信可用性状态。
至于他们检测分区事件的能力，这取决于你的代码。 如果这两个分区在一个分区中是独立可寻址的（这可能不是这种情况），那么可能发生此类攻击的主要原因是。 根据我的经验，networking分区经常会将最终用户从一个分区以及其他节点中排除。 如果分区不可寻址，那么这种攻击就不太可能成功。
分布式存储最适合每隔n秒复制一次数据来源（例如使用SQL索引和使用复制规则）来推送数据。 中央内存“SQL”来控制状态。
简而言之，当您更改对象状态时，会将此信息传递到原始节点，并且在SQL中执行事务，同时将logging上的locking。
如果节点当时不能到达原点，那么操作必须失败，因为原始状态只在原始服务器上。
这就像起源边缘的工作stream程，起源有“记忆” – 状态，边缘“内容” – 对象。
从理论上讲，在保持安全性的同时，绕过上述的边缘和中心内存模型，并以简单的方式进行操作，是不可能的。 以上模式是最高效和最正确的，而模糊只会使生活变得困难。
如果您正在寻找一个可行的解决scheme，以便在存在分区的情况下允许交易继续，我有一个想法。
对于创build为未耗尽的每个新数据logging，将其分配给单个节点。 networking分区时，分配给可访问节点的数据logging是唯一允许客户端使用的logging。 分区解决后，所有的节点重新同步哪些数据logging被花费。 由于只有客户端可以访问的模式花费了分配给这些节点的logging，所以不应该有超额使用的logging。
我们必须考虑如何将logging分配给节点，以及在统一操作和分区操作期间当节点用完自己的logging时该怎么做。