這篇文章將為大家詳細講解有關mysql中Oneproxy如何實現讀寫分離，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

基本架構： 寫請求全部定向到主庫，數據通過日志異步復制到副庫，讀請求可根據情況路由到主庫或者副庫，分散讀壓力目前讀的壓力平均分到3臺服務器，性能提升在20-30%左右


中間件連接池會根據 CONNECTION的AUTO COMMIT 狀態來緩沖連接，如果過程中AUTOCOMMIT的值發生變化，則之前緩存的數據庫連接會失效. 導致重新建立連接性能下降. JDBC事務控制恰恰會主動把CONNECTION的 AUTOCOMMIT屬性設為 FALSE （默認為TRUE). 如果禁用事務，數據完整性得不到保證并且會引發其他錯誤. 好在ONEPROXY最新版本已經解決了這個問題 （題外話，好像MYCAT連接池的設計思路也類似，使用時有沒有坑有待驗證）


在高并發下 ONEPROXY 中間件的連接池大小要調整

ONEPROXY 中間件的字符集要設置成UTF8，默認是GBK, 如果沒有設對，那么對象序列化的BLOB存到MYSQL數據庫會損壞導致無法反序列化
 


在寫主數據庫，讀多個副數據庫的架構下，最常見的問題是數據復制不及時，導致定向到副庫的讀請求沒有讀到數據ONEPROXY 通過事務控制來解決這個問題，如果讀和寫操作都在一個事務里，那么他們都會到被定向到主數據庫所以事務的邊界控制很重要，但是現在應用的代碼非常混亂，導致控制事務很困難，ONEPROXY提供了一個折衷的方案，可指定對于某個表定向到主庫/副庫，現在對于讀寫都很頻繁的表，購物車，訂單，訂單行，促銷，支付記錄等一律指定路由到主庫錯誤率目前基本控制在零. 曾經也嘗試過用PERCONA的參數 WSREP_CAUSAL_READS 來解決上述問題，但是并沒有效果

關于“mysql中Oneproxy如何實現讀寫分離”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。

另外有需要云服務器可以了解下創新互聯cdcxhl.cn，海內外云服務器15元起步，三天無理由+7*72小時售后在線，公司持有idc許可證，提供“云服務器、裸金屬服務器、高防服務器、香港服務器、美國服務器、虛擬主機、免備案服務器”等云主機租用服務以及企業上云的綜合解決方案，具有“安全穩定、簡單易用、服務可用性高、性價比高”等特點與優勢，專為企業上云打造定制，能夠滿足用戶豐富、多元化的應用場景需求。