熊游泳

摘要：隨著4G網(wǎng)絡(luò)和移動(dòng)互聯(lián)網(wǎng)業(yè)務(wù)的迅猛發(fā)展，面對(duì)海量數(shù)據(jù)處理、高并發(fā)交易的壓力，傳統(tǒng)的集中式數(shù)據(jù)庫(kù)如Oracle基本不支持大規(guī)模自動(dòng)擴(kuò)展，逐漸表現(xiàn)出其局限性。中國(guó)電信基于開源的Mysql數(shù)據(jù)庫(kù)和Mycat分布式數(shù)據(jù)庫(kù)中間件，結(jié)合企業(yè)實(shí)際，自主研發(fā)的分布式數(shù)據(jù)庫(kù)系統(tǒng)在湖南電信IT系統(tǒng)中得到廣泛應(yīng)用，解決了海量交易型業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)和高效訪問(wèn)的難題，實(shí)現(xiàn)了低成本、高性能、高可用、高擴(kuò)展，有利的支撐了企業(yè)IT架構(gòu)互聯(lián)網(wǎng)化轉(zhuǎn)型。

關(guān)鍵詞：MySQL;Mycat;分布式數(shù)據(jù)庫(kù)

中圖分類號(hào)：TP391 文獻(xiàn)標(biāo)識(shí)碼：A

文章編號(hào)：1009-3044（2019）32-0018-05

1概述

湖南電信自1995年“九七工程”建設(shè)第一個(gè)IT系統(tǒng)開始，截止到2017年底，已建成的IT系統(tǒng)達(dá)到288套。其中近95%的系統(tǒng)使用的是Oracle RAC數(shù)據(jù)庫(kù)。進(jìn)入互聯(lián)網(wǎng)時(shí)代以來(lái)，特別是近幾年，隨著4G網(wǎng)絡(luò)和移動(dòng)互聯(lián)網(wǎng)業(yè)務(wù)的迅猛發(fā)展，電信核心系統(tǒng)數(shù)據(jù)量均出現(xiàn)了大規(guī)模的增長(zhǎng)，以計(jì)費(fèi)系統(tǒng)為例，每月的清單數(shù)據(jù)量從2014年的5TB增長(zhǎng)到2019年的30TB，5年時(shí)間數(shù)據(jù)量增長(zhǎng)近6倍，由于原有系統(tǒng)Oracle RAC的shared ev-erything的架構(gòu)，10的處理能力及擴(kuò)展能力有限，并且隨著節(jié)點(diǎn)數(shù)的增加，數(shù)據(jù)庫(kù)系統(tǒng)的穩(wěn)定性和高性能難以保障。因此，海量數(shù)據(jù)的存儲(chǔ)、處理與訪問(wèn)成為當(dāng)時(shí)湖南電信乃至整個(gè)中國(guó)電信IT系統(tǒng)設(shè)計(jì)與使用中亟待解決的問(wèn)題。

中國(guó)電信自2017年開始，對(duì)標(biāo)業(yè)界領(lǐng)先公司，采用主流互聯(lián)網(wǎng)公司技術(shù)路線，基于開源的Mysql數(shù)據(jù)庫(kù)和Mycat分布式數(shù)據(jù)庫(kù)中間件，結(jié)合企業(yè)實(shí)際，自主研發(fā)了高性能、高可用、高擴(kuò)展的分布式數(shù)據(jù)庫(kù)，在低成本、可擴(kuò)展、快速響應(yīng)等方面擁有巨大優(yōu)勢(shì)，成為湖南電信企業(yè)級(jí)rr架構(gòu)的發(fā)展方向。

2分布式數(shù)據(jù)庫(kù)概念的提出

Oracle、Mysql等傳統(tǒng)的關(guān)系數(shù)據(jù)庫(kù)非常成熟并且已大規(guī)模商用，為什么還要用分布式數(shù)據(jù)庫(kù)呢？主要是由于中國(guó)互聯(lián)網(wǎng)業(yè)務(wù)的迅猛發(fā)展，所生成的海量數(shù)據(jù)對(duì)存儲(chǔ)、處理、訪問(wèn)的性能要求越來(lái)越高，傳統(tǒng)數(shù)據(jù)庫(kù)存在著先天性的缺陷，即單機(jī)性能有限，擴(kuò)展困難，且隨著節(jié)點(diǎn)數(shù)的增加，數(shù)據(jù)庫(kù)系統(tǒng)的穩(wěn)定性和高性能難以保障，已經(jīng)無(wú)法滿足海量數(shù)據(jù)存儲(chǔ)及高性能訪問(wèn)的要求。因此，業(yè)界提出了分布式數(shù)據(jù)庫(kù)的概念。簡(jiǎn)單來(lái)說(shuō)，分布式數(shù)據(jù)庫(kù)是采用分庫(kù)分表等數(shù)據(jù)切分的方式提供可擴(kuò)展的數(shù)據(jù)存儲(chǔ)，并且采用數(shù)據(jù)庫(kù)代理方式為應(yīng)用提供透明訪問(wèn)及平滑擴(kuò)縮容能力，包括數(shù)據(jù)的存儲(chǔ)與數(shù)據(jù)的訪問(wèn)兩部分的內(nèi)容。

