PolarDB支持基于連接數負載均衡和基于活躍請求數負載均衡兩種負載均衡策略，來保證多個只讀節點間的負載均衡。
負載均衡策略
PolarDB只讀模式的集群地址支持基于連接數負載均衡和基于活躍請求數負載均衡兩種負載均衡策略；可讀可寫（自動讀寫分離）模式的集群地址僅支持基于活躍請求數負載均衡的策略。
負載均衡策略名稱 | 差異點 | 相同點 |
基于連接數負載均衡 說明 讀請求將在集群地址內的多個只讀節點中按照連接數自動調度，來保證多個只讀節點間的負載均衡。 |
| 對于只讀模式的集群地址，無論采用哪種負載均衡策略，任何請求都不會被轉發到主節點。 |
基于活躍請求數負載均衡 說明 讀請求將在集群地址內的多個只讀節點中按照活躍請求數自動調度，來保證多個只讀節點間的負載均衡。 |
|
主庫是否接受讀
主庫是否接受讀選擇否后，普通的讀請求將不再發往主節點。而事務內，一致性要求的讀請求仍會被發往主節點，以保證業務需求。另外，當所有只讀節點出現故障后，讀請求也會發往主節點。如果業務對一致性的要求較低，可以通過設置一致性級別為最終一致性來減少讀請求到主節點，也可以通過事務拆分功能來減少真正事務前的讀請求發往主節點。廣播的請求（例如SET或PREPARE）仍會被發往主節點。
僅當讀寫模式為可讀可寫（自動讀寫分離）時，支持設置主庫是否接受讀。關于如何修改主庫是否接受讀設置，具體操作請參見配置數據庫代理。
如果您的數據庫代理版本為1.x.x或為2.5.1及以上，主庫是否接受讀配置更改后會立即生效。
如果您的數據庫代理版本為2.x.x且為2.5.1之前的版本，主庫是否接受讀配置更改后，如果業務側使用的是長連接，需要重新建立連接才能生效；如果業務側使用的是短連接，會立即生效。
事務拆分
當使用PolarDB可讀可寫模式集群地址時，讀寫請求會由數據庫代理（Proxy）分發到主節點和只讀節點。為了保證一個會話連接中事務讀寫一致性，代理會將這個會話中所有在事務中的請求都發送到主節點。例如，某些數據庫客戶端驅動（如JDBC）默認將請求封裝在事務中，因此應用的請求都會被發送到主節點，導致主節點壓力大，而只讀節點幾乎沒有壓力，如下圖所示：
為了解決上述問題，PolarDB在讀已提交（Read Committed）的事務隔離級別下提供了事務拆分功能，旨在保證業務中讀寫一致性的前提下，將事務中讀請求發送到只讀節點，以減輕主節點的壓力。您不需要改動應用的代碼或配置就可以將事務中的讀壓力從主節點轉移到只讀節點，從而提高主節點的穩定性。開啟事務拆分能力的詳細操作步驟請參見配置數據庫代理。
PolarDB MySQL版提供了事務寫前讀拆分（默認值，即原來的事務拆分功能）和事務全（寫前讀、寫后讀）拆分兩個級別的事務拆分能力：
事務寫前讀拆分
Proxy會將事務中第一個寫請求前的讀請求發送到只讀節點，從而減輕主節點的負載。
全（寫前讀、寫后讀）拆分
寫前讀拆分對于事務中寫之后的讀仍然會路由到主節點，這種情況下負載仍然不太均衡，為徹底解決事務帶來的負載均衡問題，PolarDB MySQL版推出事務全拆分能力，可以使得事務中的讀操作都路由到只讀節點且獲得正確的結果。進一步減輕主節點的壓力。
事務寫后讀被路由到只讀節點的前提是當前的只讀節點已同步事務之前的寫操作的數據，如果用戶配置了會話一致性，那么在路由寫后讀時會先判斷當前Session的只讀節點是否已經同步之前的寫，如果已同步就會路由過去，否則會直接路由到主節點。同樣地，如果用戶配置了全局一致性，那么在路由寫后讀時會先判斷當前所有Session的事務是否都已經同步到只讀節點，如果已同步就會路由過去，否則會直接路由到主節點。事務全拆分不支持配置為最終一致性。
版本和使用限制
如需使用事務全拆分能力，則PolarDB MySQL版集群需要滿足：
PolarDB MySQL版5.6版本，且修訂版本為5.6.1.0.29及以上。
PolarDB MySQL版5.7版本，且修訂版本為5.7.1.0.9及以上。
PolarDB MySQL版8.0.1版本，且修訂版本為8.0.1.1.18及以上。
PolarDB MySQL版8.0.2版本，無修訂版本限制。
需要讓內核參數
loose_query_cache_type設置為OFF（PolarDB MySQL版5.6、5.7和8.0.1版本參數默認值為OFF，8.0.2版本默認為ON，該參數設置變更需要重啟PolarDB）。
僅對讀已提交（Read Committed）事務隔離級別的會話支持事務拆分功能，并且該功能默認開啟。
受讀寫一致性的約束，如果只讀節點的一致性不滿足要求，則讀請求不會路由至只讀節點。
若您的數據庫代理版本為2.4.14之前的版本，則只支持事務寫前讀拆分不支持事務全拆分能力。
若您的數據庫代理版本為2.4.14及之后的版本，且事務拆分配置為事務全拆分，如果業務側使用的是長連接，則需要重新建立連接才能生效。如果業務側使用的是短連接，會立即生效。
關閉事務拆分
當事務拆分關閉后，事務內的所有請求都路由到主節點。
基于權重的動態負載均衡
當前PolarDB MySQL版代理默認的負載均衡策略是優先選擇最小活躍（并發）請求數的節點去路由請求。該策略基本可以使得流量根據后端節點的負載均衡的路由到不同的后端節點上，即使后端節點的規格不一致，也能較好的進行負載均衡。但是線上客戶的業務負載多種多樣，用戶對于流量的分發需求也不盡相同。
為了更好地滿足客戶的需求，PolarDB MySQL版引入了基于權重的動態負載均衡功能，您可以為每個節點配置不同的權重，在后續的路由過程中，權重和并發請求數會同時作為參考標準去動態的調整最終的路由決策。目前僅支持基于以下2個維度配置權重：
全局DB維度
該配置會對所有的地址生效；
地址（endpoint）維度
地址維度的權重僅會對該地址的負載均衡生效，并覆蓋DB維度。即用戶先配置了一個DB維度的權重，又為某個地址單獨配置了權重，則這個地址的負載均衡以配置到該地址維度為準；
注意事項
該功能要求數據庫代理的版本為2.8.3或以上。
由于同時考慮當前節點負載和用戶自定義權重，所以整體的比例可能和用戶自定義比例有一些偏差，隨著時間推移，會逐步地向自定義比例靠近。
Serverless實例不支持地址（endpoint）維度權重設置。
實現原理
在路由請求過程中，各個節點最終的權重是根據用戶配置的權重和節點當前的并發請求數進行動態調整。所采用的公式簡化后如下：
動態權重=自定義配置的權重/并發請求數
動態權重越大，節點的優先級越高。動態權重負載策略提供了一個比較靈活的路由方式。在實際使用時，業務流量會根據用戶所配置的權重逐步變化（相比完全按照權重輪詢會需要更多的時間）。
操作步驟
初始時每個后端節點的權重默認相同，即均為1。
權重的可配置范圍為0~100。
當權重為0時，正常情況下請求不會再路由到該節點，只會在其他節點都不可用時才會選擇該節點。
如果集群中只存在一個只讀列存節點，則其權重可以忽略。如果集群中存在多個只讀列存節點，則列存請求會根據列存節點的權重進行負載均衡。
配置全局DB維度權重
登錄PolarDB控制臺。
在左上角，選擇集群所在地域。
找到目標集群，單擊集群ID。
在基本信息頁面的數據庫代理企業通用版或數據庫代理企業獨享版區域，單擊數據庫代理服務配置。
在數據庫代理服務配置對話框中，根據業務需求為每個節點配置不同的權重。
配置完成后，單擊確定。
配置地址維度權重
登錄PolarDB控制臺。
在左上角，選擇集群所在地域。
找到目標集群，單擊集群ID。
在基本信息頁面的數據庫代理企業通用版或數據庫代理企業獨享版區域，單擊集群地址或自定義地址右上角的配置。
在編輯地址配置頁面的服務節點區域，將自定義節點權重選擇開啟，并為節點設置權重。
設置完成后，單擊確定。
測試數據
以下展示了配置節點權重后的實際測試數據。
測試使用的三個節點的權重配置比例為1:2:3（RW節點為1），可以看到壓測結果符合預期（使用Sysbench oltp_read_only測試集）。
pi-bp1d1mtcobuzv****和pcbp14vvpolardbma23957****兩個節點為內部節點，不參與路由，指標無需考慮。
按需建連
背景信息
對于基于活躍請求數負載均衡的Endpoint，默認的建聯方式為全建聯。即一個客戶端會話通過代理建連后，代理會與該地址內的所有數據庫節點都建立一個會話（連接），即1:N的連接關系。并且這個會話的普通讀請求會按照當前數據庫的活躍負載而路由到各個數據庫執行，廣播請求（SET語句等）會路由到所有的數據庫。在數據庫數目較多時，整體效率會因為建聯和廣播明顯降低。
實現原理
按需建立連接，即代理根據需要與后端數據庫建立連接。在保證一致性和RW負載的情況下，盡量少地與數據庫建聯，從而節省數據庫因為與代理建聯和執行廣播導致的開銷。大部分情況下，一個會話至多與一個RW節點和一個RO節點建聯（在不考慮一致性，即最終一致性）。在短連接或者廣播語句比較多的場景下，性能提升比較明顯。
如上圖所示，假設PolarDB集群中只存在一個RW節點和三個RO節點，在不考慮一致性的前提下，三種場景下的請求路由和數據讀取效率如下：
非按需建連
用戶的一個會話通過數據庫代理會與四個數據庫都建立連接，并且廣播語句會路由到四個數據庫節點。
按需建連，只讀會話
用戶的一個會話通過數據庫代理會只與一個RO節點建立連接，只讀請求（包括廣播）只會路由到這一個RO節點上，數據讀取效率明顯提升。
按需建連，讀寫會話
用戶的一個會話通過數據庫代理只會與一個RO節點，以及一個RW節點建立連接，廣播請求只會路由到兩個數據庫節點，數據讀取效率也會明顯提升。
適用場景
RO節點較多；
短連接；
廣播語句較多（例如PHP短連接場景下，會話的第一個語句一般似于
set names utf8mb4語句）；使用短prepare進行查詢比較多的場景。
使用限制
數據庫代理版本需為2.8.34及以上。查看集群的數據庫代理版本的具體操作步驟請參見查詢版本號。
使用
SHOW PROCESSLISTS查看連接的數據庫數量時，可能不會顯示所有的數據庫連接數。使用KILL命令終止指定連接時，可能不會終止所有數據庫中的指定連接。
性能測試
測試環境
數據庫節點：1個讀寫（RW）節點、7個只讀（RO）節點
測試使用的SQL：
SET NAMES utf8mb4，SELECT 1測試工具：Sysbench，且每次的并發數量一樣
測試場景：不打開連接池、打開會話級連接池和打開事務級連接池三種場景，每種場景測試分為兩個部分，前半部分為不打開按需建連，后半部分為打開按需建連。
測試結果
不打開連接池場景下的性能測試結果：
數據庫節點的CPU消耗如下圖所示，打開按需建連后，數據庫的CPU消耗下降60%以上：
數據庫節點的總連接數變化如下圖所示，打開按需建連后，數據庫的總連接數下降80%以上：
總體的QPS變化如下圖所示，打開按需建連后，總體的QPS提升了35%：
打開會話級連接池場景下的性能測試結果：
數據庫節點的CPU消耗如下圖所示，打開按需建連后，數據庫的CPU消耗下降50%~60%以上：
數據庫節點的總連接數變化如下圖所示，打開按需建連后，數據庫的總連接數下降60%：
總體的QPS變化如下圖所示，打開按需建連后，QPS提升了30%：
打開事務級連接池場景下的性能測試結果：
數據庫節點的CPU消耗如下圖所示，打開按需建連后，數據庫的CPU下降了60%：
數據庫節點的總連接數變化如下圖所示，打開按需建連后，總連接數下降了50%：
總體的QPS變化如下圖所示，打開按需建連后，QPS提升了260%：
