掌握6大模塊、7個核心概念！幫你搞定Mycat中間件#導入MD文檔圖片#

開篇

近今年裏隨着經濟的飛速發展，企業的業務也在不斷膨脹，做爲業務支撐的信息系統特別是數據庫系統也面臨史無前例的壓力，行業應用所產生的數據呈爆炸式地增加。數據從原來的GB級別迅速增常到TB甚至是PB的規模，已經遠遠超過傳統計算技術的要求，原來集中式的存儲方式已經沒法知足數據存儲的要求，此時分佈式數據存儲因爲良好的透明性、數據冗餘性、擴展性、自治性逐漸進入人們的視野。爲了更好的使用和管理分佈式數據庫，業內推出了很多優秀的分佈式數據庫中間件，Mycat就是其中之一，今天就來看看Mycat的架構和實現原理。本篇文章會學到如下內容：

• 分佈式數據存儲與Mycat
• Mycat架構介紹
• Mycat核心概念及配置

 

分佈式數據存儲與Mycat

衆所周知，在分佈式數據庫的使用場景下，數據的存儲不像集中式數據庫那樣都存放在一臺服務器的一個數據庫中，而是會分佈在不一樣的服務器的不一樣數據庫中。而應用程序的會根據不一樣的數據庫進行訪問，如圖1 所示，應用程序須要根據訪問的數據庫不一樣：數據庫一、數據庫二、數據庫3使用不一樣的數據庫鏈接，若是說某張數據表在三個數據庫中都存在，也須要使用特定的方式對其進行訪問，能夠說在應用程序這端訪問起來是比較麻煩的。

圖1 分佈式的數據庫隊增長了應用程序訪問的複雜度

正由於應用程序在訪問分佈式數據庫的時候會遇到相似的問題，因此引入了數據庫中間件來簡化應用程序須要面對的問題。如圖2所示，在應用程序和數據庫中間引入Mycat數據庫中間件之後，讓應用程序的編程更加方便，它不用在面對分佈式的數據庫，而只用針對Mycat中間件進行數據庫編程就能完成對應的數據操做，而且適用於如下幾種場景：

• 讀寫分離：能夠經過Mycat針對數據庫1進行寫操做，而對數據庫2和3進行讀操做。若是在寫服務器出現宕機的狀況，Mycat能夠將寫的請求暫時轉移到其餘的數據庫服務器上，保證數據庫的可用性。
• 垂直分表分庫：將訂單表存放到數據庫1和2中，將商品表存放到數據庫3中。也就是把不一樣的表放在不一樣的庫中。
• 水平分表分庫：將訂單表的不一樣記錄經過分片算法（例如：hash取模）分表存放到數據庫1和2中。也就是將相同表的不一樣數據放到不一樣庫的表中。
• 訪問不一樣的數據庫：數據庫1和2對應訪問的就是MySQL數據庫，而數據庫3訪問的是Oracle數據庫。
• 控制應用程序到數據庫的鏈接數量：每個數據庫鏈接都會佔用數據庫服務器的資源，每一個數據庫服務器可以鏈接的請求也是有限的，這裏Mycat能夠控制前端應用請求數據庫服務器的鏈接數量，保證數據庫服務器的高可用。

換句話說，當應用程序發起一條SQL語句的時候，不用關心數據庫存放在哪一個服務器，以及數據庫表是否作了分表分庫，只用將要查的數據告訴Mycat就能夠了，Mycat在考慮上述場景以後將結果返回給應用程序，讓開發者更加方便快捷地操做數據。

圖2 引入Mycat協助應用程序實現讀寫分離、分表分庫操做

上面描述的這些數據操做若是在沒有Mycat中間件的狀況須要在應用程序端維護大量的代碼，而有了Mycat以後應用程序只須要針對Mycat進行配置，而且對其變成就能完成這些操做。

Mycat是一個開源的面相企業應用開發的數據庫中間件，支持大數據庫集羣、事物、ACID。適用於高可用性、數據庫讀寫分離、數據分級存儲保障、大型數據庫的分表分庫以及並行計算、數據庫路由以及整合諸如MySQL、Oracle、SQL Server等數據庫。因爲Mycat開源中間件有一個發展的過程，每一個版本的迭代都會遇到一些問題，目前已經更新到了Mycat 2.0是一個相對穩定的版本。若是有條件的同窗儘可能使用最新版本，或者使用Mycat 1.6.5 以上的版本，其修正了一些經常使用SQL函數的問題。不過Mycat也不是萬能的依舊會存在一些問題，咱們這裏把它的優缺點列出以下表格方便你們參考。