3分布式數(shù)據(jù)庫(kù)的數(shù)據(jù)切分

分布式數(shù)據(jù)庫(kù)的數(shù)據(jù)存儲(chǔ)通過(guò)數(shù)據(jù)切分的方式，按照特定的規(guī)則，將一個(gè)數(shù)據(jù)庫(kù)中的數(shù)據(jù)分散存放到多個(gè)數(shù)據(jù)庫(kù)里面，從而將單臺(tái)數(shù)據(jù)庫(kù)的負(fù)載分散到多個(gè)數(shù)據(jù)庫(kù)。

數(shù)據(jù)的切分可以分為垂直切分與水平切分兩種切分模式。按照業(yè)務(wù)的不同，對(duì)表進(jìn)行分類，不同業(yè)務(wù)的表切分到不同的數(shù)據(jù)庫(kù)稱為垂直切分;按照表中某個(gè)字段的特定規(guī)則將數(shù)據(jù)分散到多個(gè)庫(kù)之中，每個(gè)表都包含部分?jǐn)?shù)據(jù)，稱為水平切分。水平切分可以理解為是按照數(shù)據(jù)行進(jìn)行的切分，表中的一部分行切分到一個(gè)數(shù)據(jù)庫(kù)，而另外的一部分行又切分到其他的數(shù)據(jù)庫(kù)中，分布式數(shù)據(jù)庫(kù)一般使用的是水平切分的方式。

垂直切分一般來(lái)說(shuō)規(guī)則比較簡(jiǎn)單，實(shí)施比較方便，對(duì)于業(yè)務(wù)邏輯清晰，業(yè)務(wù)之間的耦合度較低的系統(tǒng)尤其適合。在湖南電信BSS3.0系統(tǒng)中就按照相對(duì)獨(dú)立的業(yè)務(wù)垂直切分為受理中心數(shù)據(jù)庫(kù)、賬務(wù)中心數(shù)據(jù)庫(kù)、計(jì)費(fèi)中心數(shù)據(jù)庫(kù)、策略中心數(shù)據(jù)庫(kù)、客服中心數(shù)據(jù)庫(kù)等。由于垂直切分是按照不同的業(yè)務(wù)的分類將表分散到不同的庫(kù)，不可避免地存在一些業(yè)務(wù)表會(huì)過(guò)于龐大、單庫(kù)讀寫性能與存儲(chǔ)瓶頸的問(wèn)題，例如經(jīng)過(guò)垂直切分后的計(jì)費(fèi)中心數(shù)據(jù)庫(kù)依然存在單表數(shù)據(jù)量過(guò)大的問(wèn)題，此時(shí)就需要進(jìn)行進(jìn)一步的水平拆分來(lái)做解決。

水平切分相對(duì)于垂直切分來(lái)說(shuō)，由于要將同一個(gè)表中的不同數(shù)據(jù)拆分到不同的數(shù)據(jù)庫(kù)中，拆分規(guī)則及后期的數(shù)據(jù)維護(hù)及數(shù)據(jù)訪問(wèn)也會(huì)更為復(fù)雜一些。在數(shù)據(jù)的水平切分過(guò)程中，數(shù)據(jù)容量和訪問(wèn)的均衡性是我們首要考量的因素，不均衡的數(shù)據(jù)分布和訪問(wèn)無(wú)法充分發(fā)揮數(shù)據(jù)拆分的能力，讓訪問(wèn)體驗(yàn)變差，同時(shí)帶來(lái)成本上的損耗。一般來(lái)說(shuō)拆分字段區(qū)分度比較大，數(shù)據(jù)分布和訪問(wèn)相對(duì)會(huì)比較均衡，同時(shí)也需要考慮到某一個(gè)拆分值是否存在熱點(diǎn)訪問(wèn)的問(wèn)題。此外，事務(wù)邊界越大或者單個(gè)sql所執(zhí)行的數(shù)據(jù)分片數(shù)越大，那么系統(tǒng)的鎖沖突概率越高，系統(tǒng)越難以擴(kuò)展，性能越低。因此，若想將系統(tǒng)做到很好的擴(kuò)展性，那么一個(gè)最重要的原則就是想辦法劃小事務(wù)邊界，并盡可能讓事務(wù)的邊界限制在單臺(tái)機(jī)器內(nèi)。

3.1數(shù)據(jù)切分的原則

