Azure Cosmos DB SQL SDK 連線模式

  • 發行項

適用於：NoSQL

用戶端連線到 Azure Cosmos DB 的方式，對於效能有重大影響 (尤其對觀察到的用戶端延遲而言)。 Azure Cosmos DB 提供透過 HTTPS 的簡單且開放 RESTful 程式設計模型 (稱為閘道模式)。 此外，還會提供有效率的 TCP 通訊協定，在其通訊模型中也屬於 RESTful，並使用 TLS 來進行初始驗證和加密流量 (稱為直接模式)。

可用的連線模式

兩種可用的連線模式如下：

  • 閘道模式

    所有 SDK 平台都支援閘道模式。 如果您的應用程式在有嚴格防火牆限制的公司網路中執行，則閘道模式會是最佳的選擇，因為它會使用標準 HTTPS 連接埠與單一 DNS 端點。 不過，對於效能的影響是每次在 Azure Cosmos DB 中讀取或寫入資料時，閘道模式都會涉及額外的網路躍點。 當應用程式執行所在的環境所擁有的通訊端連線數量有限時，也建議您使用閘道連線模式。

    當您在 Azure Functions 中使用 SDK 時 (特別是在使用量方案中)，請注意目前的連線限制。

  • 直接模式

    直接模式使用 TLS 進行初始驗證和加密流量，以支援透過 TCP 通訊協定進行連線，並提供更佳的效能，因為網路躍點較少。 應用程式會直接連線到後端複本。 目前只有 .NET 和 Java SDK 平台可支援直接模式。

The Azure Cosmos DB connectivity modes

這些連線模式基本上會決定資料平面要求 (會記載讀取和寫入) 會從用戶端機器提取到 Azure Cosmos DB 後端分割區的路由。 直接模式是達到最佳效能的慣用選項，可讓您的用戶端直接對 Azure Cosmos DB 後端的資料分割區開啟 TCP 連線，而且能在無需中繼的情況下直接傳送要求。 相反地，在閘道模式中，用戶端所提出的要求會路由傳送至 Azure Cosmos DB 前端的所謂「閘道」伺服器，進而將您的要求傳送到 Azure Cosmos DB 後端中的適當磁碟分割區。

服務連接埠範圍

在使用直接模式時，您必須確定您的用戶端可以存取 10000 到 20000 之間的連接埠範圍，因為 Azure Cosmos DB 使用動態 TCP 連接埠。 這是對網路閘道連接埠的補充。 在私人端點上使用直接模式時，Azure Cosmos DB 可能會使用從 0 到 65535 的完整 TCP 連接埠範圍。 如果您的用戶端上未開啟這些連接埠，而您又嘗試使用 TCP 通訊協定，便可能會收到「503 服務無法使用」的錯誤。

下表顯示各種 API 可用的連線模式摘要，以及每個 API 所使用的服務連接埠：

連線模式 支援的通訊協定 支援的 SDK API/服務連接埠
閘道 HTTPS 所有 SDK SQL (443)、MongoDB (10255)、Table (443)、Cassandra (10350)、Graph (443)
直接 TCP (透過 TLS 加密) .NET SDK Java SDK 使用公用/服務端點時：10000 到 20000 範圍中的連接埠
使用私人端點時：0 到 65535 範圍中的連接埠

直接模式連線架構

如簡介中所述，直接模式用戶端會透過 TCP 通訊協定直接連線到後端節點。 每個後端節點都代表屬於實體分割區的複本集中的複本。

路由

當直接模式上的 Azure Cosmos DB SDK 正在執行作業時，其必須解析要連線的後端複本。 第一個步驟是知道作業應該移至哪個實體分割區，而針對該作業，SDK 會取得容器資訊，其中包含閘道節點的資料分割索引鍵定義。 其也需要包含複本 TCP 位址的路由資訊。 路由資訊也可以從閘道節點取得，而且兩者都被視為控制平面中繼資料。 SDK 取得路由資訊後，就可以繼續開啟屬於目標實體分割區複本的 TCP 連線，並執行作業。

每個複本集都包含一個主要複本和三個次要複本。 寫入作業一律會路由傳送至主要複本節點，而讀取作業可以從主要或次要節點提供服務。

Diagram that shows how S D Ks in direct mode fetch the container and routing information from Gateway before opening the T C P connections to the backend nodes

因為容器和路由資訊不會經常變更，所以會在 SDK 本機快取這些資訊，以利後續作業。 已建立的 TCP 連線也會跨作業重複使用。 除非透過 SDK 選項進行其他設定，否則在 SDK 執行個體的存留期內，會永久維護連線。

如同任何分散式架構，保留複本的電腦可能會進行升級或維護。 服務會確保複本集維持一致性，但任何複本的移動都會導致現有的 TCP 位址產生變更。 在這些情況下，SDK 必須重新整理路由資訊，並透過新的閘道要求重新連線到新的位址。 這些事件不應影響整體的 P99 SLA。

連線數量

每個實體分割區都有四個複本的複本集，為了提供最佳的效能，SDK 最終會開啟與混合寫入和讀取作業的工作負載的所有複本連線。 並行作業會跨現有連線進行負載平衡，以利用每個複本所提供的輸送量。

有兩個因素決定 SDK 將開啟的 TCP 連線數目：

  • 實體分割區數目

    在穩定狀態下，SDK 在每個實體分割區的每個複本會有一個連線。 容器中實體分割區的數目愈大，開啟的連線數目就愈大。 由於作業會跨不同的分割區路由傳送，因此會視需要建立連線。 然後，連線的平均數目會是實體分割區的數目乘以四。

  • 並行要求的數量

    每個已建立的連線都可以提供可設定的並行作業數目。 如果並行作業的數量超過此閾值，將會開啟新的連線來提供服務，而且對於實體分割區而言，開啟的連線數目可能會超過穩定狀態數目。 此行為預期適用於可能在其作業量尖峰的工作負載。 對於 .NET SDK，此設定是由 CosmosClientOptions.MaxRequestsPerTcpConnection 設定，而對於 Java SDK，您可以使用 DirectConnectionConfig.setMaxRequestsPerConnection 自訂設定。

依預設會永久維護連線，以受益於未來作業的效能 (開啟連線時，會有計算額外負荷)。 在某些情況下，您可能會想要關閉一段時間未使用的連線，以便瞭解這是否會影響未來的作業。 對於 .NET SDK，此設定是由 CosmosClientOptions.IdleTcpConnectionTimeout 設定，而對於 Java SDK，您可以使用 DirectConnectionConfig.setIdleConnectionTimeout 自訂設定。 不建議將這些設定設為低值，因為這可能會導致連線經常關閉，並影響整體效能。

語言特定的實作詳細資料

如需語言的進一步實作詳細資料，請參閱：

下一步

針對特定 SDK 平台的效能最佳化：