我的客户制造一种医疗设备，对给定样品进行各种测量，并将结果写入数据库。 生成的数据量相对较小。
在当前configuration中，每个设备都有自己的计算机，并且该计算机运行数据库服务器的一个实例。 设备没有联网。
客户希望修改设备，使其中大约五十个可以连接到局域网。
这些设备使用很多编号的消耗品，一旦使用就不能再使用。 这些批号在测量样品时写入数据库。 这个要求值得注意，因为在当前configuration中，设备无法知道消耗品是否已经被不同的设备使用。 在所提出的networkingconfiguration中，期望存在每个设备将立即访问由其他设备使用的消耗品的信息。
这些设备还需要跟踪testing过程中使用的各种化学品的数量。 每瓶化学品都有很多编号和条形码。 当瓶子插入机器时，机器读取数据库以确定从瓶子消耗了多less液体。 人们期望有很多数量的瓶子可以插入任何一台机器，机器能够精确地测量瓶子中的液体量。
客户想要推荐两种架构应该使用哪一种：
1.）每个设备都会像现在这样将数据写入到自己的本地数据库中。 同步软件将被安装在每个设备上，同步将被实时执行。 每个设备将周期性地广播一个心跳（build议1到5分钟的间隔），这个心跳将包含一个CRC校验和。 networking上的每个设备都将监听心跳。 如果心跳CRC与自身不同，设备将启动同步。 同步软件在运行testing的软件的外部并且独立于软件。 因此，从理论上讲，一台设备在与networking断开连接或者同步软件不运行的时候可能会运行，但不太可能。
2.）每个设备上的数据库服务器将被删除，而数据库服务器将被使用。
客户端担心，如果使用数据库服务器，则在服务器发生故障的情况下，networking上的所有设备都将变得不可用。 使用对等拓扑有效地降低了这种风险吗？ 换句话说，如果networking上的一个对等设备出现故障，所有其他对等设备的运行情况如何？ 任何数据完整性危险或利益与任何方法相关？
编辑回应iag和MikeyB的答案：
我可以看到我的问题是如何留下模棱两可的，所以在这里再次，希望以更有意义的方式措辞。
在客户端 – 服务器环境中，服务器故障是灾难性的，因为如果服务器出现故障，所有客户端都将closures。 鉴于这种devise特点，为什么一些高度关键的信息，库存，财务和医疗系统实现客户端 – 服务器架构而不是对等？
请注意我不是在问“如何缓解风险服务器故障？” 我问：“对等体系结构是缓解服务器故障风险的有效方法吗？ 为什么或者为什么不？ networking的拓扑结构是否会影响应用程序的devise？ 点对点是否会引入数据损坏或模糊结果的可能性？
以下是对等networking拓扑结构中可能出现的一个现实例子吗？
DeviceA，DeviceB和DeviceC是对等networking上的计算机，它们共享一个称为代理R的公共代理程序。每当对等方需要检查有多lessR可用时，它就会与其他对等方同步并计算可用性。 大约下午1点的一天，实验室技术人员将一瓶R插入DeviceB。 DeviceB立即与DeviceC同步并确认DeviceC从未从该瓶中消耗R。 然而DeviceA自从中午以来一直没有响应ping。 DeviceB可以可靠地计算瓶子里的R的数量吗？
我是一名软件工程师，我将编写允许这些设备通过networking共享数据的应用程序。 老实说，我对我所问的问题有意见，但是我的客户不相信我的经验。 我想知道我的同事的经验，因此我的职位在这里。 我不想把言语放在任何人的口中，所以我想尽量不要一般，而是要解释这个问题。
如果在底层networking中已经具有冗余，则对等软件体系结构可以是在节点之间传播信息的有效且容错的方式。
如果多个节点保存数据，对等体系结构还可以保护您免遭数据丢失。 在典型的对等系统中，由于节点自身的利益，节点保存数据。 你想要的是不同的，因为你希望他们保持数据，因为坚持一个政策，而不是个人利益。
只要数据量有限，存储所有事物的每个节点都很简单。 但是，由于存储空间（或者由于法律要求，在某些情况下），存储所有内容可能不切实际。 那么需要注意要删除什么以及要保留什么。 这是主要的缺陷之一。
但是，所有这些都没有解决数据完整性和数据一致性的问题。 如果您只是简单地转换到对等体系结构而不给数据的正确性，那么系统在这方面的稳健性就会下降。 只有更多的地方可以引入腐败。
为了实现这样的解决scheme，你需要弄清楚如何validation一块数据的完整性。
一个只能由系统中的一个特定节点更新的数据是最容易处理的。 但是，如果该节点开始行为不当，您仍然需要问一下系统的可接受行为。 让节点密码签名每个更新是不够的，如果它可能错误地发出签名更新以删除它先前写入的所有内容或发送多个签名的更新不同意数据的新值。 再次简单的方法是存储所有内容，并需要手动干预，如果出现冲突的更新。 但是，如果您需要根据数据做出任何自动决定，那么这是不够的。
如果只有一个节点可以更新数据，但是对于其他人都同意它执行的更新有严格的要求，那么问题会变得稍微困难一些。
这个问题的解决scheme仍然不是非常复杂，它提供了用于解决这种数据完整性问题的各种方法。
允许首先发送更新的节点可能会以阻止数据再次更新的方式失败。 但只要它发出一致的更新，那么它将最终在整个对等networking中一致地存储。
这可能听起来好像每一块数据所需的大量签名都需要大量的存储空间。 幸运的是，这可以通过称为阈值签名的方法来避免。
但是，如果要replace数据库，一个节点可以更新一个数据是不够的。 您有多个节点，可以更新同一条数据，但是您需要整个networking就谁是第一个达成一致。 这是拜占庭式的协议。
解决这个问题的方法比上面描述的要复杂得多。 但是我可以提一些关键的成果要注意。
您必须在两个故障模型之间进行select。 您可以假设一个失败的节点只是停止通信，并且从不发送单个损坏的消息。 这种模式需要较less的硬件，但只需要一个翻转的位就可以降低系统的性能。
另外，你也可以select拜占庭式的失败模式，这个失败模式可以让一个失败的节点做任何事情，系统仍然能够存活下来。 为了容忍这个模型中的t故障，你总共需要3t+1节点。 换句话说，为了容忍一个单一的故障节点，你需要四个节点。 如果总共有10个节点，则可以容忍3个节点的故障。
您还必须在同步或asynchronous通信模型之间进行select。 同步通信意味着您对通信时间进行了假设。 如果数据包需要较长时间才能到达目的地，系统就会崩溃。 此外，如果节点崩溃，则必须等待系统可以继续运行之前所允许的最大延迟时间。
asynchronous模型使得软件devise更加复杂，但具有一些明显的优势。 您不必等待超时，而只需等到三分之二以上的节点才能继续，就可以比需要较长时间的同步模型快得多。
asynchronous模型的另一个缺点是它必须是随机的。 algorithm的运行时间成为没有最坏情况下的随机variables。 有一个理论上的可能性，更新将花费无限的时间，但是这个概率可以被表示为零。 实际上，往返往返的平均数量可以显示为不变。 对于我来说，这看起来比同步模式，在通信延迟的情况下可以打破。
你可以想象得到这样一个系统是不是一件容易的事情。 它需要一个专门的开发工作来实现这一点。 而且一个软件错误仍然可能导致系统崩溃。 如果less于三分之一的节点失败，系统将继续存在。 但是，如果软件中存在一个错误，那么你可能会在超过三分之一的节点上安装这个bug软件。
我在这里看到很多可能的问题。
首先，您已经提供了两个不完善的解决scheme，这两个解决scheme既难以pipe理，又容易出错。
其次，您似乎对如何构build数据服务感到困惑。 这更关心。
我不确定你的参与情况与所描述的环境有什么关系，但是我build议不要做任何事情，并且定义好更好的需求，并且比没有备份（活动或其他）的大量数据库的随机框更好地实现它们。
如果你的担心是实验室库存，那么有很多软件解决这个问题。 如果您正在从供应商那里获得专有的怪异，build立他们的环境要求，find一种方法来访问和保留这些数据，并保证一定的水平。 我向你保证之前已经完成了。
这一切都不会发生在这个论坛上的模糊问题。 如果你感觉不到自己的深度，你应该花几个小时的时间来帮助你。
在给定的环境中，数据的信息来源似乎是很重要的。 真的吗？ 我们不能说。
总会有失败点 – 你需要devise什么是可以接受的。
你必须想出你的系统的约束。 必须有一个单一的数据来源？ 设备可以在离线时使用广告资源吗？ 可以容忍单个服务器故障吗？ 系统能够容许在短时间内以只读模式运行吗？
一旦你有这些限制，你会发现devise系统的方式是由约束产生的。