分表分庫(kù)雖然能解決大表對(duì)數(shù)據(jù)庫(kù)系統(tǒng)的壓力，但它并不是萬(wàn)能的，也有一些不利之處，通過(guò)結(jié)合在湖南電信的應(yīng)用實(shí)踐，數(shù)據(jù)切分一般要遵守以下幾個(gè)原則。

分片數(shù)量盡量少，分片盡量均勻分布在多個(gè)庫(kù)上，因?yàn)橐粋€(gè)查詢SQL跨分片越多，則總體性能越差，只在必要的時(shí)候進(jìn)行擴(kuò)容，增加分片數(shù)量。

能不分片就不分片，800萬(wàn)行以內(nèi)的表，不建議分片，通過(guò)合適的索引，讀寫分離等方式，可以很好地解決性能問(wèn)題。

不到800萬(wàn)但跟大表（超800萬(wàn)的表）有關(guān)聯(lián)查詢的表也要拆分，在此稱為大表關(guān)聯(lián)表。大表關(guān)聯(lián)表如何拆：小于100萬(wàn)的使用全局表;大于100萬(wàn)小于800萬(wàn)跟大表使用同樣的拆分策略;無(wú)法跟大表使用相同規(guī)則的，可以考慮從iava代碼上分步驟查詢，不用關(guān)聯(lián)查詢，或者破例使用全局表。

拆分字段只能是一個(gè)字段，如果想按照兩個(gè)字段拆分，必須新建一個(gè)冗余字段，冗余字段的值使用兩個(gè)字段的值拼接而成（如大xE+年月拼成zone_yyyymm字段）。

分片規(guī)則需要慎重選擇，分片規(guī)則的選擇，需要考慮數(shù)據(jù)的增長(zhǎng)模式，數(shù)據(jù)的訪問(wèn)模式，分片關(guān)聯(lián)性問(wèn)題，分片擴(kuò)容問(wèn)題以及數(shù)據(jù)熱點(diǎn)問(wèn)題。如果某個(gè)表的數(shù)據(jù)有明顯的時(shí)間特征，比如訂單、交易記錄等，則他們通常比較合適用時(shí)間范圍分片，因?yàn)榫哂袝r(shí)效性的數(shù)據(jù)，我們往往關(guān)注其近期的數(shù)據(jù)，查詢條件中往往帶有時(shí)間字段進(jìn)行過(guò)濾，比較好的方案是，當(dāng)前活躍的數(shù)據(jù)，采用跨度比較短的時(shí)間段進(jìn)行分片，而歷史性的數(shù)據(jù)，則采用比較長(zhǎng)的跨度存儲(chǔ)?？傮w上來(lái)說(shuō)，分片的選擇是取決于最頻繁的查詢SQL的條件。

3.2水平切分的常用算法

水平切分的算法根據(jù)分片鍵類型的不同主要有以下幾種：

取模分片（PartitionByMod）是對(duì)整數(shù)型分片鍵進(jìn)行十進(jìn)制求模，根據(jù)模值對(duì)應(yīng)到不同分片。適用于分片鍵是整數(shù)類型，分片鍵求余后的值均勻分布的場(chǎng)景。其特點(diǎn)是算法簡(jiǎn)單，性能高，由于分片鍵相鄰的數(shù)據(jù)分散在不同的分片上故對(duì)多值、范圍的查詢支持較差。

字符串hashCode取模分片（PartitionByStringMod）是對(duì)字符型分片字段的值先進(jìn)行hashcode（）計(jì)算并取其絕對(duì)值，然后根據(jù)配置的分片數(shù)量求模得到最終的分片。由于是對(duì)字符串先hash再取模，數(shù)據(jù)分布較不均勻。

枚舉分片（PartitionByFileMap）是根據(jù)配置文件中枚舉的具體值（允許非數(shù)值）與分片號(hào)的對(duì)應(yīng)關(guān)系和分片字段的值進(jìn)行分片，當(dāng)未找到對(duì)應(yīng)分片時(shí)，進(jìn)入到設(shè)定的默認(rèn)分片。數(shù)據(jù)分布的均勻度取決于枚舉值對(duì)應(yīng)的記錄是否分布均勻，較好的支持多值、范圍的查詢。電信有些業(yè)務(wù)數(shù)據(jù)需要按照省份或市縣來(lái)做保存，而省份市縣相對(duì)固定，適合于使用這個(gè)分片算法。

時(shí)間范圍分片（PartitionByDat-eRange）是按照時(shí)間范圍進(jìn)行分片，超過(guò)分片數(shù)量后從第一個(gè)分片再次循環(huán)分片。適用于按時(shí)間范圍進(jìn)行存儲(chǔ)的數(shù)據(jù)。

