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