基于zookeeper和強(qiáng)一致性復(fù)制實(shí)現(xiàn)MySQL分布式數(shù)據(jù)庫(kù)集群

張旭剛，李東輝，俞俊，朱廣新，鄭磊

?

基于zookeeper和強(qiáng)一致性復(fù)制實(shí)現(xiàn)MySQL分布式數(shù)據(jù)庫(kù)集群

張旭剛，李東輝，俞俊，朱廣新，鄭磊

摘 要：目前MySQL數(shù)據(jù)庫(kù)間的復(fù)制技術(shù)主要有異步、半同步、同步等，這幾種技術(shù)存在各自的局限性和適用場(chǎng)景，很難滿足國(guó)家電網(wǎng)業(yè)務(wù)對(duì)分布式事務(wù)和性能的要求。結(jié)合國(guó)內(nèi)外先進(jìn)的框架和技術(shù)，利用zookeeper實(shí)現(xiàn)MySQL數(shù)據(jù)庫(kù)間復(fù)制的監(jiān)控和管理，并改進(jìn)MySQL數(shù)據(jù)庫(kù)的線程池，參考半同步技術(shù)模型實(shí)現(xiàn)數(shù)據(jù)庫(kù)間強(qiáng)一致性復(fù)制，融合以上兩種技術(shù)實(shí)現(xiàn)復(fù)制在毫秒級(jí)、高可靠和高性能的MySQL分布式數(shù)據(jù)庫(kù)集群。

關(guān)鍵詞：MySQL；zookeeper；強(qiáng)一致性

0 引言

MySQL的復(fù)制模式有異步、半同步、同步等模式。在MySQL發(fā)展的早期，采取異步復(fù)制技術(shù)，由于主數(shù)據(jù)庫(kù)只管把Binary Log發(fā)出去，而不關(guān)心從數(shù)據(jù)庫(kù)是否收到，主從數(shù)據(jù)庫(kù)間的數(shù)據(jù)不一致非常嚴(yán)重，通常是把從數(shù)據(jù)庫(kù)作為一種容災(zāi)和備份方案。到MySQL5.5后，提供了半同步模式，確保必須收到一個(gè)從數(shù)據(jù)庫(kù)的應(yīng)答才讓事務(wù)在主數(shù)據(jù)庫(kù)中提交，若備機(jī)應(yīng)答超時(shí)，強(qiáng)同步會(huì)自動(dòng)退化成異步模式，這種模式適用于局域網(wǎng)，當(dāng)跨數(shù)據(jù)中心時(shí)，時(shí)延較大，通常會(huì)工作在異步模式下，而且主數(shù)據(jù)庫(kù)等待從數(shù)據(jù)庫(kù)的應(yīng)答，影響主數(shù)據(jù)庫(kù)的性能。除了異步和半同步模式，還有同步集群方案，主要有MySQL NDB Cluster和MariaDB Galera Cluster，MySQL NDB Cluster基于全內(nèi)存，只支持Read Committed事務(wù)隔離級(jí)別，需要把引擎Innodb為NDB，需要高速網(wǎng)絡(luò)環(huán)境支持，而MariaDB Galera Cluster維護(hù)和管理復(fù)雜，在跨數(shù)據(jù)中心時(shí)，性能下降比較大。

為解決上述異步和半同步復(fù)制的缺陷，同步復(fù)制在跨數(shù)據(jù)中心時(shí)的性能降低問(wèn)題，本文提供一種強(qiáng)一致性主從數(shù)據(jù)庫(kù)復(fù)制方案，并通過(guò)zookeeper監(jiān)控和管理主從數(shù)據(jù)復(fù)制的一致性、主從數(shù)據(jù)庫(kù)的切換、服務(wù)器負(fù)載等，實(shí)現(xiàn)一種高性能、高可靠、易管理的分布式數(shù)據(jù)庫(kù)集群。

1 Zookeeper介紹和結(jié)構(gòu)

1.1 Zookeeper介紹