枚舉分組取模分片（PartitionByEnumAndMod）是枚舉+取模的組合分片方式，包含枚舉鍵和取模鍵兩個(gè)分片鍵，先通過(guò)枚舉鍵將數(shù)據(jù)分配到不同的分組，再在分組里通過(guò)取模鍵對(duì)應(yīng)到具體的分片。

4數(shù)據(jù)庫(kù)中間件

要實(shí)現(xiàn)對(duì)應(yīng)用透明的分布式數(shù)據(jù)庫(kù)的訪問(wèn)，離不開數(shù)據(jù)庫(kù)中間件。簡(jiǎn)單來(lái)說(shuō)，數(shù)據(jù)庫(kù)中間件就是介于數(shù)據(jù)庫(kù)與應(yīng)用之間，進(jìn)行數(shù)據(jù)處理與交互的中間服務(wù)。由于對(duì)數(shù)據(jù)進(jìn)行水平切分處理之后，原來(lái)一個(gè)表的數(shù)據(jù)現(xiàn)在分布到多個(gè)庫(kù)的多個(gè)表里，應(yīng)用不可避免的需要訪問(wèn)多個(gè)數(shù)據(jù)庫(kù)的數(shù)據(jù)并進(jìn)行匯聚處理。如果沒有數(shù)據(jù)庫(kù)中間件，那么應(yīng)用將直接面對(duì)分片集群，數(shù)據(jù)源切換、事務(wù)處理、數(shù)據(jù)聚合都需要應(yīng)用直接處理，原本該是專注于業(yè)務(wù)的應(yīng)用，將會(huì)花大量的工作來(lái)處理分片后的問(wèn)題。所以有了數(shù)據(jù)庫(kù)中間件，應(yīng)用只需要集中于業(yè)務(wù)處理，而數(shù)據(jù)聚合，事務(wù)，數(shù)據(jù)源切換都由中間件來(lái)完成，數(shù)據(jù)庫(kù)中間件可以看作一個(gè)或多個(gè)數(shù)據(jù)庫(kù)集群構(gòu)成的邏輯庫(kù)，而對(duì)實(shí)際應(yīng)用來(lái)說(shuō)，并不需要知道中間件的存在。

5電信自研的分布式數(shù)據(jù)庫(kù)

5.1系統(tǒng)架構(gòu)

電信自研的分布式數(shù)據(jù)庫(kù)由統(tǒng)一數(shù)據(jù)訪問(wèn)層TeleUDAL及高可用數(shù)據(jù)庫(kù)TeleDB兩部分組成。TeleDB基于開源關(guān)系型數(shù)據(jù)庫(kù)MySQL改造，提供高可靠的數(shù)據(jù)存儲(chǔ)能力;數(shù)據(jù)訪問(wèn)基于開源數(shù)據(jù)庫(kù)中間件Cobar改造，屏蔽數(shù)據(jù)庫(kù)分庫(kù)分表帶來(lái)的訪問(wèn)難題。

系統(tǒng)架構(gòu)圖如圖1所示。

從圖1可看出，TeleUDAL主要由LVS、DBProxy、GiServer組件組成。

LVS為DBProxy提供服務(wù)注冊(cè)發(fā)現(xiàn)及負(fù)載均衡功能，應(yīng)用發(fā)送的請(qǐng)求通過(guò)LVS均衡分布到各個(gè)DBProxy上。

DBProxy是TeleUDAL的核心組件，是一個(gè)實(shí)現(xiàn)了mysql協(xié)議的Sever進(jìn)程，前端用戶可以把DBProxy看成數(shù)據(jù)庫(kù)代理，可用mysql客戶端工具或命令行方式直接訪問(wèn)，其后端以mysql原生協(xié)議與多個(gè)mysql數(shù)據(jù)庫(kù)進(jìn)行通信，也可以用jdbc協(xié)議與大多數(shù)主流數(shù)據(jù)庫(kù)服務(wù)器通信，DBProxy的核心功能是分庫(kù)分表并對(duì)應(yīng)用層屏蔽分庫(kù)分表帶來(lái)的訪問(wèn)難題。

GiServer是切片索引服務(wù)進(jìn)程，是為了提升非分片鍵查詢（select語(yǔ)句）時(shí)的效率（避免廣播查詢）而開發(fā)的，與數(shù)據(jù)庫(kù)的索引沒有任何關(guān)系，是完全不同的兩個(gè)概念，GiServer是切片索引數(shù)據(jù)的生產(chǎn)者，真正的消費(fèi)者是DBProxy進(jìn)程，假設(shè)客戶表是以cust_id進(jìn)行分表的，但應(yīng)用需要通過(guò)客戶身份證來(lái)查詢客戶信息，如果沒有切片索引，則DBProxy會(huì)將查詢語(yǔ)句廣播到所有節(jié)點(diǎn)執(zhí)行，接收到執(zhí)行結(jié)果進(jìn)行匯聚后再返回給應(yīng)用，如果建立了切片索引，則DBProxy首先會(huì)根據(jù)身份證號(hào)碼從切片索引中查詢到對(duì)應(yīng)的cust_id，再根據(jù)分片算法定位到cust_id對(duì)應(yīng)的分片，這樣就避免了廣播查詢。