優勢	缺點
拆分後業務清晰，拆分規則明確	部分業務表沒法join，只能經過接口調用
系統之間容易擴展和整合	跨庫事務難以處理
數據維護簡單	垂直切分後某些業務數據過於龐大，仍然存在單體性能瓶頸
解決了單庫大數據、高併發的性能瓶頸	拆分規則很難抽象
拆分規則封裝好，對應用端幾乎透明，開發人員無需關心拆分細節	分片事務一致性難以解決，須要經過XA或者藉助其餘分佈式事務方式，例如：Redis、Zookeeper。
提升了系統的穩定性和負載能力	二次擴展時，數據遷移、維護難度大

 

 

Mycat 架構介紹

上面講到了Mycat在分佈式數據庫中起到的做用，讓應用程序的開發專一於業務自己，把分表分庫、讀寫分離、訪問不一樣數據以及控制數據庫鏈接的問題都交給Mycat來處理。那麼Mycat是經過怎樣的架構實現上述功能的呢，下面就和我一塊兒來看看Mycat的組件和架構。

從邏輯上劃分如下六個模塊。

• 通訊協議模塊：主要負責底層通訊功能，例如收發數據、線程回調等工做。採用Reactor、Proctor模式，在網絡IO架構中實現了NIO和AIO的方式。
• SQL執行模塊：顧名思義，其接受到要執行的SQL 之後經過數據庫鏈接模塊鏈接到數據庫，經過鏈接池獲取目標數據庫，再經由SQL路由解析把SQL語句分發到數據庫節點中進行執行。
• 路由解析模塊：當Mycat實現分表分庫功能的時候，路由就顯得很是重要了。該模塊當收到應用程序請求的查詢語句之後，會鏈接後端的數據，經過配置文件的規則設置，將請求路由到對應的數據庫的表中進行查詢。同時該模塊還肩負SQL解析的職能，須要對SQL語句的EXPLAIN、SET、SHOW、SELECT等命令進行解析，從而獲取表名、條件、字段列表等信息。同時還能夠對SQL語句進行改寫。
• 數據庫鏈接模塊：主要負責建立、管理、維護後端的數據庫以及對應的數據庫鏈接池。而且經過鏈接池機制對數據庫鏈接的生命週期進行管理。
• 結果集處理模塊：當查詢結果返回以前須要將其進行彙總、排序。特別是針對數據分片的狀況，返回的數據來自不一樣的數據庫服務器和表，須要將這些數據進行必要的彙總才能返回給應用程序。
• 監控管理模塊：主要對Mycat中的鏈接、內存等資源進行監控和管理。監控參數包括：鏈接數、緩存命中數等。

上面六個模塊看上去比較抽象，若是理清邏輯順序記憶起來仍是比較方便的。通信協議模塊接受到應用程序的SQL請求，會將其交給SQL執行模塊，執行模塊解析SQL以後須要知道訪問哪些節點上的數據庫。因而，它請求路由解析模塊，再瞭解須要訪問哪些數據庫之後，經過數據庫鏈接模塊創建數據庫鏈接，而且分發SQL到對應數據庫上執行。將返回的數據經過結果集處理模塊，彙總、排序，最後返回給應用程序。監控管理模塊就好像一個大管家監視Mycat中的鏈接、內存等資源使用狀況。

若是將上面的組件經過Mycat的處理流程展現的話，如圖3所示，整個圖由上、中、下3步部分組成。上面的部分表明客戶端，其承載多個應用程序會向處在中間的Mycat服務發起SQL請求。中間Mycat服務，包含了上述的六大組件，負責對應用程序請求進行處理和響應。下面的存儲層能夠對接不一樣的數據源，爲Mycat提供存儲服務。整個請求處理流程分爲請求和響應兩個部分，分別由「從上往下」和「從下往上」的兩個箭頭表明，這裏咱們將Mycat的處理分爲六個步驟給你們介紹以下：

1. 在客戶端的應用程序向Mycat服務發起SQL請求的時候，通訊協議模塊會經過NIO/AIO的方式將請求提交給路由解析模塊。
2. 路由解析模塊包含SQL解析、優化和路由的功能。主要功能是將SQL進行解析成要執行的命令，而且對其進行優化，以後經過路由規則找到要執行的數據庫服務器。
3. 以後請求會交給SQL執行模塊，根據路由解析的結果分發到數據庫服務器上執行。
4. 在執行以前須要經過數據庫鏈接模塊獲取數據庫對應的鏈接，同時須要對數據庫鏈接池進行管理。
5. 一樣，在分發執行SQL的時候也須要通訊協議模塊進行信息的傳遞。
6. 當執行完SQL請求之後，數據庫會將數據經過結果處理模塊進行聚合、排序、彙總的操做，最後將數據返回給客戶端的應用程序，完成整個請求過程。