Zookeeper是一個(gè)分布式的協(xié)調(diào)服務(wù)，為分布式應(yīng)用提供統(tǒng)一命名服務(wù)、狀態(tài)同步服務(wù)、集群管理、分布式應(yīng)用配置項(xiàng)的管理等，由2n+1(n＞=1)服務(wù)器節(jié)點(diǎn)組成，這些節(jié)點(diǎn)中有一個(gè)主節(jié)點(diǎn)（leader），leader是通過(guò)leader selection自動(dòng)地從

服務(wù)器節(jié)點(diǎn)中選舉出來(lái)，其他節(jié)點(diǎn)角色為follower或observer。Zookeeper提供了一個(gè)類(lèi)似于標(biāo)準(zhǔn)文件系統(tǒng)目錄結(jié)構(gòu)的層次化的命名空間（hierarchal namespace）。如圖1所示：

圖1　層次化的命名空間

hierarchal namespace中的每一個(gè)節(jié)點(diǎn)都被稱為 znode。Znode是組成hierarchal namespace的基本單位。在源碼中對(duì)應(yīng)于類(lèi)DataNode，其維護(hù)著節(jié)點(diǎn)用戶數(shù)據(jù)、父節(jié)點(diǎn)和子節(jié)點(diǎn)集合，以及本節(jié)點(diǎn)狀態(tài)，用戶可以在hierarchal namespace中創(chuàng)建znode，將數(shù)據(jù)保存在znode中，并監(jiān)聽(tīng)znode的狀態(tài)變化，Zookeeper會(huì)保證client對(duì)znode的操作是順序一致性。

1.2 Zookeeper結(jié)構(gòu)

Zookeeper服務(wù)器節(jié)點(diǎn)的實(shí)現(xiàn)可以分成兩部分：一部分是處理與客戶端交互，實(shí)現(xiàn)客戶端對(duì)zookeeper的hierachal namespace的各種操作；另一部分是作為zab算法（paxos算法的zookeeper實(shí)現(xiàn)）的參與者（leader、follower、observer3種角色的其中一種），實(shí)現(xiàn)具體的算法邏輯。

Zookeeper服務(wù)器的hierachal namespace、znode、客戶端與服務(wù)器連接、以及客戶端可以監(jiān)聽(tīng)服務(wù)器的znode狀態(tài)的watch機(jī)制之間的元數(shù)據(jù)關(guān)系如圖2所示：

圖2　Zookeeper 組件關(guān)系圖

Zookeeper使用Trie樹(shù) 來(lái)實(shí)現(xiàn)了hierachal namespace，由PathTrie這個(gè)類(lèi)來(lái)完成。為了實(shí)現(xiàn)從路徑到znode的映射，zookeeper在內(nèi)存中維護(hù)了一個(gè)znode的hashmap，key為znode在hierachal namespace上的路徑，value為znode對(duì)象，znode在zookeeper源碼中由DataNode這個(gè)類(lèi)實(shí)現(xiàn)。為了實(shí)現(xiàn)client監(jiān)聽(tīng)znode的狀態(tài)變化，zookeeper將與客戶端的連接和hierachal namespace的節(jié)點(diǎn)路徑進(jìn)行映射，WatchManager這個(gè)類(lèi)就是用于維護(hù)這個(gè)映射關(guān)系的，其中NIOServerCnxn是zookeeper服務(wù)器與client的一個(gè)socket連接；為了監(jiān)聽(tīng)Znode的目錄結(jié)構(gòu)的變化和數(shù)據(jù)變化，zookeeper使用了兩個(gè)WatchManager，分別用來(lái)監(jiān)聽(tīng)namespace的目錄結(jié)構(gòu)和數(shù)據(jù)的變化。

在paxos算法中有3種角色，分別是提案者，接受者和學(xué)習(xí)者，與在zookeeper中的3種節(jié)點(diǎn)類(lèi)型對(duì)應(yīng)，即leader、follower和observer3種類(lèi)型的節(jié)點(diǎn)，其中observer節(jié)點(diǎn)只能學(xué)習(xí)已經(jīng)批準(zhǔn)的提案，而不會(huì)參與到提案的投票過(guò)程中，這個(gè)角色的設(shè)定是為了保證提案選舉的性能不會(huì)隨著zookeeper集群規(guī)模擴(kuò)大而降低。角色間的信令交互如圖3所示：

