基于Mycat 的分布式技術(shù)在收集與分發(fā)系統(tǒng)中的應(yīng)用

劉 洋，高 鵬，徐 娟，陳旭輝

（甘肅省氣象信息與技術(shù)裝備保障中心，甘肅 蘭州 730020）

引言

隨著科技的進(jìn)步，氣象數(shù)據(jù)的種類和數(shù)量在不斷上升，由原來單一的、小規(guī)格的數(shù)據(jù)累積成了海量數(shù)據(jù)［1］。數(shù)據(jù)量的急劇增長會(huì)導(dǎo)致單機(jī)的存儲(chǔ)能力嚴(yán)重不足，特別是在汛期，高頻率的查詢使單機(jī)的處理能力和響應(yīng)性能嚴(yán)重的下降，數(shù)據(jù)不能實(shí)時(shí)入庫，給用戶的使用帶來極大的不便，同時(shí)給數(shù)據(jù)庫的管理者帶來了很大的負(fù)擔(dān)，而分布式數(shù)據(jù)庫［2-3］是在集中式數(shù)據(jù)庫基礎(chǔ)上發(fā)展而來的，其最顯著的特點(diǎn)就是數(shù)據(jù)分布在地理位置不同的機(jī)器上，但是所有的數(shù)據(jù)在邏輯上是集中管理的，分布式數(shù)據(jù)庫的出現(xiàn)克服了傳統(tǒng)集中式數(shù)據(jù)庫的許多缺點(diǎn)，成為大數(shù)據(jù)處理和存儲(chǔ)的方案之一［4-6］，分布式數(shù)據(jù)庫已被廣泛的應(yīng)用到各行各業(yè)［7-9］。目前，氣象業(yè)務(wù)中的收集與分發(fā)系統(tǒng)所采用的Mysql 數(shù)據(jù)庫是單機(jī)版的，高并發(fā)的數(shù)據(jù)量會(huì)導(dǎo)致單機(jī)的存儲(chǔ)能力和響應(yīng)性能嚴(yán)重下降，極大的削弱了系統(tǒng)的服務(wù)能力。

針對(duì)現(xiàn)有數(shù)據(jù)庫存在的問題，本文提出了基于Mycat 的分布式數(shù)據(jù)庫集群架構(gòu)，利用分布式存儲(chǔ)中間件Mycat 對(duì)數(shù)據(jù)進(jìn)行了讀寫分離，從而極大的提高了數(shù)據(jù)庫的讀寫性能以及可擴(kuò)展性；利用Haproxy［10-11］實(shí)現(xiàn)了Mycat 的高可用性；同時(shí)使用keepalived［12］實(shí)現(xiàn)了Haproxy 的高可用，解決了傳統(tǒng)的集中式數(shù)據(jù)庫單點(diǎn)故障的問題，保障了氣象數(shù)據(jù)傳輸?shù)姆€(wěn)定性和有效性。

1 基于Mycat 分布式數(shù)據(jù)庫的設(shè)計(jì)

采用Mycat+Mysql+Haproxy+Keepalived 的技術(shù)架構(gòu)來構(gòu)建關(guān)系型分布式集群系統(tǒng)，其整體架構(gòu)如圖1 所示。為了保證系統(tǒng)的高性能、高并發(fā)和高可用，所有的模塊都是基于集群進(jìn)行構(gòu)建，遵循自底向上的技術(shù)路線。

1.1 Mysql 數(shù)據(jù)庫集群的實(shí)現(xiàn)

主從復(fù)制是實(shí)現(xiàn)Mysql 高可用性、負(fù)載均衡以及讀寫分離的基礎(chǔ)，Mysql 的主從復(fù)制有多種形式，本文采用一主一從的形式，即一個(gè)寫節(jié)點(diǎn)（Master）和一個(gè)讀節(jié)點(diǎn)（Slave），寫節(jié)點(diǎn)負(fù)責(zé)所有應(yīng)用的寫操作，讀節(jié)點(diǎn)負(fù)責(zé)所有應(yīng)用的讀操作，一主一從的架構(gòu)部署簡單并且高效，不僅可以實(shí)現(xiàn)高可用，還能夠?qū)崿F(xiàn)讀寫分離，進(jìn)而提升集群的并發(fā)能力。

圖1 基于Mycat 的分布式集群架構(gòu)

1.2 Mycat 實(shí)現(xiàn)Mysql 的讀寫分離和高可用性

