商用App服務端數據訪問架構改造研究

洪亮

摘要：商用App因為使用人數較多，對于服務端數據庫訪問有著較高的要求。如果數據訪問架構不合理，當訪問請求較多時，容易出現訪問超時的情況。文中，主要就對商用App服務端數據訪問架構改造進行了分析。

關鍵詞：商用App;服務端;數據訪問;架構

中圖分類號：TP393 文獻標識碼：A

文章編號：1009-3044（2020）21-0076-02

開放科學（資源服務）標識碼（0SID）：

1 背景研究

1.1系統商用問題

某國某運營商的掌上App項目中，近期出現了用戶使用過程中App響應慢，卡頓甚至系統崩潰的問題。經過問題排查發現問題大概率出現在業務高峰期，并且隨著用戶量的增加，問題的出現概率越高。系統前端向服務端的請求出現超時。進而檢查服務端，發現超時的原因在于數據庫鏈接滿載，讀寫吞吐量達到瓶頸導致請求超時。

1.2系統服務端架構分析

通過對目前系統服務端的架構做分析，發現目前服務端是采用的單一數據訪問架構，服務端通過web項目將業務服務封裝為restful接口給前端App調用，服務端的業務類訪問單一的Mysql數據庫，當讀寫數據量大時，業務類到Mysql的鏈接處就出現了瓶頸，出現了上面提到的問題。所以為了解決這個問題就必須改造現網系統服務端的數據訪問架構，從單一數據庫訪問改造為分布式或集群架構，用來擴展數據庫訪問效率和吞吐量，并可提升數據訪問的高可用性。

1.3 架構選型

目前業界有多種Mysql數據庫的分布式/集群方案，通過對各種方案的優劣并結合項目實際情況為本次的改造選擇使用MysqI+Mycat的架構，中間件對代碼影響最小，易于架構改動，以及后期擴展。

2 架構實現

第一部分的改造將一臺Mysql數據庫擴展為兩臺Mysql，一主一備，通過原生的復制機制實現雙向復制，加入Mycat中間件代理兩臺Mysql，實現讀寫的負載均衡，并且Mycat通過心跳機制檢測到主庫宕機后，自動切換到備機。業務測代碼不需要修改，只需要修改數據庫的連接由Mysql的地址切換到Mycat即可。

第二部分的改造也有兩種方案，第一種：將一臺Mycat擴展為兩臺，業務測訪問VIP（虛擬IP），兩臺keepalive競爭VIP，并由HAproxy轉發到其中一臺Mycat，實現負載均衡高可用。

第二種：Mycat依舊為兩臺，但是負載均衡不在服務端，而是放在客戶端（及業務代碼端），使用java原生提供的LoadBal-ancing協議，將對數據庫的讀寫請求負載在多個MYcat實例上實現Mycat的高可用。LoadBalancing原理：mysql connector/J驅動創建的LoadBalancedConnection是一個邏輯鏈接，其內部持有一個物理鏈接列表，即與每個host建立一個Connection。url中的每個host都是平等的主host，當客戶端獲取連接時會有兩種random（默認隨機）和bestResponseTime（最小響應時間）兩種均衡策略，可以在參數** loadBalanceStrategy**中指定，架構圖如圖1。

關于兩種方案的選擇，方案一自定義軟負載是自己實現的，功能單一，負載策略只有輪詢，而且健康檢查在很長一段時間出現連接泄露的問題，穩定性不夠好，還需要做一些優化和測試進行打磨;方案二是基于mysql的Java連接驅動做的負載均衡，是官方提供的方案，穩定性和可用性更高，而且我們在經過很長一段時間的壓測和容錯性測試，發現其性能很優越，負載均衡策略也更豐富，使用過程更簡單，所以決定使用方案二。

3 環境搭建

3.1 Mycat+Mysql搭建

首先在兩臺Linux主機上安裝Mycat，然后再安裝兩臺Mysql，端口號分別為3301和3302，安裝方法這里不贅述。接著對兩臺Mycat進行配置，分別代理兩臺Mysql數據庫，分別對server.xml.schemas.xml做相應的配置，實現代理一主一從兩個Mysql數據庫，并且從庫也為主庫的備用庫，注意schemas.xml中的balance類型設置為2，所有的主庫和從庫都參與讀操作的負載均衡。

3.2 功能驗證

3.2.1 負載均衡

啟動兩臺Mysql和兩臺Mycat，從任意一臺Mysql主機訪問Mycat，指令為：

mysql -h172.16.23.126 -P8066 -uroot -pmycat0001

端口指向其中一臺My at，用戶名密碼，執行多次查詢操作，讀操作負載均衡日志中展示的結果，已實現了在主從庫中負載讀的操作。

3.2.2故障遷移

手動停掉主庫模擬數據庫宕機的情況，mycat自動將從庫切換為主庫，不影響讀寫操作，并且當主庫故障恢復后，再次測試多次查詢操作，恢復到之前的負載均衡狀態。

