MySQL中間件的負載均衡策略優(yōu)化方案

1、mysql中間件的負載均衡策略優(yōu)化方案目錄、背景3二. 負載均衡策略及性能優(yōu)化4三. 總結(jié)9.背景隨著業(yè)務(wù)的爆發(fā)式增長，電商系統(tǒng)中的讀寫壓力越來越高，單節(jié)點mysql實例壓力越來越大， 單純升級服務(wù)器硬件已經(jīng)無法滿足生產(chǎn)環(huán)境的需要。解決讀請求壓力，需要支持從庫擴展；解 決寫請求壓力，對數(shù)據(jù)分片增加多個節(jié)點，降低單節(jié)點mysql實例的壓力成了更優(yōu)的選擇。傳統(tǒng)的分片是通過dao層進行的，但是dao層對數(shù)據(jù)分片存在諸多問題。從業(yè)務(wù)角度看，配 置修改需要重啟服務(wù)，代價巨大；需要對分片結(jié)果集進行處理，業(yè)務(wù)邏輯愈加復(fù)雜；功能相對簡單。從數(shù)據(jù)庫運維角度看，配管理的統(tǒng)一化難度較大；db的升級、遷移等操作復(fù)雜。

2、網(wǎng)易電商同樣面臨著這些問題，為了徹底解決數(shù)據(jù)庫瓶頸，網(wǎng)易樂得團隊在實際生產(chǎn)中硏發(fā)了 自己的中間件cetuso其具有正統(tǒng)基因，基于官方mysql-proxy的版本進行全面修復(fù)和再創(chuàng) 新，已于不久前開源，在各個產(chǎn)品線上得到廣泛應(yīng)用，性能和穩(wěn)定性均表現(xiàn)良好。cetus兼容mysql協(xié)議，前端應(yīng)用不用修改即可通過cetus訪問數(shù)據(jù)庫，方便dba運維同學(xué) 和開發(fā)同學(xué)使用，實現(xiàn)了數(shù)據(jù)庫層面的橫向擴展。目前cetus有讀寫分離和sharding兩個版本,可通過編譯參數(shù)選擇適合的版本。它支持對用戶透明的多項功能，例如分布式事務(wù)、連接池、結(jié)果集壓縮、安全管理、狀態(tài)監(jiān)控、tcp stream傳輸?shù)鹊?。二、負載均衡

3、策略及性能優(yōu)化本文所討論的負載均衡，指的是讀流量的負載均衡，即讀流量如何分配到后端同一 mysql集 群內(nèi)的各個db。cetus的負載均衡策略，主要分為兩部分:主從庫之間讀流量的負載策略；從庫之間讀流量的負載策f具體實現(xiàn)時候，流量的分配單位與atlas等中間件也略有不同，進行了性能優(yōu)化。下面章節(jié)將依次詳細介紹。1、主從庫之間讀流量的負載策略默認情況下，非事務(wù)中、未通過注釋強制路由主庫或未使用鎖的讀流量會優(yōu)先路由到從庫，各個從庫之間負載均衡。只有當從庫都不可用時，讀流量才會路由到主庫。有些業(yè)務(wù)場景下，主庫可以分擔(dān)部分讀流量，這時就涉及到讀流量在主庫和從庫上配置負載策略了。cetus中;可以通過配

4、置參數(shù)read-master-percentage來指定默認的讀流量路由到主庫的百 分比，該參數(shù)的取值范圍是0, 100。該值默認為0,即所有讀流量會優(yōu)先路由從庫，所有從庫均不可用時，才會路由主庫；如果該 參數(shù)設(shè)置為100時，則所有讀流量都會路由到主庫；如果該值設(shè)置為（0, 100）時，則會按照設(shè) 置的比例進行路由。需要注意的是，該值表示的是主庫和所有從庫的比例。2、從庫之間的讀流量負載策略路由到從庫的流量會在各個從庫之間進行負載均衡。目前cetus各個從庫之間的讀流量負載策 略僅支持輪詢（rr ）方式。在流量分配方面，cetus也進行了優(yōu)化。一些mysql數(shù)據(jù)庫中間件（例如atlas ）是基

5、于sql 的維度做負載均衡的，不會考慮sql是同一個連接還是不同連接發(fā)送來的，中間件依次將接收到的sql按照策略發(fā)往后端的數(shù)據(jù)庫。在實際使用中發(fā)現(xiàn)，長連接的場景下，該策略會造成大量的連接切換，從而導(dǎo)致session級變 量的頻繁調(diào)整，影響sql執(zhí)行效率。因此，cetus對其進行了優(yōu)化，并非完全按照sql的維 度做負載均衡。cetus考慮了同一個連接連續(xù)發(fā)送sql請求的情況，不會立即將當前sql使用完的cetus與mysql的連接放回連接池復(fù)用，而是持有短暫（256毫秒）時間，以期后續(xù)仍有sql執(zhí)行，從而避免了 session級變量的調(diào)整，大大增加了 sql執(zhí)行的效率。長連接場景下，對優(yōu)化前后的

6、cetus進行了簡單測試。通過測試發(fā)現(xiàn)，通過優(yōu)化后的cetus針對長連場景下的讀流量的吞吐量有了明顯提升。下圖是在docker環(huán)境下的簡單測試對比：序號節(jié)點角色1docker: 172.17.02cetus-release2docker: 172.17.0.3mysql5.7-master3docker: 172.17.0.4mysql5.7-slave4docker: 172.17.0.5mysql5.7-slave5docker: 172.17.0.6sysbench1.1為了防止10過高;簡單改造了 sysbench發(fā)送的sql，限制了返回的結(jié)果集大小。禁用事務(wù)和prepare的情況下，

7、采用100個線程每次測試60s ,連續(xù)測試5次，結(jié)果如下：序號優(yōu)化前qps優(yōu)化后qps1389124300.6123686.944983.4734166.355002.9443674.555219.5553371.535380.14avg3758.1144977.342由于本機docker性能較差，且sysbench模擬測試的語句較為簡單，不涉及session變量的 切換，因此對比效果不甚明顯，本次測試性能僅提升30%左右。長連接業(yè)務(wù)場景下z性能優(yōu)化 可能會更加明顯。久讀流量的路由策略總結(jié)a.b.c.在存在至少1個可用從庫的情況下，影響查詢語句的路由策略的因素主要有：事務(wù)中的查詢；select

8、.for update 或 select. lock in share mode ;cetus設(shè)置參數(shù)master-preferred=true所有流量默認全部路由主庫;d. cetus設(shè)置參數(shù)read-master-percentage控制主從讀流量負載；e使用注#mode二readwrite*/或廠#mode二readonly*/。默認情況下，讀流量會優(yōu)先路由到從庫，從庫之間按照輪詢策略在各個從庫之間做負載均衡； 一旦所有從庫均不可用，會路由到主庫上。目前cetus的各個從庫暫不支持按照權(quán)重做負載。對于a、b、c點，cetus會將查詢語句直接路由主庫；對于d點，如果設(shè)置read-master-percentage=100 ,所有的查詢流量均路由到主庫；如果設(shè) 置read-master-percentage=o/ 100） , cetus會將讀流量按照該比例路由到主庫和從庫（注 意，這里的從庫指的是全部的從庫，即該比例指的是主庫和全部從庫的比例）；對于e點，如果使用注釋/*#mode = readwrite*/ ,讀流量會路由到主庫；如果使用注釋 /*#mode=readonly*/讀流量會路由從庫,如果所有從庫均不可用時才會路由到主庫。上面的各個因素的優(yōu)先級，注釋的優(yōu)先級最高，其次是參數(shù)master-preferred ,