Mycat 是基于阿里巴巴Cobar 項(xiàng)目的開源分布式數(shù)據(jù)庫系統(tǒng)，其架構(gòu)如圖2 所示，Mycat 是介于數(shù)據(jù)庫和應(yīng)用之間，負(fù)責(zé)資源的調(diào)度和服務(wù)，后端是物理數(shù)據(jù)庫，Mycat 支持Mysql，SQL Server，Oracle，DB2 等主流數(shù)據(jù)庫。其原理是對(duì)用戶發(fā)送的SQL 語句進(jìn)行攔截，首先對(duì)SQL 語句做一些特定的分析，如路由分析、讀寫分離分析等，根據(jù)分析的結(jié)果，將對(duì)應(yīng)的SQL 語句發(fā)送至后端的物理數(shù)據(jù)庫，并將返回結(jié)果進(jìn)行處理后再輸出給用戶，對(duì)用戶而言Mycat 完全是透明的，為了防止Mycat 服務(wù)器單點(diǎn)故障，Mycat 的部署采用災(zāi)備方式，當(dāng)其中的一臺(tái)服務(wù)器宕機(jī)后，另外的一臺(tái)會(huì)立即接管相應(yīng)的服務(wù)，避免因單機(jī)故障導(dǎo)致服務(wù)中斷，從而實(shí)現(xiàn)了Mycat 的高可用性。同時(shí)，Mycat 內(nèi)置了一些功能，可以對(duì)后端真實(shí)的物理節(jié)點(diǎn)進(jìn)行定期的檢測，如果發(fā)現(xiàn)有故障節(jié)點(diǎn)，Mycat 可以進(jìn)行節(jié)點(diǎn)之間的自動(dòng)切換，從而提高了數(shù)據(jù)庫的可靠性。

圖2 Mycat 的原理架構(gòu)圖

1.3 Haproxy 實(shí)現(xiàn)Mycat 負(fù)載均衡和高可用性

Haproxy 是一款提供高可用和負(fù)載均衡的代理軟件。為了實(shí)現(xiàn)Mycat 的高可用性，避免Mycat 服務(wù)器的單點(diǎn)故障，文中采用Haproxy 來檢測Mycat 的存活，如果Haproxy 發(fā)現(xiàn)其中的某個(gè)Mycat 服務(wù)器已經(jīng)宕機(jī)，它會(huì)把用戶的請(qǐng)求自動(dòng)轉(zhuǎn)發(fā)到存活的Mycat 節(jié)點(diǎn)上，從而實(shí)現(xiàn)了Mycat 服務(wù)的高可用性，保證了服務(wù)的可靠性。同時(shí)，隨著氣象數(shù)據(jù)的越來越多，種類越來越復(fù)雜，單一的Mycat 節(jié)點(diǎn)承載能力有限，過多的數(shù)據(jù)量隨時(shí)都有可能導(dǎo)致單個(gè)節(jié)點(diǎn)宕機(jī)，所以需要再增加一個(gè)Mycat 節(jié)點(diǎn)，在這種情況下，就必須要通過負(fù)載均衡來實(shí)現(xiàn)流量的合理調(diào)度。Haproxy 提供了多種負(fù)載均衡的算法，文中采用了最常用的輪詢算法，Haproxy 會(huì)把請(qǐng)求輪詢的轉(zhuǎn)發(fā)到每一個(gè)服務(wù)器上，按照權(quán)重來分配。

1.4 Keepalived 實(shí)現(xiàn)Haproxy 高可用性

為了實(shí)現(xiàn)一個(gè)高性能，高可靠的分布式數(shù)據(jù)庫服務(wù)系統(tǒng)，Haproxy 采用了熱備模式，防止單節(jié)點(diǎn)故障的發(fā)生，文中利用Keepalived 并編寫監(jiān)測程序?qū)崟r(shí)監(jiān)控Haproxy 的健康狀態(tài)，隨時(shí)對(duì)故障進(jìn)行轉(zhuǎn)移，從而實(shí)現(xiàn)Haproxy 的高可用，Keepalived 主要是通過虛擬路由冗余協(xié)議實(shí)現(xiàn)高可用功能。

2 性能測試及分析

為了驗(yàn)證基于Mycat 的分布式數(shù)據(jù)庫的性能，文中搭建了六臺(tái)虛擬機(jī)并部署了分布式數(shù)據(jù)庫測試環(huán)境，虛擬機(jī)的配置為CentOS-7.3.1611-x86_64，32Core，16G Mem。所有應(yīng)用的部署都是在Windows 下通過Xshell 來實(shí)現(xiàn)的，所需要的依賴包都是通過Yum 方式進(jìn)行安裝。

2.1 Mysql 數(shù)據(jù)庫讀寫分離和主從切換測試

