分割區容錯性的權衡

設定一致性和分割區容錯優先順序的資料庫通常採用主要-次要設定，其中系統中許多節點的其中一個節點被選為主導者。 只有領導者才會核准資料寫入，而所有次要節點會從領導者抄寫資料以處理讀取。 如果主要節點失去與網路的連線，或無法與許多系統節點通訊，則剩餘的節點會選取新的主要節點。 此選取處理程序在系統之間有所不同，並且可能是 重大問題的來源。

IBM Cloudant 會透過採用主要-主要設定來設定可用性和分割區容錯的優先順序，以便每個節點都可以接受對其部分資料的寫入和讀取。 多個節點包含資料每一部分的副本。 每一個節點都會利用其他節點複製資料。 如果有某個節點變成無法存取，則其他節點可在網路恢復時取代其位置。 如此一來，即使任意節點失敗，系統仍會及時傳回您的資料，並維護 最終一致性。 解除絕對一致性之優先順序的取捨為，所有節點都需要時間才能看到相同的資料。 因此，當新資料在系統中傳播時，部分回應可能包括舊資料。

變更方法

維護一致的資料視圖是合乎邏輯且易於瞭解的，因為關聯式資料庫會替您完成此工作。 期望與資料庫系統互動的 Web 型服務以此方式運作。 但這種期望並不意味著他們會這樣做。 一致性不是既定的，需要一些工作來改變方法。

事實上，多數企業雲端服務不一定需要一致性。 大型且大量使用的系統，會讓其系統的某個部分有很高的失敗機率。 根據設定可用性及最終一致性優先順序之需求而設計的資料庫，更適合用來讓您的應用程式保持在線上。 應用程式資料的一致性可在事後處理。

企業中的應用程式可用性與一致性

看看熱門的 Web 型服務，人們已經期待高可用性，很高興將此可用性交易為最終一致的資料，但往往不知道他們會這麼做。

許多應用程式為了可用性而誤導了使用者。 請考量 ATM: 不一致的銀行資料就是為何仍有可能在未意識到的情況下透支貨幣。 如果網路中的每個節點都必須中止並記錄此數字，然後作業繼續進行，則在整個銀行系統中呈現一致的帳戶餘額視圖是不現實的。 更好的選擇是讓系統具有高可用性。

銀行業已在 1980 年代就瞭解這一點，但是許多 IT 組織仍會擔心為了可用性而犧牲一致性。 想一想您的銷售團隊在無法存取其 CRM 應用程式時而撥打支援電話的次數。 現在，考量他們是否甚至注意到更新資料庫需要幾秒的時間，才能在整個應用程式中傳播資料。

可用性勝過一致性，超過您可能的預期。 線上購物車系統、HTTP 快取及 DNS 就是其中的幾個範例。 組織必須考量運作中斷時間的成本，例如使用者挫敗、生產力損失，以及錯過機會。

從理論到實作

處理高可用性對雲端應用程式至關重要。 否則，在您進行調整時，廣域資料庫一致性仍會是主要瓶頸。 高可用性應用程式需要持續聯絡其資料，即使該資料不是最新的。 這就是最終一致性的概念，並沒有什麼可怕的。 有時候，大規模地提供答案，總比完全不提供答案來得好。

資料庫系統以不同方式隱藏可用性與一致性的複雜性，但它們一律存在。 IBM Cloudant、CouchDB 及其他 NoSQL 資料庫團隊認為最佳原則需要開發人員在設計處理程序早期解決這些複雜性。 事先做好艱辛的工作，可以減少出人意料的事件，因為應用程式從第一天起就要做好擴充的準備。