圖3　角色交互圖

2 Zookeeper設(shè)計(jì)與實(shí)現(xiàn)

基于zookeeper實(shí)現(xiàn)的MySQL強(qiáng)一致性復(fù)制集群，主要由zookeeper、agent和MySQL等組件組成，zookeeper作為系統(tǒng)的協(xié)調(diào)器，監(jiān)控和管理系統(tǒng)資源，agent部署在MySQL上，負(fù)責(zé)向Scheduler上報(bào)MySQL實(shí)例的狀態(tài)，包括實(shí)例的可用性、復(fù)制的一致性、服務(wù)器負(fù)載等，由mysqlreport和mysqltransfer兩個(gè)模塊構(gòu)成，mysqltransfer用于自動(dòng)擴(kuò)容，mysqlreport用于上報(bào)心跳信息、資源信息?？傮w結(jié)構(gòu)如圖4所示：

圖4　系統(tǒng)結(jié)構(gòu)圖

2.1 主從一致性監(jiān)控

主從數(shù)據(jù)庫(kù)的一致性監(jiān)控通常是在從庫(kù)上執(zhí)行語(yǔ)句show slave statusG獲取Seconds_Behind_Master參數(shù)的值來(lái)判斷，但這個(gè)值通常不能反映主從數(shù)據(jù)庫(kù)一致性的真實(shí)情況。Seconds_Behind_Master是通過(guò)比較sql_thread執(zhí)行的event 的timestamp和io_thread復(fù)制的 event的timestamp進(jìn)行比較得到的一個(gè)差值。當(dāng)主庫(kù)I/O負(fù)載很大或是網(wǎng)絡(luò)阻塞，io_thread復(fù)制binlog的速度會(huì)非常慢或停滯，此時(shí)sql_thread一直都能及時(shí)應(yīng)用io_thread的復(fù)制，Seconds_Behind_Master的值是0，表示是沒(méi)有無(wú)延時(shí)的，實(shí)際主從數(shù)據(jù)一致性延遲非常嚴(yán)重。

為解決以上問(wèn)題，本文通過(guò)在主從數(shù)據(jù)庫(kù)上創(chuàng)建一張表SysDB.StatusTable，dbagent將當(dāng)前當(dāng)前時(shí)間戳、ip、端口通過(guò)replace into方式寫(xiě)入SysDB.StatusTable表，mysqlreport默認(rèn)3秒連接一次mysql，并對(duì)sysdb.statustable表進(jìn)行讀操作，根據(jù)master同步過(guò)來(lái)的時(shí)間、slave寫(xiě)入的時(shí)間進(jìn)行相減，計(jì)算出時(shí)間差值作為延遲的時(shí)間，將以上獲取的數(shù)據(jù)庫(kù)信息寫(xiě)入zookeeper的hb@IP地址_端口號(hào)位置上，寫(xiě)入信息：{"agentbindport":"57086","autorebuildms":"1","conn_err":

"0","conn_info":"","delay":"0","gtiddelay":"","read_err":" 0","read_info":"","repl":"0","svrtype":"master","ver":"1.0","wri te_err":"0","write_info":""}，其中delay值代表主從數(shù)據(jù)復(fù)制的延遲，單位為秒，0表示無(wú)延遲，結(jié)構(gòu)圖如圖5所示：

圖5　復(fù)制一致性設(shè)計(jì)圖

通過(guò)以上方式，能準(zhǔn)確獲取主從數(shù)據(jù)庫(kù)的一致性延遲，如果延遲超過(guò)設(shè)置的閾值，則在主庫(kù)宕機(jī)從庫(kù)承擔(dān)讀寫(xiě)角色時(shí)，從庫(kù)只能讀不能寫(xiě)。

2.2 資源監(jiān)控