讀寫分離，即把應(yīng)用對(duì)數(shù)據(jù)庫的讀操作和寫操作放在不同的節(jié)點(diǎn)上執(zhí)行，其中寫操作在Mysql 的主節(jié)點(diǎn)上執(zhí)行，包括Insert，Delete，Update 操作，讀操作在從節(jié)點(diǎn)上執(zhí)行，包括Select 操作。在測試的過程中，開啟debug 模式，進(jìn)行Insert 語句和Select 語句操作，通過查看日志mycat.log 確認(rèn)讀和寫SQL 被路由到哪個(gè)服務(wù)器上，從而實(shí)現(xiàn)了數(shù)據(jù)的讀寫分離。

主從切換，即當(dāng)Mysql 的其中一個(gè)節(jié)點(diǎn)宕機(jī)之后會(huì)自動(dòng)切換到備用節(jié)點(diǎn)上，讀和寫的操作全部由備用節(jié)點(diǎn)來承擔(dān)。主從切換測試之前需要將dataHost 標(biāo)簽中的switchType 屬性值設(shè)置為1，并配置心跳檢測，停止Mysql 寫節(jié)點(diǎn)服務(wù)之后，進(jìn)行寫和讀操作，查看mycat.log 確認(rèn)讀和寫的SQL 被路由到Mysql 的哪個(gè)節(jié)點(diǎn)上，測試結(jié)果可知當(dāng)Mysql 寫節(jié)點(diǎn)宕機(jī)之后，讀和寫的操作全部由Mysql 的從節(jié)點(diǎn)來承載，從而實(shí)現(xiàn)了主從切換。

2.2 Mycat 高可用性測試

Haproxy 是專門用來檢測mycat 狀態(tài)和進(jìn)行負(fù)載均衡的軟件，Haproxy 負(fù)責(zé)將請(qǐng)求分發(fā)到Mycat上，實(shí)現(xiàn)了Mycat 多節(jié)點(diǎn)的集群高可用和負(fù)載均衡，通過監(jiān)聽Mycat 服務(wù)器的48700 端口來實(shí)現(xiàn)，通過檢測可知Mycat 狀態(tài)是否正常，如果正常則顯示為UP，如果異常則顯示為DOWN，同時(shí)可以查看Mycat服務(wù)運(yùn)行的時(shí)長。通過Haproxy 所在的其中一臺(tái)服務(wù)器訪問雙機(jī)熱備的mycat，本文選取第一臺(tái)Haproxy 的服務(wù)器，對(duì)訪問的幾種可能性進(jìn)行了測試，測試結(jié)果如表1 所示。從表1 可知Haproxy 只會(huì)將請(qǐng)求轉(zhuǎn)發(fā)到存活的Mycat 上，Haproxy 會(huì)自動(dòng)將宕機(jī)的Mycat 服務(wù)器從集群中移除，故障恢復(fù)后會(huì)自動(dòng)將Mycat 服務(wù)器添加到集群中，Haproxy 這些操作對(duì)用戶來說是完全透明的，即只要有一臺(tái)Mycat 的服務(wù)器正常，用戶都能夠?qū)?shù)據(jù)進(jìn)行訪問。

表1 HAProxy 高可用性測試結(jié)果

2.3 Keepalived＋Haproxy 高可用性測試

為了避免Haproxy 服務(wù)單點(diǎn)故障，文中將Haproxy部署為雙機(jī)熱備模式，即當(dāng)兩個(gè)節(jié)點(diǎn)上的任何一個(gè)Haproxy 服務(wù)在線，都能夠?qū)ν馓峁┓?wù)。Haproxy的高可用性是通過Keepalived 來實(shí)現(xiàn)的，Keepalived主要作用是負(fù)責(zé)搶占虛擬IP，搶占虛擬IP 有優(yōu)先級(jí)，一般主服務(wù)器比備服務(wù)器的優(yōu)先級(jí)高。通過模擬故障，對(duì)幾種組合進(jìn)行了測試，測試結(jié)果如表2，首先停止Haproxy 進(jìn)程，然后通過虛擬IP 訪問Haproxy 的Web 頁面，檢測該頁面是否能夠正常提供服務(wù)，比如，節(jié)點(diǎn)keep-ha-node1 上的Haproxy 服務(wù)停止后，通過虛擬IP 地址192.168.6.125（URL：http：／ ／192.168.6.125：8099／stats）訪問Haproxy 的Web 頁面正常，則表明當(dāng)節(jié)點(diǎn)keep-ha-node1 的Haproxy 服務(wù)宕機(jī)之后，節(jié)點(diǎn)keep-ha-node2 上的Keepalived 搶占了虛擬IP，虛擬IP 漂移到節(jié)點(diǎn)keep-ha-node2 上，保證了服務(wù)不中斷，實(shí)現(xiàn)了Haproxy 的高可用，其它組合情況測試類同。