3.2.3 主從復制

關于主從復制功能，因為目前一主一從的架構下寫操作都在主庫，讀操作在主庫與從庫間負載，所以需要主從保持復制同步數據。這里使用Mysql原生的復制機制，通過bin log實現數據的同步。驗證過程：同樣登陸mycat，執行插入，修改或刪除操作，首先數據會入主庫，查詢主庫表能夠查詢到寫操作的結果，這時再查詢從庫，發現數據和主庫一致，說明復制操作完成。當停掉其中一個數據庫后，再次執行插入，修改或刪除操作，然后手動恢復停掉的數據庫，再次查詢該數據庫的表數據，發現兩庫數據保持一致，說明在故障恢復后，主從復制的機制仍然有效。

4 性能測試

4.1 測試前提準備

有一個重要的指標需要注意，就是數據庫的最大連接數，要模擬現網項目的真實場景，這個配置是至關重要的，所以首先需要將兩臺Mysql數據庫的最大連接數設置和現網項目保持一致，這里我們設置為2000。

4.2 采集樣本準備

準備兩組采集樣本，第一組采集對單例mysql讀操作的性能數據，初始并發請求為0，每過10秒鐘增加100并發請求，一直增加到并發5000，然后保持60秒，然后每秒減少100并發，直到并發為0。通過對上述場景下的mysql單例吞吐量，請求書，失敗率三個方面表現做觀察和分析。第二組則對Mycat架構下一主一從的mysql做讀操作的性能數據，同樣采用以上的遞增并發測試場景。

4.3 壓測工具準備

采用開源壓力測試工具JMeter作為本次的性能壓力測試工具，并創建壓測模板。新建兩個stepping thread group，一個是連接單例mysql，一個連接mycat，采用同樣的讀查詢SQL。

4.4 壓測結果分析

首先在對單例mysql的測試中我們可以看到剛開始時請求成功的TPS達到1700左右，然后隨著并發量的提升，TPS逐漸降低，到4分鐘時差不多降到1600左右，這個時候的并發請求快到了2000，后面繼續降低，并且開始出現請求錯誤的響應，繼續到9分鐘左右，并發到達峰值5000，成功請求TPS降到1500左右。

14分鐘總共處理請求數155萬，平均響應時長1014ms，響應錯誤率13.46%，也就是成功響應的請求數為134萬。

然后看mycat代理2臺mysql負載均衡的測試結果，剛開始時請求成功的TPS達到3500左右，然后隨著并發量的提升，TPS逐漸降低，到4分鐘時差不多降到3300左右，這個時候的并發請求快到了2000，后面繼續降低，并且開始出現請求錯誤的響應，繼續到9分鐘左右，并發到達峰值5000，成功請求TPS降到3100左右。

14分鐘總共處理請求數337萬，平均響應時長529ms，響應錯誤率17.73%，也就是成功響應的請求數為277萬。

綜合對比分析，可見在mycat的代理分布式mysql的環境下，不論從吞吐量，處理請求書，響應延時以及成功請求數等各方面，幾乎提升了一倍的性能，效果比較理想。

5 穩定性測試

為了保證在升級到新的架構后數據庫訪問的穩定性，所以要做穩定性測試，在新的mycat代理2臺mysql環境下，繼續使用JMeter工具壓測，測試樣本調整為保持2000并發請求，并持續24小時，觀察新架構下的數據訪問穩定性，從測試結果可以看得出24個小時保持高并發下mycat+mysql表現穩定，吞吐量保持在3200-3300左右，平均請求延時在600ms左右，總共的請求錯誤率在1.1%左右，可以說結果比較理想。

6 擴展性

目前為止已經完成了將單例mysql擴展為2臺mysql負載均衡的架構，這里稱為擴容階段1。并且通過壓力測試結果可以得出性能確實提升的結論，所以再升級為新的架構后，理論上可以有效緩解現網App客戶在使用時的卡頓、響應慢、崩潰等問題。當然考慮到用戶量的不斷增加，新的架構也必須要考慮到良好的擴展性，對于后期的擴容本文也給出了響應的架構演進，擴容階段2將增加兩臺mysql，一共4臺，做雙主單從，兩主互為主備，相互復制，主從之前相互復制，讀操作在4臺中負載均衡，效率應為階段1的兩倍左右。隨著用戶量繼續增加，再到擴容階段3再增加兩臺mysql，一共6臺，在雙主的情況下做雙主雙從，這時可以將負載均衡策略改為再除了當前主機之外的其他5臺mysql做讀負載，主機只做寫，讀寫分離，讓主機寫效率更高。如果用戶量還在持續上升，那么架構將演進到最終階段，架構升級為N主N從，可以考慮將寫負載到N臺主庫上，所有從庫做讀負載均衡。

【通聯編輯：李雅琪】