在MySQL分布式集群系統(tǒng)中，有多種系統(tǒng)資源需要監(jiān)控，并根據(jù)結(jié)果做出反應(yīng)，主要的監(jiān)控資源有CPU的使用率、磁盤(pán)使用率、磁盤(pán)IO、MySQL數(shù)據(jù)庫(kù)狀態(tài)信息等，如圖6所示：

圖6　系統(tǒng)資源監(jiān)控設(shè)計(jì)圖

放到zookeeper的相關(guān)目錄下，進(jìn)行統(tǒng)一管理，并通過(guò)界面查看各資源信息，進(jìn)行優(yōu)化。

實(shí)際步驟是mysqlreport根據(jù)mysql的my.cnf文件，找到數(shù)據(jù)文件日志和日志目錄， mysqlreport調(diào)用C語(yǔ)言的statfs函數(shù)分析mysql的數(shù)據(jù)文件、binlog文件在磁盤(pán)使用情況，mysqlreport獲取只是統(tǒng)計(jì)數(shù)據(jù)文件及binlog的根目錄大小，同時(shí)mysqlreport連接到mysql通過(guò)show global statusG命令獲取Com_select、Com_update、Com_insert、Slow_queries等信息，Mysqlreport默認(rèn)5秒一次將收集到的數(shù)據(jù)上傳到zookpeeper的rsinfo@IP_端口號(hào)目錄下。

通過(guò)獲取以上信息，當(dāng)數(shù)據(jù)庫(kù)的資源使用率超過(guò)設(shè)置閾值時(shí)，調(diào)用策略應(yīng)對(duì)，如當(dāng)CPU使用率超過(guò)95%時(shí)，進(jìn)行主從切換，防止數(shù)據(jù)庫(kù)宕機(jī)。

3 強(qiáng)一致性復(fù)制設(shè)計(jì)與實(shí)現(xiàn)

在分布式數(shù)據(jù)系統(tǒng)中，有一個(gè)CAP原理，由三個(gè)要素組成，包括一致性(Consistency)、可用性(Availability)和分區(qū)容忍性(Partition tolerance)，這3個(gè)要素最多只能同時(shí)實(shí)現(xiàn)兩點(diǎn)，不可能三者兼顧。對(duì)于分布式數(shù)據(jù)系統(tǒng)，分區(qū)容忍性是基本要求，否則就失去了價(jià)值，因此設(shè)計(jì)分布式數(shù)據(jù)系統(tǒng)，就是在一致性和可用性之間取一個(gè)平衡。對(duì)于大多數(shù)應(yīng)用系統(tǒng)，并不需要強(qiáng)一致性，因而犧牲一致性而換取高可用性，是目前多數(shù)分布式數(shù)據(jù)庫(kù)產(chǎn)品的方向。

但在計(jì)費(fèi)、ERP等系統(tǒng)中，對(duì)數(shù)據(jù)的一致性要求很高，數(shù)據(jù)庫(kù)承受的壓力也很大，在保證可用性和分區(qū)容忍性的同時(shí)，盡可能提高數(shù)據(jù)一致性的實(shí)時(shí)性，使產(chǎn)品具有更廣泛的應(yīng)用場(chǎng)景。

3.1 MySQL復(fù)制技術(shù)的發(fā)展

在MySQL發(fā)展的早期，就提供了異步復(fù)制的技術(shù)，Mysql 主數(shù)據(jù)庫(kù)將自己的Binary Log通過(guò)復(fù)制線程傳輸出去以后，Mysql 主數(shù)據(jù)庫(kù)就自動(dòng)返回?cái)?shù)據(jù)給客戶端，而不關(guān)系從數(shù)據(jù)庫(kù)是否接受到了這個(gè)二進(jìn)制日志，異步復(fù)制模型如圖7所示：

圖7　異步復(fù)制模型