圖3 Mycat 數據處理流程

 

Mycat 核心概念及配置

在描述完Mycat 的架構和工做流程之後，相信你們對Mycat的執行機制和結構都有必定的瞭解。站在架構的高度對下面的核心概念的理解會有一些幫助，若是說上面講的是Mycat邏輯架構，那麼下面介紹的核心概念及配置就涉及到具體操做的範疇。畢竟Mycat須要提供配置工具完成開發者的功能，而後再經過架構來執行這些規則，最後實現對分佈式數據庫開發的透明性。接下來要介紹的就是在使用Mycat過程當中遇到的核心概念，以及這些概念對應的配置方式和對應的配置文件。方便咱們落地Mycat中間件的應用。

如圖4所示，改圖描述了Mycat 核心概念之間的關係，而且描述了這些核心概念在哪些配置文件中進行配置。咱們從上往下跟着序號來看這些概念：

1. Mycat中的系統信息和用戶信息都在xml文件中進行配置，其中對於user（用戶）的配置包含了，用戶基本信息和所可以訪問schema（邏輯庫）的權限。
2. xml包含了Mycat對於數據的定義，Schema（邏輯庫）會包含一個或者多個table（邏輯表）。
3. Table（邏輯表）會經過包含的datanode（數據節點）來描述數據存放的服務器和物理數據庫。
4. 在datanode中包含了datahost和database。其中datahost表示數據庫所在的服務器集羣，而database是對物理數據庫的描述。
5. 針對每一個table的分片定義規則，在xml文件中進行定義，rule在定義規則的時候會調用function對規則算法進行描述。

圖4 Mycat核心概念圖

上面咱們將Mycat核心概念以及它們對應的配置文件給你們作了總體介紹，接下來將對上面的概念作深刻的描述。

用戶（User）

Mycat中的用戶是一個邏輯上的用戶，他定義了用來鏈接Mycat中間件的用戶信息，而且將這些信息存放在server.xml文件中。如圖5所示，這是server.xml 文件中對user 信息的定義。

• 能夠看到定義了用戶名爲「test」，密碼「password」是在schemas 標籤裏面定義了「test_db」 這是該用戶能夠訪問的邏輯數據庫。
• 在privileges標籤中定義了true說明還會用戶對邏輯庫的具體使用權限。這裏定義對「test_db」的dml到操做用的是四位數字表示，分別是「0110」。實際上每一位都表示一種操做，四位對應的操做分別是「insert、update、select、delete」，若是對應的位數上是「1」表示支持該操做，若是是「0」表示不支持對應的操做。「0110」就表示，不支持insert操做、支持update操做、支持select操做，不支持delete操做。以此類推在schema標籤下面還有一個table標籤，能夠設置對邏輯表的權限，例如：table01的dml是0000，也就是不能進行四種操做的意思。

圖5 用戶的定義Server.xml文件

邏輯庫（schema）

開發人員在進行數據庫開發的時候都須要對某個具體的數據庫進行操做，例如：查找、更新、刪除等等。可是到了分佈式數據庫的時代，數據庫以分佈式的方式部署在不一樣的服務器節點中，此時再去訪問這些數據庫難度就增長了。有Mycat介入之後，引入了邏輯庫的概念。邏輯庫是一個概念上的定義，其背後對應的是一個或者多個實體數據庫。它的定義是在schema.xml文件中進行的。如圖6所示，

• 定義了名爲「test_db」的邏輯數據庫。
• sqlMaxLimit 用來限制每次查詢數據可否返回的最大行數，這裏設置的是「1000」，當爲「-1」的時候就沒有限制。
• checkSQLschema 是一個是否經過庫名和表名方式訪問數據庫的開關，默認狀況下是「fasle」。

圖6 邏輯庫在schema.xml文件中的定義

邏輯表（table）

既然有邏輯庫就必定有邏輯表，一般意義上邏輯表會和物理表進行對應，有多是一個邏輯表對應多個分佈在不一樣數據節點的物理表；也有可能對應一張沒有進行分片的物理表。一樣這些配置都是在schema.xml配置文件中完成的。如圖7 所示，