除此之外，UDAL依賴的外部組件主要有zookeeper及分布式緩存，zookeeper用于存放DBProxy、GiServer的配置信息及全局序列數(shù)據(jù)，分布式緩存用于存放切片索引數(shù)據(jù)。

5.2關(guān)鍵概念

電信分布式數(shù)據(jù)庫(kù)中涉及邏輯庫(kù)、邏輯表、切片索引、全局序列等幾個(gè)關(guān)鍵概念。

邏輯庫(kù)（schema），對(duì)實(shí)際應(yīng)用來(lái)說(shuō)，并不需要知道中間件的存在，應(yīng)用開發(fā)人員只需要知道數(shù)據(jù)庫(kù)的概念，所以數(shù)據(jù)庫(kù)中間件可以被看作一個(gè)或多個(gè)數(shù)據(jù)庫(kù)集群構(gòu)成的邏輯庫(kù)。UDAL的邏輯庫(kù)（schema），與MySQL中的Database（數(shù)據(jù)庫(kù)）對(duì)應(yīng)，一個(gè)邏輯庫(kù)中定義了所包括的table。

邏輯表（table），對(duì)應(yīng)用來(lái)說(shuō)，所操作的表就是邏輯表，可以是數(shù)據(jù)切分后，分布多個(gè)分片庫(kù)中，也可以不做切分，存放在單個(gè)分片中，在UDAL中邏輯表包括：?jiǎn)纹怼⒎制?、全局表、?kù)內(nèi)分表四種類型的表。

單片表是相對(duì)分片表來(lái)說(shuō)的，就是指那些不需要作數(shù)據(jù)切分的表，一個(gè)數(shù)據(jù)庫(kù)中并不是所有表都很大，某些表是可以不用進(jìn)行切分的。

分片表是指那些原有的很大數(shù)據(jù)的表，需要切分到多個(gè)數(shù)據(jù)庫(kù)的表，這樣，每個(gè)分片都有一部分?jǐn)?shù)據(jù)，所有分片構(gòu)成完整的數(shù)據(jù)。

全局表是在每個(gè)分片庫(kù)都中保存一份同樣數(shù)據(jù)的表，主要解決跨庫(kù)關(guān)聯(lián)查詢問(wèn)題。這類表的數(shù)據(jù)量一般較小，變化不頻繁，如：字典、配置、工號(hào)、機(jī)表、區(qū)域等，其特點(diǎn)主要是變動(dòng)不頻繁，數(shù)據(jù)量總體變化不大且數(shù)據(jù)量較小，全局表的插入、更新操作會(huì)同步在所有節(jié)點(diǎn)上執(zhí)行，全局表的查詢操作，只從一個(gè)節(jié)點(diǎn)獲取，全局表可以跟任何一個(gè)表進(jìn)行JOIN操作。對(duì)全局表執(zhí)行update、delete、insert等DML操作時(shí)，需要保障這些DML語(yǔ)句在所有節(jié)點(diǎn)同步執(zhí)行成功，由于全局表的每條語(yǔ)句都需要分發(fā)到所有節(jié)點(diǎn)執(zhí)行，這樣就形成了跨節(jié)點(diǎn)分布式事務(wù)，在UDAL中我們采用事務(wù)補(bǔ)償機(jī)制來(lái)保障全局表數(shù)據(jù)的最終一致性。DB-Proxy檢測(cè)事務(wù)中的第一條DML語(yǔ)句是全局表時(shí)，會(huì)自動(dòng)開啟分布式事務(wù)如果有節(jié)點(diǎn)commit失敗，DBProxy會(huì)進(jìn)行自動(dòng)補(bǔ)償。

切片索引fgiserver）是一組非分片鍵和分片鍵的映射關(guān)系，目的是提升非分片鍵查詢（select語(yǔ)句）時(shí)的效率，避免廣播查詢。當(dāng)沒有切片索引時(shí)，select語(yǔ)句中如果沒有帶分片鍵，db-proxy無(wú)法計(jì)算出分片節(jié)點(diǎn)，這樣語(yǔ)句會(huì)廣播到所有節(jié)點(diǎn)執(zhí)行。如果有切片索引，先通過(guò)非分片鍵查詢到分片鍵的值，根據(jù)分片鍵的值計(jì)算出路由節(jié)點(diǎn)，再把語(yǔ)句發(fā)送到相應(yīng)的分片執(zhí)行，避免了廣播查詢。GiServer的原理是基于mysql binlog技術(shù)，模擬自己為mysql slave，所以一定要開啟mysql的binlog功能，并配置binlog模式為row.數(shù)據(jù)處理流程如圖2所示。

