負(fù)載均衡策略

主庫(kù)是否接受讀

主庫(kù)是否接受讀選擇否后，普通的讀請(qǐng)求將不再發(fā)往主節(jié)點(diǎn)。而事務(wù)內(nèi)，一致性要求的讀請(qǐng)求仍會(huì)被發(fā)往主節(jié)點(diǎn)，以保證業(yè)務(wù)需求。另外，當(dāng)所有只讀節(jié)點(diǎn)出現(xiàn)故障后，讀請(qǐng)求也會(huì)發(fā)往主節(jié)點(diǎn)。如果業(yè)務(wù)對(duì)一致性的要求較低，可以通過(guò)設(shè)置一致性級(jí)別為最終一致性來(lái)減少讀請(qǐng)求到主節(jié)點(diǎn)，也可以通過(guò)事務(wù)拆分功能來(lái)減少真正事務(wù)前的讀請(qǐng)求發(fā)往主節(jié)點(diǎn)。廣播的請(qǐng)求（例如SET或PREPARE）仍會(huì)被發(fā)往主節(jié)點(diǎn)。

事務(wù)拆分

當(dāng)使用PolarDB可讀可寫(xiě)模式集群地址時(shí)，讀寫(xiě)請(qǐng)求會(huì)由數(shù)據(jù)庫(kù)代理（Proxy）分發(fā)到主節(jié)點(diǎn)和只讀節(jié)點(diǎn)。為了保證一個(gè)會(huì)話連接中事務(wù)讀寫(xiě)一致性，代理會(huì)將這個(gè)會(huì)話中所有在事務(wù)中的請(qǐng)求都發(fā)送到主節(jié)點(diǎn)。例如，某些數(shù)據(jù)庫(kù)客戶端驅(qū)動(dòng)（如JDBC）默認(rèn)將請(qǐng)求封裝在事務(wù)中，因此應(yīng)用的請(qǐng)求都會(huì)被發(fā)送到主節(jié)點(diǎn)，導(dǎo)致主節(jié)點(diǎn)壓力大，而只讀節(jié)點(diǎn)幾乎沒(méi)有壓力，如下圖所示：

為了解決上述問(wèn)題，PolarDB在讀已提交（Read Committed）的事務(wù)隔離級(jí)別下提供了事務(wù)拆分功能，旨在保證業(yè)務(wù)中讀寫(xiě)一致性的前提下，將事務(wù)中讀請(qǐng)求發(fā)送到只讀節(jié)點(diǎn)，以減輕主節(jié)點(diǎn)的壓力。您不需要改動(dòng)應(yīng)用的代碼或配置就可以將事務(wù)中的讀壓力從主節(jié)點(diǎn)轉(zhuǎn)移到只讀節(jié)點(diǎn)，從而提高主節(jié)點(diǎn)的穩(wěn)定性。開(kāi)啟事務(wù)拆分能力的詳細(xì)操作步驟請(qǐng)參見(jiàn)配置數(shù)據(jù)庫(kù)代理。

PolarDB MySQL版提供了事務(wù)寫(xiě)前讀拆分（默認(rèn)值，即原來(lái)的事務(wù)拆分功能）和事務(wù)全（寫(xiě)前讀、寫(xiě)后讀）拆分兩個(gè)級(jí)別的事務(wù)拆分能力：

• 事務(wù)寫(xiě)前讀拆分

  Proxy會(huì)將事務(wù)中第一個(gè)寫(xiě)請(qǐng)求前的讀請(qǐng)求發(fā)送到只讀節(jié)點(diǎn)，從而減輕主節(jié)點(diǎn)的負(fù)載。

  