• 在上面定義的邏輯庫「test_db」中定義了一個邏輯表，表的名字叫作「order」 ，邏輯表的名字須要和物理表的名字保持一致。由於在Mycat不會再定義邏輯表與物理表之間的關係了，所以使用這種隱性的方式讓它們進行對應。
• 「primaryKey」標籤是定義邏輯表的主鍵，邏輯表的主鍵和物理表的主鍵也是保持一致的。設置主鍵的目的是，若是在數據分片時沒有選擇主鍵，Mycat會經過這個定義主鍵的定義對物理表進行查詢，從而提升查詢的效率。
• 在「dataNode」標籤中 定義了物理數據庫的名字。若是一張物理表分片存儲在多個物理數據庫，那麼每一個物理數據庫須要經過逗號進行分割。這裏物理節點的順序也就是索引的順序。如圖中顯示的「orderdb01」的索引就是0，「orderdb02」的索引就是1。
• 最後在Rule標籤中定義的是水平分片的規則，具體的定義方式在後面進行詳細講解。

圖7 在邏輯庫中定義邏輯表

 

數據節點（DataNode）

定義邏輯存儲對應的物理數據庫，這裏包含兩個重要的信息：第一，保存數據的數據庫主機（集羣）的名字；第二，物理數據庫的名稱。一樣在schema.xml配置文件的dataNode標籤下配置。如圖8 所示，

• 「dataHost」標籤描述了物理數據庫的數據庫服務器（服務器節點/集羣）。
• 「database」標籤描述了客戶端物理數據庫的名字，在服務器節點上必須存在這個數據庫。

從兩個數據節點（「orderdb01」，「orderdb02」）都定義到一個「mysql01」的datahost能夠看出，它們的數據庫都存放在同一個數據庫集羣中。

圖8 數據節點定義

數據主機集羣（DataHost）

數據主機集羣主要是描述存放數據庫的主機信息，一般來講是描述一個數據庫服務器的集羣。如圖9所示，

• dataHost中定義了「mysql01」的數據庫主機集羣，其中包括「maxCon」（最大鏈接數），「minCon」（最小鏈接數），「balance」（讀寫分離開關），「dbType」（數據庫類型）等標籤。
• 重要的是，在這個集羣中定義了三臺數據庫的服務器。」192.168.0.1」這臺是寫服務器，與之對應有一臺讀服務器，它是「168.0.2」。另外，還有一臺寫服務器是」192.168.0.3」。

圖9 數據主機集羣

 

分片規則(TableRule)和函數(Function)

在schema.xml文件中基本都是數據方面的定義，其中在邏輯表中有針對rule的定義，這種狀況是用來定義分片規則的。通常而言分片規則的定義在rule.xml文件中完成。

如圖10所示：

• tableRule中定義了分片規則爲「mod_3_order_id」,這個名字是給邏輯表中的rule標籤使用的。從名字的含義能夠看出，經過對3取模的方式對order_id這個字段進行計算，從而實現分片操做。
• 在columns標籤中定義了order_id做爲取模的字段。
• 在algorithm標籤中定義了具體的分片算法。這裏的算法名稱能夠從下面的function節點中找到對應的定義。
• Function中的name 對應上面tablerule中的算法名稱，一樣是」mod_3」,也就是經過對3進行取模。
• 在class 標籤中定義了算法實現的Class 類的namespace和對應的類名。
• Count 標籤訂義的3就是具體取模的數字，這裏是對3進行取模。

圖10 tableRule和function定義

根據上面給出的配置規則的定義，能夠獲得圖11所示分片規則。

1. 當應用程序發起一個對order表的SQL查詢，查詢order_id=1的數據。
2. 當請求提交給Mycat之後，針對簡單取模的方式把order_id對3進行取模獲得1。
3. 因爲order表被分片存放在DB0、DB一、DB2三個庫中，經過取模的值路由到DB1的order表中而且執行SQL語句，完成此次分佈式的查詢。

圖11 分片規則定義路由選擇

 

總結

本文從分佈式數據存儲入手，描述了Mycat在分佈式數據庫中起到了怎樣的做用。而後介紹了Mycat的六大模塊：通訊協議、SQL執行、路由解析、數據庫鏈接、結果集處理、監控管理，是如何工做的。最後經過介紹Mycat七大核心概念：用戶、邏輯庫、邏輯表、數據節點、數據主機集羣、分片規則、分片函數，以及對應的三個配置文件：Server.xml、Schema.xml 和Rule.xml文件是如何幫助應用程序使用好Mycat中間件的。

 

如何構建高併發架構？請關注個人專欄 秒殺高併發白話實戰