全局序列是在整個(gè)邏輯庫(kù)層面實(shí)現(xiàn)了全局唯一的序列。在分布式數(shù)據(jù)庫(kù)場(chǎng)景下，一個(gè)邏輯庫(kù)對(duì)應(yīng)了多個(gè)物理數(shù)據(jù)庫(kù)分片，邏輯庫(kù)表的主鍵要求在所有物理庫(kù)分片上都唯一，這樣用數(shù)據(jù)庫(kù)本身的機(jī)制生成序列號(hào)就無(wú)法滿足業(yè)務(wù)的需求了，必須采用新的全局序列生成機(jī)制。我們TeleUDAL的實(shí)現(xiàn)原理是DBProxy從ZooKeeper上獲取序列段保存到本地內(nèi)存，同時(shí)修改ZooKeeper上下一次獲取序列段的起始值，本地內(nèi)存中的序列用完后再?gòu)膠k獲取新的序列段。全局序列的使用與ora]ce的sequence使用類似，先創(chuàng)建好sequence，再通過(guò)select XXX.next-val獲取序列值。為保證序列獲取的效率，dbproxy會(huì)緩存一段序列，這樣在一個(gè)集群中存在多個(gè)dbproxy的情況下不能保證序列是嚴(yán)格遞增的。

5.3 TeleUDAL簡(jiǎn)單原理

TeleUDAL究竟是如何實(shí)現(xiàn)數(shù)據(jù)的水平拆分及對(duì)應(yīng)用透明的數(shù)據(jù)訪問(wèn)的呢？下面簡(jiǎn)要說(shuō)明其實(shí)現(xiàn)原理。

1）數(shù)據(jù)的拆分及存儲(chǔ)

分片鍵是數(shù)據(jù)進(jìn)行拆分的分片字段，是UDAL中數(shù)據(jù)分布和SQL路由的計(jì)算依據(jù)。UDAL中的數(shù)據(jù)按照拆分字段值，加上特定的算法進(jìn)行計(jì)算，根據(jù)結(jié)果存儲(chǔ)數(shù)據(jù)到對(duì)應(yīng)分片。如圖3所示，左表使用MEMBE_ID作為分片鍵，表中數(shù)據(jù)根據(jù)字符串hash取模算法分散到庫(kù)1和2中。

2）SQL路由

當(dāng)用戶SQL到UDAL時(shí)，UDAL會(huì)理解整個(gè)SQL含義，然后按照拆分字段的值和執(zhí)行策略將SQL路由到對(duì)應(yīng)分區(qū)進(jìn)行執(zhí)行，如圖4所示。

3）數(shù)據(jù)匯聚

如果一個(gè)SQL對(duì)應(yīng)多個(gè)分片數(shù)據(jù)執(zhí)行，UDAL會(huì)將各個(gè)分片返回的數(shù)據(jù)按照原始SQL語(yǔ)義進(jìn)行合并，如圖5所示。

5.4TdeDB梁構(gòu)

TeleDB是中國(guó)電信基于開源MySQL5.7數(shù)據(jù)庫(kù)系統(tǒng)自主開發(fā)的高可用數(shù)據(jù)庫(kù)集群產(chǎn)品。在MYSQL基礎(chǔ)上，額外開發(fā)了Gateway、keeper、Agen組件，對(duì)外提供高性能高可用、數(shù)據(jù)一致性的分布式數(shù)據(jù)庫(kù)服務(wù)，大概架構(gòu)如圖7所示。

Keeper是TeleDB的調(diào)度器，監(jiān)聽zookeeper的特定路徑，主要作用是用于監(jiān)控底層主數(shù)據(jù)庫(kù)與備數(shù)據(jù)庫(kù)的可用狀態(tài)、數(shù)據(jù)庫(kù)同步延遲等一類信息;決定主從數(shù)據(jù)是否能夠進(jìn)行主從切換，控制主從切換的啟動(dòng)及操作過(guò)程。在生產(chǎn)環(huán)境中為保證KEEPER高可用，至少部署三臺(tái)KEEPER在三臺(tái)獨(dú)立機(jī)上。

zookeeper是分布式一致性協(xié)議的一種開源實(shí)現(xiàn)，用于TeleDB組件中狀態(tài)信息的保存，起到通信媒介的作用;一旦zookeeper崩潰，各個(gè)模塊間的通信全部中斷。為保證zookeeper高可用，至少部署三臺(tái)zookeeper在三臺(tái)獨(dú)立機(jī)上。

Agent用于收集底層DB服務(wù)器的狀態(tài)信息，并將相關(guān)信息寫入zookeeper。DB服務(wù)器狀態(tài)信息包括底層數(shù)據(jù)庫(kù)狀態(tài)信息（是否可讀寫），主從數(shù)據(jù)復(fù)制延遲、服務(wù)器負(fù)載、磁盤使用使用情況等信息。

