mysql中Oneproxy如何實(shí)現(xiàn)讀寫(xiě)分離

這篇文章將為大家詳細(xì)講解有關(guān)mysql中Oneproxy如何實(shí)現(xiàn)讀寫(xiě)分離，小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

基本架構(gòu)： 寫(xiě)請(qǐng)求全部定向到主庫(kù)，數(shù)據(jù)通過(guò)日志異步復(fù)制到副庫(kù)，讀請(qǐng)求可根據(jù)情況路由到主庫(kù)或者副庫(kù)，分散讀壓力目前讀的壓力平均分到3臺(tái)服務(wù)器，性能提升在20-30%左右


中間件連接池會(huì)根據(jù) CONNECTION的AUTO COMMIT 狀態(tài)來(lái)緩沖連接，如果過(guò)程中AUTOCOMMIT的值發(fā)生變化，則之前緩存的數(shù)據(jù)庫(kù)連接會(huì)失效. 導(dǎo)致重新建立連接性能下降. JDBC事務(wù)控制恰恰會(huì)主動(dòng)把CONNECTION的 AUTOCOMMIT屬性設(shè)為 FALSE （默認(rèn)為T(mén)RUE). 如果禁用事務(wù)，數(shù)據(jù)完整性得不到保證并且會(huì)引發(fā)其他錯(cuò)誤. 好在ONEPROXY最新版本已經(jīng)解決了這個(gè)問(wèn)題  （題外話，好像MYCAT連接池的設(shè)計(jì)思路也類(lèi)似，使用時(shí)有沒(méi)有坑有待驗(yàn)證）


在高并發(fā)下 ONEPROXY 中間件的連接池大小要調(diào)整

ONEPROXY 中間件的字符集要設(shè)置成UTF8，默認(rèn)是GBK, 如果沒(méi)有設(shè)對(duì)，那么對(duì)象序列化的BLOB存到MYSQL數(shù)據(jù)庫(kù)會(huì)損壞導(dǎo)致無(wú)法反序列化
 


在寫(xiě)主數(shù)據(jù)庫(kù)，讀多個(gè)副數(shù)據(jù)庫(kù)的架構(gòu)下，最常見(jiàn)的問(wèn)題是數(shù)據(jù)復(fù)制不及時(shí)，導(dǎo)致定向到副庫(kù)的讀請(qǐng)求沒(méi)有讀到數(shù)據(jù)ONEPROXY 通過(guò)事務(wù)控制來(lái)解決這個(gè)問(wèn)題，如果讀和寫(xiě)操作都在一個(gè)事務(wù)里，那么他們都會(huì)到被定向到主數(shù)據(jù)庫(kù)所以事務(wù)的邊界控制很重要，但是現(xiàn)在應(yīng)用的代碼非?；靵y，導(dǎo)致控制事務(wù)很困難，ONEPROXY提供了一個(gè)折衷的方案，可指定對(duì)于某個(gè)表定向到主庫(kù)/副庫(kù)，現(xiàn)在對(duì)于讀寫(xiě)都很頻繁的表，購(gòu)物車(chē)，訂單，訂單行，促銷(xiāo)，支付記錄等一律指定路由到主庫(kù)錯(cuò)誤率目前基本控制在零. 曾經(jīng)也嘗試過(guò)用PERCONA的參數(shù) WSREP_CAUSAL_READS 來(lái)解決上述問(wèn)題，但是并沒(méi)有效果

關(guān)于“mysql中Oneproxy如何實(shí)現(xiàn)讀寫(xiě)分離”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。