到了MySQL 5.5版本，google提供了一個(gè)半同步半異步的插件，當(dāng)主數(shù)據(jù)庫(kù)在將自己binlog發(fā)給從數(shù)據(jù)庫(kù)后，要確保從數(shù)據(jù)庫(kù)已經(jīng)接受到了這個(gè)二進(jìn)制日志，才會(huì)返回?cái)?shù)據(jù)給客戶端，通過(guò)收到一個(gè)從數(shù)據(jù)庫(kù)的應(yīng)答來(lái)實(shí)現(xiàn)；當(dāng)備機(jī)應(yīng)答超時(shí)時(shí)，強(qiáng)同步就會(huì)自動(dòng)退化成異步模式，復(fù)制模型如下圖8所示：

圖8　半同步復(fù)制模型

半同步方案相對(duì)異步復(fù)制，在數(shù)據(jù)的可靠性方面得到了提高，若主數(shù)據(jù)庫(kù)故障則最后一個(gè)事務(wù)，至少在一個(gè)從數(shù)據(jù)庫(kù)上存在。但在主從數(shù)據(jù)庫(kù)跨數(shù)據(jù)中心時(shí)，性能非常很低。

除了異步和半同步，還有同步方案，典型的有MySQL NDB Cluster、MariaDB Galera Cluster等，MySQL NDB Cluster基于全內(nèi)存，只支持Read Committed事務(wù)隔離級(jí)別，需要把引擎Innodb改為NDB，需要高速網(wǎng)絡(luò)環(huán)境支持，應(yīng)用范圍窄。MariaDB Galera Cluster 是一套在mysql innodb存儲(chǔ)引擎上面實(shí)現(xiàn)multi-master及數(shù)據(jù)實(shí)時(shí)同步的系統(tǒng)架構(gòu)，業(yè)務(wù)層面無(wú)需做讀寫(xiě)分離工作，數(shù)據(jù)庫(kù)讀寫(xiě)壓力都能按照既定的規(guī)則分發(fā)到各個(gè)節(jié)點(diǎn)上去，具有如下特點(diǎn)：

（1）同步復(fù)制；

（2）多主的拓?fù)浣Y(jié)構(gòu)，可以認(rèn)為沒(méi)有備機(jī)的概念；（3）可對(duì)集群中任一節(jié)點(diǎn)進(jìn)行數(shù)據(jù)讀寫(xiě)；

（4）自動(dòng)成員控制，故障節(jié)點(diǎn)自動(dòng)從集群中移除；（5）自動(dòng)節(jié)點(diǎn)加入；

（6）真正并行的復(fù)制，基于行級(jí)；

（7）每個(gè)節(jié)點(diǎn)都包含完整的數(shù)據(jù)副本。

MariaDB Galera Cluster在功能實(shí)現(xiàn)上非常完美，但管理和維護(hù)困難，在跨數(shù)據(jù)中心時(shí)，性能損耗較大。

3.2 性能分析

如圖9所示：

圖9　同步模式對(duì)比

從上圖9可以看出，在跨數(shù)據(jù)中心時(shí)，半同步、同步復(fù)制的性能損耗非常嚴(yán)重，這與MySQL前期版本采用的每個(gè)連接一個(gè)線程的模型有關(guān)，該模型的優(yōu)勢(shì)在于開(kāi)發(fā)特別簡(jiǎn)單，線程內(nèi)部都是同步調(diào)用，只要不訪問(wèn)外部接口，支撐每秒上千的請(qǐng)求量也夠用，因?yàn)榇蟛糠智闆r下IO是瓶頸。不過(guò)隨著當(dāng)前硬件的發(fā)展，尤其是SSD、FusionIO的出現(xiàn)，IOPS從每秒200+發(fā)展到每秒幾十萬(wàn)甚至百萬(wàn)次，IO基本上不再是瓶頸，如再采用這套模型并采用阻塞的方式調(diào)用延遲較大的外部接口，則CPU會(huì)阻塞在等網(wǎng)絡(luò)應(yīng)答上了，性能自然下降。

3.3 強(qiáng)一致性復(fù)制實(shí)現(xiàn)

在MySQL5.6企業(yè)版和MariaDB、Percona中引入了線程池，優(yōu)勢(shì)在于線程處理的最小單位是statement(語(yǔ)句)，一個(gè)線程可以處理多個(gè)連接的請(qǐng)求。這樣，在保證充分利用硬件資源情況下(合理設(shè)置線程池大小)，可以避免瞬間連接數(shù)暴增導(dǎo)致的服務(wù)器抖動(dòng)，線程池的實(shí)現(xiàn)模型如圖10所示：

