本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 應用程式和工作負載考量事項
<a name="rds-proxy-best-practices.workload-considerations"></a>

**Topics**
+ [多租戶和多使用者環境](#rds-proxy-best-practices.multi-tenant)
+ [提供多個應用程式或軟體堆疊的資料庫](#rds-proxy-best-practices.multiple-applications)
+ [搭配 RDS Proxy 使用應用程式層級集區和進階驅動程式](#rds-proxy-best-practices.application-pooling)

## 多租戶和多使用者環境
<a name="rds-proxy-best-practices.multi-tenant"></a>

 在可擴展性和改善連線管理方面，使用 RDS Proxy 的好處取決於其執行連線集區的能力，以及更大規模的連線多工能力。連線集區可減少與開啟和關閉連線相關聯的額外負荷。連線多工可讓代理在交易之後重複使用後端資料庫連線。如需詳細資訊，請參閱[RDS Proxy 概念和術語](rds-proxy.howitworks.md)。

 當無法多工連線時，代理會回復為稱為*連線鎖定*的行為。釘選是用戶端被迫在其整個工作階段使用相同基礎代理連線的情況。代理連線會保留給該用戶端，因此無法供其他用戶端重複使用。換言之，鎖定會在用戶端代理連線和代理資料庫連線之間建立獨佔的 1：1 關聯。在 RDS Proxy 主要用於可擴展性和效率的所有案例中，避免鎖定非常重要。如需最新的鎖定行為，請參閱 [避免鎖定 RDS Proxy](rds-proxy-pinning.md)。

 一般而言，當連線具有相同的狀態時，可以多工連線。當連線包含自訂工作階段特定的狀態資訊時，就無法多工連線。定義工作階段狀態的其中一個層面是與連線相關聯的資料庫使用者名稱。當您以「user\_A」連接到代理時，代理還需要以「user\_A」開啟後端資料庫連線。代理可能會為以 "user\_A" 身分登入的其他用戶端集區和重複使用此後端連線，但不適用於使用不同使用者名稱的用戶端。

 此行為可以大幅降低具有大量唯一資料庫帳戶的多使用者環境中的集區和多工效率。在使用資料庫層級或結構描述層級多租用戶的架構中尤其如此。如果資料庫包含數千個結構描述 （每個租用戶一個結構描述），且每個租用戶連接到具有不同使用者名稱的資料庫，則連線集區會分割成使用者特定的微型集區，從而降低整體效率。

 此外，資料庫引擎特有的層面可能會進一步影響集區效率和代理多工連線的能力：

1.  在 Amazon RDS 和 Aurora PostgreSQL 中，多租用戶通常透過每個租用戶使用一個資料庫來實作。不過，在 PostgreSQL 中，連線是資料庫特定的：針對一個資料庫開啟的連線無法存取來自其他資料庫的資料。因此，資料庫層級多租用可降低代理層級的集區和多工效率。如果工作負載使用結構描述層級多租戶，且用戶端工作階段使用自訂 ，則此考量也適用`search_path`。不過，如果所有工作階段都使用預設搜尋路徑，並使用完整名稱 (`schema_name.table_name`) 參考資料表，則可以多工這些工作階段。

1.  在 Amazon RDS 和 Aurora MySQL 中，術語「資料庫」和「結構描述」是同義詞。多租用戶通常透過每個租用戶使用一個結構描述來實作，在 MySQL 中與每個租用戶一個資料庫相同。連線會針對 MySQL 伺服器整體開啟，且不會繫結至結構描述。如果應用程式使用結構描述層級的多租用戶，即使這些連線需要存取不同結構描述中的資料，使用相同資料庫使用者名稱的用戶端仍可進行連線多工。如果在應用程式層級完成租用戶分離，而不是為每個租用戶使用不同的資料庫帳戶，多工將最有效。

 在多結構描述環境中，多工效率取決於您如何參考資料表名稱：
+  對於使用工作階段變數 (`SET search_path ...`在 PostgreSQL 和 MySQL `USE schema;`中） 選擇目前結構描述，然後在查詢 （例如 `SELECT ... FROM table_name`) 中使用不合格資料表名稱的用戶端，連線多工只能在使用相同結構描述或相同搜尋路徑的用戶端之間運作。
+  對於不修改工作階段狀態以定義目前結構描述，而是在 SQL 陳述式 （例如 `SELECT ... FROM schema_name.table_name`) 中使用完整資料表名稱的用戶端，多工不會受到類似限制。

## 提供多個應用程式或軟體堆疊的資料庫
<a name="rds-proxy-best-practices.multiple-applications"></a>

 如上節所述，某些連線狀態特性不會導致鎖定，但仍會降低代理重複使用不同用戶端之間連線的能力。與 MySQL 目標搭配使用時，RDS Proxy 會追蹤許多設定工作階段狀態的陳述式和工作階段變數，例如字元集、時區和定序設定。當用戶端使用追蹤的陳述式或變數來設定工作階段設定時，代理連線只能針對這些設定具有相同值的其他用戶端重複使用。

 因此，某些應用程式和驅動程式行為可能會降低您在代理內重複使用連線的能力。例如，您可以允許不同的應用程式使用相同的使用者名稱連線到資料庫，假設代理可以在這些應用程式之間重複使用 和多工連線。不過，如果一個應用程式啟動與時區 A (`SET time_zone = ?`) 的連線，而另一個應用程式使用時區 B，則連線可在應用程式內重複使用，但不能在應用程式之間重複使用。這會導致連線集區的分段，對集區和多工的有效性產生負面影響。

 如需詳細資訊，請參閱[RDS Proxy 針對 RDS for MariaDB 和 RDS for MySQL 資料庫追蹤哪些項目](rds-proxy-pinning.md#rds-proxy-pinning.mysql-tracked-vars)。MySQL 以外的資料庫目標目前不支援工作階段狀態追蹤。

 如需管理工作階段狀態[組態準則](rds-proxy-best-practices.configuration.md)以避免連線鎖定的組態準則和最佳實務，請參閱 。

## 搭配 RDS Proxy 使用應用程式層級集區和進階驅動程式
<a name="rds-proxy-best-practices.application-pooling"></a>

 在應用程式本身未使用連線集區的情況下，RDS Proxy 有助於改善可擴展性和連線效率。同時，許多驅動程式和架構也包含集區功能。您也可以使用進階包裝函式或驅動程式，在驅動程式層級實作代理的某些功能。

 使用應用程式層級集區和其他連線處理改進本質上不會與使用 RDS Proxy 衝突，也不會否定其優點。例如，您可能在應用程式容器中使用連線集區，但容器數量足夠大，因此您在不使用代理的情況下仍會用完資料庫連線限制。搭配應用程式層級集區和其他連線相關功能使用 RDS Proxy 時，請檢閱並了解進階連線處理功能存在於應用程式層級的原因。決定哪些功能值得保留 （或無害），以及哪些功能可能會重疊或干擾代理行為。例如：

1.  內建於驅動程式和架構的集區功能可能很有用，即使它們似乎與 RDS Proxy 功能重疊。如果應用程式層級集區除了代理提供的優點之外，還改善了本機連線效率，您可以保留它。

1.  與容錯移轉處理相關的功能可能會干擾 RDS Proxy 邏輯，或提高整體堆疊複雜性，而不會帶來好處。例如，如果您的應用程式正在主動追蹤 Aurora 叢集的拓撲，以避免 DNS 相關的容錯移轉延遲，則不再需要使用 RDS Proxy 執行此操作。保留此拓撲追蹤邏輯可能會導致不良行為，例如略過代理並直接連線至個別資料庫執行個體的應用程式執行緒。在此案例中，您可以停用應用程式層級追蹤邏輯，並讓 RDS Proxy 為您抽象化叢集拓撲。

1.  連線集區程式庫可能會使用在理論上似乎有益的狀態管理功能，但會干擾代理行為。其中一個範例是 PostgreSQL 程式庫，呼叫`DISCARD ALL`查詢來重設借用之間的連線狀態。重設連線似乎有助於集區和多工，但會干擾 Amazon RDS Proxy 的內部工作階段狀態管理。使用 時`DISCARD`，代理會在發行時鎖定您的用戶端連線，進而降低多工效率。

 對於您保留的任何應用程式層級連線處理元件，請確保其組態不會干擾 Amazon RDS Proxy 使用的連線處理邏輯。例如：
+  對齊堆疊所有層的集區大小。如果應用程式層級集區過大 （或代理集區過小），應用程式可能會嘗試開啟未設定代理處理的連線。這些連線可能遇到最佳延遲和最差拒絕錯誤。
+  對齊逾時設定以減少流失，並避免混淆連線行為。如果應用程式集區保持連線運作 300 秒，但代理設定為在 60 秒後關閉連線，則應用程式將看到過早連線關閉，而不是預期的行為。

 其中一些架構決策和組態選擇可能需要測試和實驗。在具有多層集區和連線管理的環境中，不總是可以準確預測應用程式行為。

 如需常見組態準則[組態準則](rds-proxy-best-practices.configuration.md)，請參閱 。