2.4 分布式數(shù)據(jù)庫讀寫性能測試

為了能夠更準(zhǔn)確的測試分布式數(shù)據(jù)庫的性能，文中對(duì)單機(jī)Mysql 數(shù)據(jù)庫和基于Mycat 的分布式數(shù)據(jù)庫分別進(jìn)行了性能測試，使用sysbench-0.5［13］作為壓力測試工具，sysbench 是一個(gè)模塊化的、跨平臺(tái)和多線程基準(zhǔn)測試工具，主要用于評(píng)估各種不同系統(tǒng)參數(shù)下數(shù)據(jù)庫的負(fù)載情況。為了讓測試結(jié)果更可靠，在整個(gè)測試過程中，不允許測試的虛擬機(jī)在物理機(jī)之間進(jìn)行遷移，避免不同物理機(jī)對(duì)測試結(jié)果造成的影響。

表2 Keepalived＋HAproxy 高可用性測試結(jié)果

sysbench-0.5 對(duì)數(shù)據(jù)庫OLTP 基準(zhǔn)測試一般分為三個(gè)步驟：數(shù)據(jù)準(zhǔn)備階段；數(shù)據(jù)測試階段；數(shù)據(jù)清理階段。在數(shù)據(jù)準(zhǔn)備階段，共有10 張表，每個(gè)表插入1000 萬行數(shù)據(jù)，數(shù)據(jù)都是隨機(jī)產(chǎn)生的，10 張表的數(shù)據(jù)量大約為23GB，插入數(shù)據(jù)耗時(shí)26min。一般應(yīng)用都會(huì)存在熱點(diǎn)數(shù)據(jù)，同時(shí)innodb 引擎也是支持熱點(diǎn)數(shù)據(jù)，所以在測試過程中需要開啟熱點(diǎn)模式，取5%的熱點(diǎn)數(shù)據(jù)，壓測時(shí)間為1800s，并發(fā)數(shù)依次遞增｛8，16，32，64，128，256，512｝，每測試一個(gè)用例，需要清理主機(jī)的緩存和重啟Mysql 實(shí)例，防止緩存影響其它測試結(jié)果，sysbench 壓力測試工具中的腳本oltp.lua 中的參數(shù)oltp-read-only=on 表示只進(jìn)行讀操作，oltp-read-only=off 表示進(jìn)行讀寫操作，本文共進(jìn)行了兩組基準(zhǔn)壓力測試，分別記錄了TPS（Transactions Per Second，每秒處理的事務(wù)數(shù)）、QPS（Queries Per Second，每秒的查詢數(shù)）、平均響應(yīng)時(shí)間和95%的平均的響應(yīng)時(shí)間，響應(yīng)時(shí)間的單位為秒（s），在對(duì)每一個(gè)用例進(jìn)行測試的同時(shí)要監(jiān)控主機(jī)CPU、內(nèi)存和磁盤IO 的使用情況，從而可以快速的定位系統(tǒng)性能的瓶頸。

2.4.1 基準(zhǔn)測試一

基準(zhǔn)測試一是對(duì)單機(jī)Mysql 數(shù)據(jù)庫進(jìn)行性能測試，使用壓力測試工具中的oltp.lua 腳本，設(shè)置相關(guān)的參數(shù)，分別對(duì)Mysql 數(shù)據(jù)庫進(jìn)行只讀操作和讀寫操作的壓力測試，在測試的過程中，發(fā)現(xiàn)主機(jī)CPU的占有率非常高，使用perf 工具得知是熱點(diǎn)函數(shù)_raw_spin_lock 和ut_delay 占用CPU 資源，這兩個(gè)函數(shù)占用了78%的CPU 資源，這是由于鎖的爭用導(dǎo)致的。Mysql 提供了控制參數(shù)innodb_spin_wait_delay和innodb_sync_spin_loops 需要修改這兩個(gè)參數(shù)的值，修改后CPU 的使用率降低了，對(duì)單機(jī)Mysql 只讀壓力測試結(jié)果如表3，對(duì)單機(jī)Mysql 讀寫壓力測試結(jié)果如表4。

2.4.2 基準(zhǔn)測試二