圖10　線程池模型

每一個(gè)綠色的方框代表一個(gè)group，group數(shù)目由thread_pool_size參數(shù)決定。每個(gè)group包含一個(gè)優(yōu)先隊(duì)列和普通隊(duì)列，包含一個(gè)listener線程和若干個(gè)工作線程，listener線程和worker線程可以動(dòng)態(tài)轉(zhuǎn)換，worker線程數(shù)目由工作負(fù)載決定，同時(shí)受到thread_pool_oversubscribe設(shè)置影響。此外，整個(gè)線程池有一個(gè)timer線程監(jiān)控group，防止group“停滯”。

一個(gè)連接一個(gè)線程與線程池的對(duì)比如圖11所示：

圖11　線程模型對(duì)比

從上面的分析可知，半同步半異步是較輕量級(jí)的高一致性容災(zāi)方案，但是受限于已有的同步網(wǎng)絡(luò)模型，CPU利用不起來(lái)。如果在線程池基礎(chǔ)之上做一些修改，參考半同步的思路就可以實(shí)現(xiàn)一個(gè)高性能的強(qiáng)同步方案。

目前的做法是采用與Linux內(nèi)核處理中斷的思路：將上面線程池模型的第三個(gè)環(huán)節(jié)（執(zhí)行SQL的邏輯）拆成2個(gè)部分：

（1）上半部分，任務(wù)執(zhí)行到寫(xiě)binlog為止，然后將會(huì)話保存到session中，接著執(zhí)行下一輪循環(huán)去處理其他請(qǐng)求了，這樣就避免讓線程阻塞等待應(yīng)答了；

（2）然后MySQL自身負(fù)責(zé)主備同步的dump線程會(huì)將binlog立即發(fā)送出去，備機(jī)的io線程收到binlog并寫(xiě)入到relay log之后，再通過(guò)udp給主機(jī)一個(gè)應(yīng)答；

（3）在主機(jī)上，開(kāi)一組線程來(lái)處理應(yīng)答，收到應(yīng)答之后找到對(duì)應(yīng)的會(huì)話，執(zhí)行下半部分的commit，send應(yīng)答，綁定到epoll等操作。綁定到epoll之后這個(gè)連接又可以被其它線程檢測(cè)到并執(zhí)行了。

流程圖如圖12所示：

圖12　強(qiáng)一致性復(fù)制流程圖

該同步方案完全獨(dú)立于原生的主從復(fù)制系統(tǒng)，屬于新開(kāi)發(fā)功能，同時(shí)強(qiáng)同步的概念是從整個(gè)MySQL分布式數(shù)據(jù)庫(kù)集群上來(lái)看的，保證數(shù)據(jù)在切換、或進(jìn)行讀寫(xiě)分離時(shí)數(shù)據(jù)的一致性。當(dāng)主備數(shù)據(jù)延遲超過(guò)了一定的閥值時(shí)（可配置），就不會(huì)發(fā)生主從切換、進(jìn)行讀寫(xiě)分離操作，與半同步方案的差別：

（1）當(dāng)備機(jī)應(yīng)答超時(shí)的情況下，半同步就不會(huì)自動(dòng)退化成異步模式；

（2）線程池優(yōu)化，在主機(jī)上開(kāi)啟單獨(dú)的多線程來(lái)處理從機(jī)寫(xiě)入relaylog后的應(yīng)答實(shí)現(xiàn)連接的復(fù)用，提高效率。

4 總結(jié)

基于zookeeper與強(qiáng)一致性復(fù)制的分布式數(shù)據(jù)庫(kù)集群，易于部署、管理和維護(hù)，數(shù)據(jù)一致性實(shí)時(shí)性高，可靠性得到保證，已在國(guó)網(wǎng)多個(gè)業(yè)務(wù)系統(tǒng)中應(yīng)用，實(shí)踐效果良好。但也存在需要改進(jìn)和擴(kuò)展的方向，如zookeeper在使用過(guò)程中存在占用內(nèi)存過(guò)高的現(xiàn)象，同時(shí)擴(kuò)展dbagent功能模塊，實(shí)現(xiàn)彈性計(jì)算，如容量按需自動(dòng)收縮、數(shù)據(jù)在線搬遷等，是今后研究和設(shè)計(jì)的方向。