DB層是數(shù)據(jù)庫(kù)節(jié)點(diǎn)組，由MySQL數(shù)據(jù)庫(kù)引擎模塊以及監(jiān)控和信息采集系統(tǒng)AGENT兩個(gè)部分組成，一個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)組（SET）包括一個(gè)主節(jié)點(diǎn)（Master）、若干備節(jié)點(diǎn)（slave）I，一般是一主兩從，SET通過(guò)心跳監(jiān)控和信息采集模塊（agent）監(jiān)控，確保集群的健壯性;在分布式架構(gòu)下，若干個(gè)數(shù)據(jù)庫(kù)節(jié)點(diǎn)組（SET）可以提供一個(gè)“邏輯統(tǒng)一，物理分散”分布式數(shù)據(jù)庫(kù)實(shí)例。

5.5TeleDB核心功能

TeleDB在開源的MySQL的基礎(chǔ)上，對(duì)主從同步、性能和可靠性等多個(gè)方面做了一定的改進(jìn)。

1）支持在事務(wù)commit前等待ACK，提高主備庫(kù)同步可靠性。

TeleDB相對(duì)于MySQL5.7之前的版本增加了rDl-semi_sync_master_wait_point參數(shù)來(lái)控制半同步復(fù)制模式下主庫(kù)在返回給會(huì)話事務(wù)成功之前提交事務(wù)的方式。

該參數(shù)有兩個(gè)值A(chǔ)FrER_COMMIT，AFrER_SYNC。AF-TER_COMMIT是master將每個(gè)事務(wù)寫入binlog，傳遞到slave刷新到磁盤（relay 10g），同時(shí)主庫(kù)提交事務(wù)。master等待slave反饋收到relaylog，只有收到ACK后master才將commitOK結(jié)果反饋給客戶端，由于主庫(kù)在備庫(kù)返回ACK信號(hào)之前就提交了事務(wù)，故存在主備庫(kù)數(shù)據(jù)不一致的風(fēng)險(xiǎn);而AFTER_SYNC則是master將每個(gè)事務(wù)寫入binlog，傳遞到slave刷新到磁盤（relaylog）。master等待slave反饋接收到relaylog的ack之后，再提交事務(wù)并且返回commit OK結(jié)果給客戶端。即使主庫(kù)crash，所有在主庫(kù)上已經(jīng)提交的事務(wù)都能保證已經(jīng)同步到slave的relaylog中，因此AFTER_SYNC模式同步的可靠性更高，TeleDB默認(rèn)采用該模式。

2）實(shí)現(xiàn)了發(fā)送binlog和接受ack的異步化，提高主備庫(kù)同步性能。

以前版本的半同步的性能受限于dump thread，原因是dumpthread承擔(dān)了兩份不同且又十分頻繁的任務(wù)：傳送binlog給slave，還需要等待slave反饋信息，而且這兩個(gè)任務(wù)是串行的，dump thread必須等待slave返回之后才會(huì)傳送下一個(gè)events事務(wù)。dump thread已然成為整個(gè)半同步提高性能的瓶頸。在高并發(fā)業(yè)務(wù)場(chǎng)景下，這樣的機(jī)制會(huì)影響數(shù)據(jù)庫(kù)整體的TPS。在TeleDB中，實(shí)現(xiàn)了發(fā)送binlog和接受ack的異步化，提高了主從同步的性能。

3）控制半同步主庫(kù)超時(shí)時(shí)間，實(shí)現(xiàn)高性能與高可靠靈活控制。

TeleDB版本在MySQL 5.7基礎(chǔ)上通過(guò)調(diào)整rpl_semi_sync_master_timeout參數(shù)，來(lái)控制半同步主庫(kù)超時(shí)時(shí)間，以便運(yùn)維人員在性能與可靠性兩者之間進(jìn)行權(quán)衡。在通常的生產(chǎn)運(yùn)營(yíng)環(huán)境下，通過(guò)將該參數(shù)調(diào)整為較大的值，可以達(dá)到高可靠即強(qiáng)同步的效果;而在其他一些對(duì)數(shù)據(jù)可靠性不那么敏感，而對(duì)性能要求更高的場(chǎng)合，則可以將此參數(shù)調(diào)小。

4）使用線程池技術(shù)，提高連接效率。

TeleDB拋棄了MySQL傳統(tǒng)每連接每線程的連接模式，這種連接模式會(huì)導(dǎo)致巨大的系統(tǒng)開銷進(jìn)而影響整個(gè)性能。因此，TeleDB通過(guò)擴(kuò)展MySQL線程池，使用線程池技術(shù)來(lái)解決最大連接數(shù)限制問(wèn)題以及過(guò)多線程帶來(lái)的系統(tǒng)開銷。

