依賴複寫來實現高可用性、低延遲或兩者兼而有之的分散式資料庫必須平衡 PACELC 定理所定義的讀取一致性、可用性、延遲和輸送量。 強一致性模型的線性化是資料可編程性的標準。 不過，它會增加寫入延遲時間，因為資料必須跨長距離進行複製並提交。 強一致性也會降低失敗期間的可用性，因為資料無法在每個區域中複寫和提交。 最終一致性提供更高的可用性和更好的效能，但對應用程式進行程式設計更加困難，因為資料可能不會在所有區域中保持一致。
當今市場上大多數分散式 NoSQL 資料庫僅提供強大的最終一致性。 Azure Cosmos DB 提供五個定義完善的等級。 等級從最強到最弱分別為：
如需預設一致性層級的詳細資訊，請參閱設定預設一致性層級或覆寫預設一致性層級。
每個級別都平衡可用性和性能。 下圖顯示一致性層級為頻譜。
一致性層級與 Azure Cosmos DB API
Azure Cosmos DB 支援熱門資料庫的連線通訊協定相容 API，包括 MongoDB、Apache Cassandra、Apache Gremlin 和 Azure 資料表儲存體。 針對 Gremlin 或資料表的 API，Azure Cosmos DB 會使用帳戶上設定的預設一致性層級。 若要瞭解一致性層級對應，請參閱適用於 Apache Cassandra 的 API for Cassandra 一致性對應 和適用於 MongoDB 的 API for MongoDB 一致性對應 。
讀取一致性的範圍
讀取一致性適用於邏輯分割區內的單一讀取作業。 遠端用戶端、預存程序或觸發程式可以發出讀取作業。
設定預設一致性層級
隨時在 Azure Cosmos DB 帳戶上設定預設一致性層級。 您帳戶中設定的預設一致性層級會套用至該帳戶中的所有 Azure Cosmos DB 資料庫和容器。 在預設情況下，對容器或資料庫發出的所有讀取和查詢都會使用指定的一致性層級。 當您變更帳戶層級一致性時，請重新部署應用程式，並進行任何必要的程式碼修改以套用這些變更。 深入瞭解 如何設定預設一致性層級。 您也可以覆蓋特定請求的預設的數據一致性層級。 如需詳細資訊，請參閱 覆寫預設一致性層級 一文。
小提示
覆寫預設一致性層級僅適用於 SDK 用戶端內的讀取。 預設配置為強一致性的帳戶仍會將資料同步寫入和複製到帳戶中的每個區域。 當 SDK 用戶端執行個體或要求使用工作階段或較弱的一致性覆寫此一致性時，會使用單一複本執行讀取。 如需詳細資訊，請參閱 一致性層級和輸送量。
Important
在變更預設一致性層級之後，重新啟動應用程式，以重新建立任何 SDK 執行個體。 此步驟可確保 SDK 使用新的預設一致性層級。
與一致性層級相關聯的保證
Azure Cosmos DB 保證 100% 的讀取要求符合所選一致性層級的一致性保證。 azure/azure-cosmos-tla GitHub 存放庫中提供使用 TLA - 動作時態邏輯 - 規格語言的 Azure Cosmos DB 中五個一致性層級的精確定義。
下列各節將說明五個一致性層級的語意。
強一致性
「強式一致性」模型可提供線性化保證。 線性化意味著請求被一致地並發處理。 保證讀取一定會傳回項目的最新認可版本。 用戶端永遠不會看到未提交或部分的寫入。 保證使用者一律會讀取最新提交的寫入。
下圖顯示了與音符的高度一致性。 將資料寫入至「美國西部 2」區域之後，當您從其他區域讀取資料時，您會取得最新的值：
動態仲裁
在一般情況下，對於具有強一致性的帳戶，當所有區域都確認記錄的複寫時，會被視為已提交寫入。 如果您的帳戶有三個以上的區域，當某些區域速度緩慢或沒有回應時，系統可以降低達到會議法定數所需的區域數目。 這有助於保持強烈的一致性，即使少數區域有問題。 此時，無回應區域會從法定區域集中移除，以保留強式一致性。 只有當它們與其他區域變得一致並符合預期表現時，它們才會重新添加。 地區總數決定了可從仲裁集中剔除的可能地區數量。 例如，在三個或四個區域帳戶中，大多數分別是兩個或三個區域，因此在任何一種情況下都只能移除一個區域。 對於五個區域的帳戶，過半數為三個，因此最多可移除兩個未響應的區域。 這項功能稱為「動態仲裁」，可改善具有三個以上區域的帳戶的寫入可用性和複寫延遲。
Note
當區域從仲裁集中移除作為動態仲裁的一部分時，這些區域將不再能夠提供讀取操作，直到再次加入仲裁為止。
限定過期一致性
對於具有兩個或多個區域的單一區域寫入帳戶，資料會從主要區域複寫到所有次要 (唯讀) 區域。 對於具有兩個或多個區域的跨區域寫入帳戶，資料將從其最初寫入的區域複寫到所有其他可寫區域。 在這兩種情況下，雖然不常見，但偶爾可能會從一個區域到另一個區域出現複寫延遲。
在限定過期一致性中，任何兩個區域之間的資料延遲一律小於指定的數量。 數量可以是「K」版本 (即「更新」) 或「T」 個時間間隔 (以先達到者為準)。 換句話說，當您選擇限定過期時，任何區域中資料的最大「過期」可透過兩種方式來設定：
- 項目的版本數 (K)
- 讀取的時間間隔 (T) 可能落後於寫入
限界陳舊性主要對擁有兩個或更多區域的單一區域寫入帳戶有利。 如果區域中的資料延遲（根據實體分割區決定）超過設定的老化程度，則會對該分割區的寫入操作進行限制，直到延遲回到設定的上限內。
對於單一區域帳戶，限制陳舊性提供與工作階段和最終一致性相同的寫入一致性保証。 使用有限陳舊性時，資料將複寫至單一區域中的本地多數（在四個複本中實施三個複本）。
Important
使用限定過期一致性時，只會跨區域進行過期檢查，而不會在區域內進行。 在指定區域內，無論一致性層級為何，資料一律會複寫至本機多數 （四個複本集中的三個複本）。
使用限定過時時，讀取會從該區域的兩個可用複本讀取，以傳回該區域中可用的最新資料。 由於區域內的寫入總是會同步到本地多數副本（三個是四個副本中的多數），所以查詢任兩個副本可提供該區域內最即時的資料。
Important
使用有界不一致性時，從非主區域讀取可能無法呈現來自所有區域的最新資料。 不過，它們一律會在允許的過時限制內傳回該區域中可用的最新資料。
有界陳舊性最適合使用具有兩個或多個區域的單一區域寫入帳戶來全域分佈的應用程式，其中需要跨區域達到接近強一致性水平。 對於具有兩個或多個區域的多重區域寫入帳戶，應用程式伺服器應該將讀取和寫入導向裝載應用程式伺服器所在的相同區域。 在多寫入帳戶中，有限陳舊性是一種反模式。 此層級會依賴區域間的復寫延遲，但如果資料從其寫入的相同區域讀取，那麼復寫延遲就不成問題。
下圖通過音符來說明有界過期一致性。 將資料寫入至「美國西部 2」區域之後，「美國東部 2」和「澳洲東部」區域會根據設定的延隔時間上限或作業數目上限來讀取寫入的值：
會話一致性
在工作階段一致性層級中，在單一客戶端工作階段內，保證讀取會遵循讀取後寫入和寫入後讀取的保證。 此保證假設單一「編寫器」持續時間或在多個編寫器之間共用工作階段令牌。
像所有比強一致性層級更弱的一致性層級一樣，寫入會被複寫到本地區域的至少三個副本（在四個副本集中），且非同步地複寫至所有其他區域。
每次寫入操作後，客戶端會從伺服器接收到更新的會話令牌。 客戶端會快取權杖，並將其傳送至伺服器，以在指定區域中執行讀取操作。 如果發出讀取作業的副本包含指定代號的資料（或較新的代號），則會返回請求的資料。 如果複本未包含該連線的資料，用戶端會針對區域中的另一個複本重試請求。 如有必要，客戶端會在其他可用區域上重試讀取，直到取得與指定會話權杖相關的資料為止。
Important
在「工作階段一致性」中，用戶端會使用工作階段權杖來保證它永遠不會讀取與較舊工作階段相對應的資料。 如果用戶端使用舊的階段作業記號，但資料庫中有較新的資料可用，則系統會傳回最新版本。 即使使用過時的令牌，您也始終可以獲得最新的數據。 會話權杖用作最低版本屏障，而不是用來指向要從資料庫擷取之資料的特定（可能是歷史的）版本。
Azure Cosmos DB 中的工作階段權杖是專屬於特定分割區的，這表示它們只與一個分割區相關聯。 為了確保能夠讀取您寫入的內容，請使用上次為相關項目產生的工作階段權杖。
如果用戶端未針對實體分割區進行寫入操作，則用戶端的快取中不會包含會話權杖，且對該實體分割區的讀取行為將呈現最終一致性。 同樣地，如果重新建立用戶端，也會重新建立其工作階段權杖的快取。 在這裡，讀取操作也會遵循與最終一致性相同的行為，直到後續的寫入操作重建用戶端工作階段的權杖快取為止。
Important
如果會話權杖從一個用戶端執行個體傳遞至另一個用戶端執行個體，則不應修改權杖的內容。
工作階段一致性是單一區域和全球分散式應用程式最廣泛使用的一致性層級。 其提供與最終一致性相當的寫入延遲、可用性和讀取輸送量。 工作階段一致性還提供了符合應用程式在使用者情境中操作需求的一致性保證。 下圖以音符說明工作階段一致性。 「美國西部 2 寫入器」和「美國東部 2 讀取器」會使用相同的工作階段 (工作階段 A)，以便同時讀取相同的資料。 雖然「澳洲東部」區域使用「工作階段 B」，但稍後會以與寫入相同的順序接收資料。
動畫顯示單一用戶端工作階段內同步的音符，以演示工作階段一致性層級。
一致前置詞一致性
就像所有弱於強一致性層級的情況一樣，寫入資料會在本地區域的四個複本集中至少複寫至三個複本，並以非同步方式複寫至所有其他區域。
在一致性前置的情況下，單一文件寫入的更新具有最終一致性。
在交易中進行的批次更新，回傳時會與所屬的認可交易保持一致。 多個文件交易中的寫入操作始終一起可見。
假設在交易 T1 和 T2 中，先後對文件 Doc1 和文件 Doc2 進行兩個具有全部或無操作特性的寫入作業。 當用戶端在任何複本中執行讀取時，使用者會看到「Doc1 v1 和 Doc2 v1」或「Doc1 v2 和 Doc2 v2」，如果複本延遲，則不會看到任何文件，但不會看到相同的讀取或查詢作業的「Doc1 v1 和 Doc2 v2」或「Doc1 v2 和 Doc2 v1」。
下圖以音符說明一致前置詞一致性。 在所有區域中，讀取永遠不會看到交易寫入批次未按順序的寫入：
最終一致性
像所有比強一致性層級更弱的一致性層級一樣，寫入會被複寫到本地區域的至少三個副本（在四個副本集中），且非同步地複寫至所有其他區域。
在最終一致性中，用戶端會針對指定區域中四個複本中的任何一個發出讀取要求。 此複本可能會延遲，而且可能會傳回過時或沒有資料。
最終一致性是最弱的一致性形式，因為用戶端讀取的值可能比過去讀取的值更早。 最終一致性是應用程式不需要任何排序保證的理想選擇。 範例包括轉發、按讚或非線程評論的計數。 下圖以音符說明最終一致性。
一致性保證應用
在實踐中，您通常可能會獲得更強的一致性保證。 讀取操作的一致性保證對應到您所要求的資料庫狀態的新鮮度和排序。 讀取一致性與寫入和更新作業的排序和傳播有關。
如果在資料庫上沒有寫入作業，則具有 最終、會話 或 一致前置詞 一致性層級的讀取作業可能會產生與強一致性的讀取作業相同的結果。
如果您的帳戶設定了強一致性以外的一致性層級，您可以找出用戶端可能為您的工作負載獲得強大且一致讀取的機率。 通過查看 機率邊界陳舊性（PBS） 指標來找出此概率。 此計量會在 Azure 入口網站中公開。 如需詳細資訊，請參閱 機率有限過期監控指標（PBS）。
概率界限的陳舊性顯示了最終一致性的最終性。 此計量可讓您深入瞭解您獲得比 Azure Cosmos DB 帳戶上目前設定的一致性層級更強的一致性層級的頻率。 換句話說，您可以看到針對寫入和讀取區域的組合取得一致性讀取的機率 (以毫秒來測量)。
一致性層級和延遲
在第 99 個百分位數處，所有一致性層級的讀取延遲保證小於 10 毫秒。 第 50 個百分位數的平均讀取延遲通常為 4 毫秒或更短。
所有一致性層級的寫入延遲保證在第 99 個百分位數小於 10 毫秒。 第 50 個百分位數的平均寫入延遲通常為 5 毫秒或更短。 跨越數個區域且具有強一致性的 Azure Cosmos DB 帳戶是此保證的例外狀況。
寫入延遲和強式一致性
針對使用多個區域設定強式一致性的 Azure Cosmos DB 帳戶，寫入延遲相當於任兩個最遠區域之間來回行程時間 (RTT) 的兩倍，再加上第 99 個百分位數的 10 毫秒。 區域之間的高網路 RTT 會增加 Azure Cosmos DB 請求延遲，因為只有在確保作業在帳戶中所有區域皆已認可的情況下，強一致性才會完成作業。
確切的 RTT 延遲取決於光速距離和 Azure 網路拓撲。 Azure 網路不會提供 Azure 區域之間 RTT 的延遲服務等級協定 （SLA），但會發佈 Azure 網路來回延遲統計資料。 您 Azure Cosmos DB 帳戶的複寫延遲會顯示在 Azure 入口網站中。 移至 [計量] 區段，然後選取 [ 一致性] 選項，以使用 Azure 入口網站。 使用 Azure 入口網站，您可以監視與您 Azure Cosmos DB 帳戶相關聯的各個區域之間的複寫延遲。
Important
由於寫入延遲較高，地區跨越超過 5,000 英里（8,000 公里）的帳戶預設不允許強一致性。 若要啟用此功能，請連絡支援人員。
一致性層級和輸送量
對於強一致性和有界過時性，會針對四個複本集（少數法定人數）中的兩個複本進行讀取，以確保一致性保證。 工作階段、一致前置詞和最終一致性使用單一複本讀取。 因此，對於相同數量的要求單位，強一致性和限制過期的一致性層級的讀取吞吐量是其他層級的一半。
對於指定類型的寫入作業（例如插入、取代、合併更新或刪除），所有一致性層級的要求單位寫入輸送量皆相同。 為了達到強一致性，必須在每個區域（全域多數）中提交變更，而相較於所有其他一致性層級，則使用本地多數（四個複本中的三個）。
| 一致性層級 | 仲裁讀取 | 過半寫入 |
|---|---|---|
| 強 | 本地小眾 | 全域多數 |
| 限定過期 | 本地小眾 | 區域多數 |
| 會議 | 單一複本 (使用工作階段令牌) | 區域多數 |
| 一致前置詞 | 單一複本 | 區域多數 |
| 最終 | 單一複本 | 區域多數 |
Note
本機小量讀取的 RU 成本是較弱一致性層級的兩倍，因為讀取是從兩個副本進行，以確保強一致性和有限過期一致性層級的一致性保證。
一致性層級和資料持久性
在全球分散式資料庫環境中，一致性層級會直接影響全區域中斷期間的資料持久性。 制定商務持續性計劃時，請瞭解應用程式在從中斷事件復原期間可以容忍遺失的最近資料更新期間上限。 可能遺失的更新時段稱為 復原點目標 （RPO）。
下表顯示全區域中斷期間一致性模型與資料持久性之間的關係。
| 區域 | 複寫模式 | 一致性層級 | 復原點目標 (RPO) |
|---|---|---|---|
| 1 | 單一或多個寫入區域 | 任何一致性層級 | < 240 分鐘 |
| >1 | 單一寫入區域 | 工作階段、一致前綴、最終一致性 | < 15 分鐘 |
| >1 | 單一寫入區域 | 有界陳舊性 | K & T |
| >1 | 單一寫入區域 | 強大 | 0 |
| >1 | 多重寫入區域 | 工作階段、一致前綴、最終一致性 | < 15 分鐘 |
| >1 | 多重寫入區域 | 有界陳舊性 | K & T |
K = 項目的 K 個版本 （更新） 數目。
T = 自上次更新以來的時間間隔 T 。
對於單一區域帳戶， K 和 T 的最小值為 10 次寫入操作或 5 秒。 對於多區域帳戶， K 和 T 的最小值為 100,000 次寫入操作或 300 秒。 此值會定義在使用有限陳舊性時，資料的最小復原點目標（RPO）。
強式一致性和多個寫入區域
具有多個寫入區域的 Azure Cosmos DB 帳戶無法使用強一致性，因為分散式系統無法提供零的復原點目標 （RPO） 和零的復原時間目標 （RTO）。 此外，多個寫入區域的強一致性不會改善寫入延遲，因為寫入必須在帳戶中的所有區域進行複寫並提交。 此設定會導致與單一寫入區域帳戶相同的寫入延遲。
閱讀更多內容
若要深入了解一致性的概念，請閱讀下列文章：
- Azure Cosmos DB 所提供五個一致性層級的高階 TLA⁺ 規格
- 道格·特里（Doug Terry）以棒球（視頻）解釋數據複製的一致性
- 通過棒球解釋的複製數據一致性（白皮書），道格·特里 （Doug Terry）
- 弱一致性複寫資料的會話保證
- 現代分散式資料庫系統設計中的一致性權衡：CAP 只是故事的一部分
- 概率有限的過期性（PBS）用於實際的部分仲裁
- 最終一致 - 重新審視