基準(zhǔn)測試二是對(duì)基于Mycat 的分布式數(shù)據(jù)庫進(jìn)行性能測試，分布式數(shù)據(jù)庫的架構(gòu)為Mycat+Mysql+Haproxy+Keepalived，設(shè)置壓力測試工具中oltp.lua腳本相關(guān)的參數(shù)，分別進(jìn)行只讀和讀寫壓力測試，對(duì)分布式數(shù)據(jù)庫只讀的測試結(jié)果如表5 所示，對(duì)分布式數(shù)據(jù)庫讀寫的測試結(jié)果如表6 所示。

表3 單機(jī)Mysql 只讀壓力測試

表4 單機(jī)Mysql 讀寫壓力測試

表5 基于Mycat 分布式數(shù)據(jù)庫只讀壓力測試

表6 基于Mycat 分布式數(shù)據(jù)庫讀寫壓力測試

2.5 結(jié)果分析

表3 和表5 分別是對(duì)單點(diǎn)數(shù)據(jù)庫和分布式數(shù)據(jù)庫只讀壓力測試的結(jié)果，從表3 可知，當(dāng)并發(fā)量為128 時(shí)，Mysql 數(shù)據(jù)庫的性能最佳，QPS 可以達(dá)到12.4 萬，隨著并發(fā)量的增加，QPS 和TPS 在逐漸減小。平均響應(yīng)時(shí)間在不斷的增加，數(shù)據(jù)庫的性能在不斷的下降，系統(tǒng)出現(xiàn)了瓶頸，單點(diǎn)的數(shù)據(jù)庫已經(jīng)無法應(yīng)對(duì)高并發(fā)的數(shù)據(jù)量，從對(duì)比實(shí)驗(yàn)表5 可知，隨著并發(fā)量的增加，TPS 和QPS 的值一直在遞增，并發(fā)量越大，性能對(duì)比越明顯，平均響應(yīng)時(shí)間也要比單點(diǎn)數(shù)據(jù)庫小很多，表明了分布式數(shù)據(jù)庫的優(yōu)越性。表4 和表6 分別是對(duì)單點(diǎn)數(shù)據(jù)庫和分布式數(shù)據(jù)庫混合讀寫壓力測試的結(jié)果，從表4 可知，當(dāng)并發(fā)量為256 時(shí)，Mysql 數(shù)據(jù)庫的性能最佳，隨著并發(fā)量增加，TPS 和QPS 在不斷減小，平均響應(yīng)時(shí)間在增加，單點(diǎn)的數(shù)據(jù)庫性能已經(jīng)出現(xiàn)了瓶頸，從對(duì)比實(shí)驗(yàn)表6 可知，隨著并發(fā)量的增加，TPS 和QPS 的值一直在遞增，在同等的并發(fā)條件下，數(shù)據(jù)庫沒有出現(xiàn)瓶頸，從而驗(yàn)證了分布式數(shù)據(jù)庫集群架構(gòu)Mycat+Mysql+Haproxy+Keepalived 有效性和可行性。

3 結(jié)論與討論

為了避免收集與分發(fā)系統(tǒng)中Mysql 數(shù)據(jù)庫單點(diǎn)故障的問題，文中設(shè)計(jì)了基于Mycat+Mysql+Haproxy+Keepalived 的高可用分布式關(guān)系型數(shù)據(jù)庫集群系統(tǒng)，該架構(gòu)具有Mycat 高可用、Haproxy 高可用、Mysql 高可用、Mysql 讀寫分離的特點(diǎn)，同時(shí)對(duì)Mysql單點(diǎn)數(shù)據(jù)庫和基于Mycat 的分布式數(shù)據(jù)庫進(jìn)行了壓力測試，從不同的指標(biāo)評(píng)價(jià)了分布式數(shù)據(jù)庫架構(gòu)的性能，從測試結(jié)果可知該架構(gòu)可以實(shí)現(xiàn)對(duì)二維關(guān)系型氣象數(shù)據(jù)分散存儲(chǔ)和并發(fā)訪問服務(wù)。但是，隨著氣象數(shù)據(jù)的不斷增加，對(duì)分布式數(shù)據(jù)庫的彈性擴(kuò)展和性能調(diào)優(yōu)是必然的趨勢(shì)。

因此，在未來的研究工作中主要從以下幾個(gè)方面進(jìn)行開展：（1）分布式數(shù)據(jù)庫節(jié)點(diǎn)的擴(kuò)容，即對(duì)數(shù)據(jù)庫進(jìn)行彈性擴(kuò)展。（2）為了能夠提高數(shù)據(jù)查詢的吞吐量，考慮對(duì)數(shù)據(jù)庫進(jìn)行分庫和分表。（3）為了增強(qiáng)訪問的并發(fā)量，對(duì)Mycat 和Mysql 進(jìn)行調(diào)優(yōu)。