• 全（寫(xiě)前讀、寫(xiě)后讀）拆分

  寫(xiě)前讀拆分對(duì)于事務(wù)中寫(xiě)之后的讀仍然會(huì)路由到主節(jié)點(diǎn)，這種情況下負(fù)載仍然不太均衡，為徹底解決事務(wù)帶來(lái)的負(fù)載均衡問(wèn)題，PolarDB MySQL版推出事務(wù)全拆分能力，可以使得事務(wù)中的讀操作都路由到只讀節(jié)點(diǎn)且獲得正確的結(jié)果。進(jìn)一步減輕主節(jié)點(diǎn)的壓力。

  

  事務(wù)寫(xiě)后讀被路由到只讀節(jié)點(diǎn)的前提是當(dāng)前的只讀節(jié)點(diǎn)已同步事務(wù)之前的寫(xiě)操作的數(shù)據(jù)，如果用戶配置了會(huì)話一致性，那么在路由寫(xiě)后讀時(shí)會(huì)先判斷當(dāng)前Session的只讀節(jié)點(diǎn)是否已經(jīng)同步之前的寫(xiě)，如果已同步就會(huì)路由過(guò)去，否則會(huì)直接路由到主節(jié)點(diǎn)。同樣地，如果用戶配置了全局一致性，那么在路由寫(xiě)后讀時(shí)會(huì)先判斷當(dāng)前所有Session的事務(wù)是否都已經(jīng)同步到只讀節(jié)點(diǎn)，如果已同步就會(huì)路由過(guò)去，否則會(huì)直接路由到主節(jié)點(diǎn)。事務(wù)全拆分不支持配置為最終一致性。

  版本和使用限制

  如需使用事務(wù)全拆分能力，則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版本，無(wú)修訂版本限制。

  • 需要讓內(nèi)核參數(shù)loose_query_cache_type設(shè)置為OFF（PolarDB MySQL版5.6、5.7和8.0.1版本參數(shù)默認(rèn)值為OFF，8.0.2版本默認(rèn)為ON，該參數(shù)設(shè)置變更需要重啟PolarDB）。

• 關(guān)閉事務(wù)拆分

  當(dāng)事務(wù)拆分關(guān)閉后，事務(wù)內(nèi)的所有請(qǐng)求都路由到主節(jié)點(diǎn)。

基于權(quán)重的動(dòng)態(tài)負(fù)載均衡

當(dāng)前PolarDB MySQL版代理默認(rèn)的負(fù)載均衡策略是優(yōu)先選擇最小活躍（并發(fā)）請(qǐng)求數(shù)的節(jié)點(diǎn)去路由請(qǐng)求。該策略基本可以使得流量根據(jù)后端節(jié)點(diǎn)的負(fù)載均衡的路由到不同的后端節(jié)點(diǎn)上，即使后端節(jié)點(diǎn)的規(guī)格不一致，也能較好的進(jìn)行負(fù)載均衡。但是線上客戶的業(yè)務(wù)負(fù)載多種多樣，用戶對(duì)于流量的分發(fā)需求也不盡相同。

為了更好地滿足客戶的需求，PolarDB MySQL版引入了基于權(quán)重的動(dòng)態(tài)負(fù)載均衡功能，您可以為每個(gè)節(jié)點(diǎn)配置不同的權(quán)重，在后續(xù)的路由過(guò)程中，權(quán)重和并發(fā)請(qǐng)求數(shù)會(huì)同時(shí)作為參考標(biāo)準(zhǔn)去動(dòng)態(tài)的調(diào)整最終的路由決策。目前僅支持基于以下2個(gè)維度配置權(quán)重：

• 全局DB維度

  該配置會(huì)對(duì)所有的地址生效；

• 地址（endpoint）維度

  地址維度的權(quán)重僅會(huì)對(duì)該地址的負(fù)載均衡生效，并覆蓋DB維度。即用戶先配置了一個(gè)DB維度的權(quán)重，又為某個(gè)地址單獨(dú)配置了權(quán)重，則這個(gè)地址的負(fù)載均衡以配置到該地址維度為準(zhǔn)；

注意事項(xiàng)

• 該功能要求數(shù)據(jù)庫(kù)代理的版本為2.8.3或以上。

• 由于同時(shí)考慮當(dāng)前節(jié)點(diǎn)負(fù)載和用戶自定義權(quán)重，所以整體的比例可能和用戶自定義比例有一些偏差，隨著時(shí)間推移，會(huì)逐步地向自定義比例靠近。

• Serverless實(shí)例不支持地址（endpoint）維度權(quán)重設(shè)置。

實(shí)現(xiàn)原理

在路由請(qǐng)求過(guò)程中，各個(gè)節(jié)點(diǎn)最終的權(quán)重是根據(jù)用戶配置的權(quán)重和節(jié)點(diǎn)當(dāng)前的并發(fā)請(qǐng)求數(shù)進(jìn)行動(dòng)態(tài)調(diào)整。所采用的公式簡(jiǎn)化后如下：

動(dòng)態(tài)權(quán)重=自定義配置的權(quán)重/并發(fā)請(qǐng)求數(shù)

動(dòng)態(tài)權(quán)重越大，節(jié)點(diǎn)的優(yōu)先級(jí)越高。動(dòng)態(tài)權(quán)重負(fù)載策略提供了一個(gè)比較靈活的路由方式。在實(shí)際使用時(shí)，業(yè)務(wù)流量會(huì)根據(jù)用戶所配置的權(quán)重逐步變化（相比完全按照權(quán)重輪詢(xún)會(huì)需要更多的時(shí)間）。

