什麼是資料庫代理負載平衡 - 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），然後單擊確定。
設定完成後，單擊確定。

測試資料

以下展示了配置節點權重後的實際測試資料。

測試使用的三個節點的權重配置比例為1:2:3（RW節點為1），可以看到壓測結果符合預期（使用Sysbench oltp_read_only測試集）。

456789

說明

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%：