5）提升高并發(fā)場(chǎng)景下的性能穩(wěn)定性。

MySQL官方版默認(rèn)使用glibc作為mallc的動(dòng)態(tài)庫(kù)，在高并發(fā)情況下，大量連接連到數(shù)據(jù)庫(kù)，而在這些連接結(jié)束釋放資源后，MvsQL會(huì)導(dǎo)致cpu sys值升高，使數(shù)據(jù)庫(kù)性能惡化。針對(duì)此問(wèn)題，TeleDB給出兩種方案：增強(qiáng)線程池功能，跟主流開源線程池版本例如Percona、MariaDB等相比增加了線程池線程Cache功能;修改底層內(nèi)存分配庫(kù)，替代默認(rèn)使用系統(tǒng)glibc庫(kù)。以上兩種方案都可以解決MySQL官方版本使用glibc高并發(fā)場(chǎng)景sys升高的問(wèn)題，沒有再出現(xiàn)sys飆高導(dǎo)致性能急劇下降的情況。

通過(guò)以上幾個(gè)方面的改進(jìn)，TeleDB在高可靠、高連接、高并發(fā)、高吞吐等訪問(wèn)場(chǎng)景下表現(xiàn)出極強(qiáng)的穩(wěn)定性，比官方MySQL具有明顯的優(yōu)勢(shì)。

6分布式數(shù)據(jù)庫(kù)在湖南電信的應(yīng)用

2018年，湖南電信啟動(dòng)以分布式數(shù)據(jù)庫(kù)為核心的企業(yè)級(jí)PaaS平臺(tái)建設(shè)，到2019年7月為止，已經(jīng)完成服務(wù)開通系統(tǒng)、自動(dòng)激活系統(tǒng)、支付中心的改造遷移工作，預(yù)計(jì)到2019年底完成客戶服務(wù)中心、能力開放平臺(tái)等其余15個(gè)系統(tǒng)的改造遷移工作，到2020年完成湖南電信核心BSS3.0系統(tǒng)的遷移改造工作。目標(biāo)是在未來(lái)幾年逐步實(shí)現(xiàn)省內(nèi)IT系統(tǒng)、網(wǎng)管系統(tǒng)、業(yè)務(wù)系統(tǒng)的分布式改造，實(shí)現(xiàn)統(tǒng)一平臺(tái)、統(tǒng)一運(yùn)營(yíng)。

通過(guò)使用TeleUDAL和TeleDB分布式數(shù)據(jù)庫(kù)，遷移后支付中心的SQL執(zhí)行平均耗時(shí)由15ms減少到4ms，SQL執(zhí)行效率提升275%，服務(wù)開通系統(tǒng)每分鐘CRM取單峰值，由之前的1333筆提升到5552筆，性能提升316%;移動(dòng)電話派發(fā)自動(dòng)激活，每分鐘取單峰值由之前的582筆提升到1161筆，性能提升99.5%。系統(tǒng)改造后，效果提升明顯，充分證明TeleUDAL和TeleDB組成的分布式數(shù)據(jù)庫(kù)系統(tǒng)的穩(wěn)定、可靠、高性能，實(shí)現(xiàn)了容量和服務(wù)能力的可彈性伸縮，可輕松應(yīng)對(duì)高并發(fā)的實(shí)時(shí)交易場(chǎng)景。

7結(jié)論

面對(duì)海量數(shù)據(jù)的存儲(chǔ)、處理、訪問(wèn)的難題，中國(guó)電信基于開源組件開發(fā)了TeleUDAL和TeleDB分布式數(shù)據(jù)庫(kù)，TeleUDAL通過(guò)對(duì)數(shù)據(jù)的水平切分，將海量數(shù)據(jù)分散到多個(gè)物理上獨(dú)立而邏輯上統(tǒng)一的數(shù)據(jù)庫(kù)里，解決數(shù)據(jù)存儲(chǔ)和并發(fā)訪問(wèn)問(wèn)題;通過(guò)SQL路由和數(shù)據(jù)匯聚技術(shù)解決透明數(shù)據(jù)訪問(wèn)的問(wèn)題。TeleDB通過(guò)搭建一主兩從的集群，解決數(shù)據(jù)的可靠存儲(chǔ)問(wèn)題，通過(guò)對(duì)開源Mysql的改進(jìn)，提高主備庫(kù)同步的可靠性及性能。最終解決了電信企業(yè)海量交易型業(yè)務(wù)數(shù)據(jù)的存儲(chǔ)和高效訪問(wèn)的難題，使湖南電信能夠?qū)鹘y(tǒng)的運(yùn)營(yíng)商支撐系統(tǒng)轉(zhuǎn)型為新型的互聯(lián)網(wǎng)IT架構(gòu)的系統(tǒng)，提升企業(yè)通信服務(wù)水平。