操作步驟

配置全局DB維度權(quán)重

1. 登錄PolarDB控制臺(tái)。

2. 在左上角，選擇集群所在地域。

3. 找到目標(biāo)集群，單擊集群ID。

4. 在基本信息頁(yè)面的數(shù)據(jù)庫(kù)代理企業(yè)通用版或數(shù)據(jù)庫(kù)代理企業(yè)獨(dú)享版區(qū)域，單擊數(shù)據(jù)庫(kù)代理服務(wù)配置。

5. 在數(shù)據(jù)庫(kù)代理服務(wù)配置對(duì)話框中，根據(jù)業(yè)務(wù)需求為每個(gè)節(jié)點(diǎn)配置不同的權(quán)重。

   

6. 配置完成后，單擊確定。

配置地址維度權(quán)重

1. 登錄PolarDB控制臺(tái)。

2. 在左上角，選擇集群所在地域。

3. 找到目標(biāo)集群，單擊集群ID。

4. 在基本信息頁(yè)面的數(shù)據(jù)庫(kù)代理企業(yè)通用版或數(shù)據(jù)庫(kù)代理企業(yè)獨(dú)享版區(qū)域，單擊集群地址或自定義地址右上角的配置。

5. 在編輯地址配置頁(yè)面的服務(wù)節(jié)點(diǎn)區(qū)域，將自定義節(jié)點(diǎn)權(quán)重選擇開(kāi)啟，并為節(jié)點(diǎn)設(shè)置權(quán)重。

   

6. 設(shè)置完成后，單擊確定。

測(cè)試數(shù)據(jù)

以下展示了配置節(jié)點(diǎn)權(quán)重后的實(shí)際測(cè)試數(shù)據(jù)。

測(cè)試使用的三個(gè)節(jié)點(diǎn)的權(quán)重配置比例為1:2:3（RW節(jié)點(diǎn)為1），可以看到壓測(cè)結(jié)果符合預(yù)期（使用Sysbench oltp_read_only測(cè)試集）。

按需建連

背景信息

對(duì)于基于活躍請(qǐng)求數(shù)負(fù)載均衡的Endpoint，默認(rèn)的建聯(lián)方式為全建聯(lián)。即一個(gè)客戶端會(huì)話通過(guò)代理建連后，代理會(huì)與該地址內(nèi)的所有數(shù)據(jù)庫(kù)節(jié)點(diǎn)都建立一個(gè)會(huì)話（連接），即1:N的連接關(guān)系。并且這個(gè)會(huì)話的普通讀請(qǐng)求會(huì)按照當(dāng)前數(shù)據(jù)庫(kù)的活躍負(fù)載而路由到各個(gè)數(shù)據(jù)庫(kù)執(zhí)行，廣播請(qǐng)求（SET語(yǔ)句等）會(huì)路由到所有的數(shù)據(jù)庫(kù)。在數(shù)據(jù)庫(kù)數(shù)目較多時(shí)，整體效率會(huì)因?yàn)榻?lián)和廣播明顯降低。

實(shí)現(xiàn)原理

按需建立連接，即代理根據(jù)需要與后端數(shù)據(jù)庫(kù)建立連接。在保證一致性和RW負(fù)載的情況下，盡量少地與數(shù)據(jù)庫(kù)建聯(lián)，從而節(jié)省數(shù)據(jù)庫(kù)因?yàn)榕c代理建聯(lián)和執(zhí)行廣播導(dǎo)致的開(kāi)銷(xiāo)。大部分情況下，一個(gè)會(huì)話至多與一個(gè)RW節(jié)點(diǎn)和一個(gè)RO節(jié)點(diǎn)建聯(lián)（在不考慮一致性，即最終一致性）。在短連接或者廣播語(yǔ)句比較多的場(chǎng)景下，性能提升比較明顯。

如上圖所示，假設(shè)PolarDB集群中只存在一個(gè)RW節(jié)點(diǎn)和三個(gè)RO節(jié)點(diǎn)，在不考慮一致性的前提下，三種場(chǎng)景下的請(qǐng)求路由和數(shù)據(jù)讀取效率如下：

• 非按需建連

  用戶的一個(gè)會(huì)話通過(guò)數(shù)據(jù)庫(kù)代理會(huì)與四個(gè)數(shù)據(jù)庫(kù)都建立連接，并且廣播語(yǔ)句會(huì)路由到四個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)。

