我的客戶製造了一種醫療設備，可以對給定樣本進行各種測量並將結果寫入資料庫。產生的數據量相對較小。
在目前配置中，每個設備都有自己的計算機，並且該計算機運行資料庫伺服器的實例。這些設備未連網。
客戶想要修改設備，以便大約 50 個設備可以連接到區域網路。
這些設備使用各種消耗品，這些消耗品都有批號，一旦使用就無法再使用。測量樣品時，這些批號會寫入資料庫。此要求值得注意，因為在目前配置中，設備無法知道耗材是否已被不同設備使用。在提議的網路配置中，期望每個設備能夠立即存取有關其他設備所使用的消耗品的資訊。
這些設備還需要追蹤測試過程中使用的各種化學品的數量。每瓶化學品都有批號和條碼。當瓶子插入機器時，機器會讀取資料庫以確定瓶子中消耗了多少液體。期望可以將帶有批號的瓶子插入任何機器中，並且機器將能夠準確地評估瓶子中的液體量。
客戶希望獲得關於應使用兩種架構中哪一種的建議：
1.) 每個設備都會像現在一樣將資料寫入自己的本機資料庫。每個設備上都會安裝同步軟體，並且即時進行同步。每個裝置將定期廣播心跳（建議間隔 1 到 5 分鐘），此心跳將包含 CRC 校驗和。網路上的每個裝置都會監聽心跳。如果心跳 CRC 與其自身不同，裝置將啟動同步。同步軟體位於執行測試的軟體外部且獨立於執行測試的軟體。因此，理論上，設備在與網路斷開連接或同步軟體未運行時運行是可能的，但可能性不大。
2.) 每個設備上的資料庫伺服器將被刪除，並將使用資料庫伺服器。
客戶擔心如果使用資料庫伺服器，一旦伺服器發生故障，網路上的所有設備將變得無法使用。使用對等拓樸是否可以有效降低這種風險？換句話說，如果網路上的一個對等點發生故障，所有其他對等點是否一切正常？這兩種方法是否存在任何與資料完整性相關的危險或好處？
編輯回應 iag 和 MikeyB 的答案：
我可以看到我的問題如何留下了歧義的空間，所以這裡又出現了，希望以更有意義的方式表達。
在客戶端-伺服器環境中，伺服器故障是災難性的，因為如果伺服器發生故障，所有客戶端都會關閉。鑑於這種設計特徵，為什麼一些高度關鍵的資訊、庫存、財務和醫療系統採用客戶端-伺服器架構而不是點對點架構？
請注意，我並不是問“如何減輕伺服器故障的風險？”我問“點對點架構是減輕伺服器故障風險的有效方法嗎？”為什麼或為什麼不？網路拓撲是否會影響應用程式的設計？點對點是否會導致資料損壞或結果不明確的可能性？
以下是對等網路拓撲中可能發生的情況的真實範例嗎？
DeviceA、DeviceB 和 DeviceC 是對等網路上的計算機，它們共用一個稱為代理 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
在給定的環境中，資料的單一資訊來源似乎至關重要。真的嗎？我們無法判斷。
總是會有失敗點 - 您需要圍繞可接受的內容進行設計。
您必須提出系統周圍的限制。一定有單一資料來源嗎？設備可以在離線狀態下使用庫存嗎？能否容忍單一伺服器故障？系統能否容忍短時間以唯讀模式運作？
一旦你有了這些限制，你就會發現如何設計系統的過程源自於約束。