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