參考文獻(xiàn)

[1] Flavio Junqueira，Benjamin Reed．ZooKeeper: Distributed Process Coordination[M].O'Reilly Media,2013,12,210-333.

[2] 曾大聃,周傲英.Hadoop 權(quán)威指南(第二版-中文版)[M].北京:清華大學(xué)出版社,2011(1):88-89．

[3] 鄧鵬,李枚毅,何 誠(chéng).Namenode 單點(diǎn)故障解決方案研究[J].計(jì)算機(jī)工程,2012, 38(21):25-44．

[4] PatrickHunt，MahadevKonar，F(xiàn)lavioPJunqueira，BenjaminReedZooKeeper:Wait-freecoordinationforIntem etscalesystemsUSENIXAnnualTechnologyConference[C] .2011:2-3.

[5] 葉謙.Zookeeper初步調(diào)研報(bào)告[J]．計(jì)算機(jī)技術(shù)與發(fā)展,2011,7(7):15-25.

[6] 倪超.從Paxos到Zookeeper[M].北京:電子工業(yè)出版社,2015:43-61.

[7] Marco Aiello.leader_election[M].Distributed system.2011,1:5-9.

[8] 雷明.fast paxos算法與Zookeeper leader選舉源代碼分析[J].計(jì)算機(jī)技術(shù)與發(fā)展,2015.3,3(04):3-20.

[9] ZooKeeper: Because Coordinating Distributed Systems is a Zoo[J/OL]。Science,2014,3 (http://zookeeper.apache.org/doc/r3.4.6/ /).

MySQL Distributed Database Cluster Based on Zookeeper and Strong Consistency

Zhang Xugang, Li Donghui, Yu Jun, ZhuGuangxin, Zheng Lei
(Information System Integration Company, Nari Group Cooperation, Nanjing 210000, China)

Abstract:At present, the replication technology between MySQL mainly contains asynchronization, semi-synchronization and synchronization. These technologies have respective limits and suitable scenarios, and that make them hardly meet the requirements for distributed affairs and performances of State Grid Corporation of China. This paper uses zookeeper to realize the monitoring and management of replication between MySQL databases and improves the thread pool of MySQL databases, combining with the advanced framework and technology of home and abroad. It consults the semi-synchronization model to realize the strong consistence replication between the databases, and it also fuses the two above technologies to realize the replication on the millisecond, high reliability and performance MySQL distributed database groups.

Key words:MySQL; Zookeeper; Strong Consistency

收稿日期：（2015.10.13）

作者簡(jiǎn)介：張旭剛（1979-），南京南瑞集團(tuán)公司信息系統(tǒng)集成分公司，助理工程師，研究方向：計(jì)算機(jī)應(yīng)用技術(shù)，南京，211000李東輝（1970-），南京南瑞集團(tuán)公司信息系統(tǒng)集成分公司，高級(jí)工程師，研究方向：電力系統(tǒng)通信信息，南京，211000 俞 ?。?978-），南京南瑞集團(tuán)公司信息系統(tǒng)集成分公司，高級(jí)工程師，研究方向：電力系統(tǒng)通信信息，南京，211000朱廣新（1981-），南京南瑞集團(tuán)公司信息系統(tǒng)集成分公司，工程師，研究方向：模式識(shí)別與智能系統(tǒng)，南京，211000 鄭 磊（1972-），南京南瑞集團(tuán)公司信息系統(tǒng)集成分公司，助理工程師，研究方向：電力系統(tǒng)通信信息，南京，211000

文章編號(hào)：1007-757X(2016)01-0077-04

中圖分類(lèi)號(hào)：TP393

文獻(xiàn)標(biāo)志碼：A