• 按需建連，只讀會(huì)話

  用戶的一個(gè)會(huì)話通過(guò)數(shù)據(jù)庫(kù)代理會(huì)只與一個(gè)RO節(jié)點(diǎn)建立連接，只讀請(qǐng)求（包括廣播）只會(huì)路由到這一個(gè)RO節(jié)點(diǎn)上，數(shù)據(jù)讀取效率明顯提升。

• 按需建連，讀寫(xiě)會(huì)話

  用戶的一個(gè)會(huì)話通過(guò)數(shù)據(jù)庫(kù)代理只會(huì)與一個(gè)RO節(jié)點(diǎn)，以及一個(gè)RW節(jié)點(diǎn)建立連接，廣播請(qǐng)求只會(huì)路由到兩個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)，數(shù)據(jù)讀取效率也會(huì)明顯提升。

適用場(chǎng)景

• RO節(jié)點(diǎn)較多；

• 短連接；

• 廣播語(yǔ)句較多（例如PHP短連接場(chǎng)景下，會(huì)話的第一個(gè)語(yǔ)句一般似于set names utf8mb4語(yǔ)句）；

• 使用短prepare進(jìn)行查詢(xún)比較多的場(chǎng)景。

使用限制

• 數(shù)據(jù)庫(kù)代理版本需為2.8.34及以上。查看集群的數(shù)據(jù)庫(kù)代理版本的具體操作步驟請(qǐng)參見(jiàn)查詢(xún)版本號(hào)。

• 使用SHOW PROCESSLISTS查看連接的數(shù)據(jù)庫(kù)數(shù)量時(shí)，可能不會(huì)顯示所有的數(shù)據(jù)庫(kù)連接數(shù)。

• 使用KILL命令終止指定連接時(shí)，可能不會(huì)終止所有數(shù)據(jù)庫(kù)中的指定連接。

性能測(cè)試

測(cè)試環(huán)境

• 數(shù)據(jù)庫(kù)節(jié)點(diǎn)：1個(gè)讀寫(xiě)（RW）節(jié)點(diǎn)、7個(gè)只讀（RO）節(jié)點(diǎn)

• 測(cè)試使用的SQL：SET NAMES utf8mb4，SELECT 1

• 測(cè)試工具：Sysbench，且每次的并發(fā)數(shù)量一樣

• 測(cè)試場(chǎng)景：不打開(kāi)連接池、打開(kāi)會(huì)話級(jí)連接池和打開(kāi)事務(wù)級(jí)連接池三種場(chǎng)景，每種場(chǎng)景測(cè)試分為兩個(gè)部分，前半部分為不打開(kāi)按需建連，后半部分為打開(kāi)按需建連。

測(cè)試結(jié)果

• 不打開(kāi)連接池場(chǎng)景下的性能測(cè)試結(jié)果：

  • 數(shù)據(jù)庫(kù)節(jié)點(diǎn)的CPU消耗如下圖所示，打開(kāi)按需建連后，數(shù)據(jù)庫(kù)的CPU消耗下降60%以上：

    

  • 數(shù)據(jù)庫(kù)節(jié)點(diǎn)的總連接數(shù)變化如下圖所示，打開(kāi)按需建連后，數(shù)據(jù)庫(kù)的總連接數(shù)下降80%以上：

    

  • 總體的QPS變化如下圖所示，打開(kāi)按需建連后，總體的QPS提升了35%：

    

• 打開(kāi)會(huì)話級(jí)連接池場(chǎng)景下的性能測(cè)試結(jié)果：

  • 數(shù)據(jù)庫(kù)節(jié)點(diǎn)的CPU消耗如下圖所示，打開(kāi)按需建連后，數(shù)據(jù)庫(kù)的CPU消耗下降50%~60%以上：

    

  • 數(shù)據(jù)庫(kù)節(jié)點(diǎn)的總連接數(shù)變化如下圖所示，打開(kāi)按需建連后，數(shù)據(jù)庫(kù)的總連接數(shù)下降60%：

    

  • 總體的QPS變化如下圖所示，打開(kāi)按需建連后，QPS提升了30%：

    

• 打開(kāi)事務(wù)級(jí)連接池場(chǎng)景下的性能測(cè)試結(jié)果：

  • 數(shù)據(jù)庫(kù)節(jié)點(diǎn)的CPU消耗如下圖所示，打開(kāi)按需建連后，數(shù)據(jù)庫(kù)的CPU下降了60%：

    

  • 數(shù)據(jù)庫(kù)節(jié)點(diǎn)的總連接數(shù)變化如下圖所示，打開(kāi)按需建連后，總連接數(shù)下降了50%：

    

  • 總體的QPS變化如下圖所示，打開(kāi)按需建連后，QPS提升了260%：