[[378586]]

本文轉載自微信公眾號「石杉的架構筆記」，作者崔皓 。轉載本文請聯系石杉的架構筆記公眾號。  

開篇

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

分布式數據存儲與Mycat

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

眾所周知，在分布式數據庫的使用場景下，數據的存儲不像集中式數據庫那樣都存放在一臺服務器的一個數據庫中，而是會分布在不同的服務器的不同數據庫中。而應用程序的會根據不同的數據庫進行訪問，如圖1 所示，應用程序需要根據訪問的數據庫不同：數據庫1、數據庫2、數據庫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的組件和架構。

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

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

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

如果將上面的組件通過Mycat的處理流程展示的話：

圖3

Mycat 數據處理流程

如圖3所示，整個圖由上、中、下3步部分組成。

上面的部分代表客戶端，其承載多個應用程序會向處在中間的Mycat服務發起SQL請求。中間Mycat服務，包含了上述的六大組件，負責對應用程序請求進行處理和響應。下面的存儲層可以對接不同的數據源，為Mycat提供存儲服務。整個請求處理流程分為請求和響應兩個部分，分別由“從上往下”和“從下往上”的兩個箭頭代表，這里我們將Mycat的處理分為六個步驟給大家介紹如下：

1. 在客戶端的應用程序向Mycat服務發起SQL請求的時候，通信協議模塊會通過NIO/AIO的方式將請求提交給路由解析模塊。

2. 路由解析模塊包含SQL解析、優化和路由的功能。主要功能是將SQL進行解析成要執行的命令，并且對其進行優化，之后通過路由規則找到要執行的數據庫服務器。

3. 之后請求會交給SQL執行模塊，根據路由解析的結果分發到數據庫服務器上執行。

4. 在執行之前需要通過數據庫連接模塊獲取數據庫對應的連接，同時需要對數據庫連接池進行管理。

5. 同樣，在分發執行SQL的時候也需要通信協議模塊進行信息的傳遞。

6. 當執行完SQL請求以后，數據庫會將數據通過結果處理模塊進行聚合、排序、匯總的操作，最后將數據返回給客戶端的應用程序，完成整個請求過程。

Mycat核心概念及配置

在描述完Mycat 的架構和工作流程以后，相信大家對Mycat的執行機制和結構都有一定的了解。站在架構的高度對下面的核心概念的理解會有一些幫助，如果說上面講的是Mycat邏輯架構，那么下面介紹的核心概念及配置就涉及到具體操作的范疇。

畢竟Mycat需要提供配置工具完成開發者的功能，然后再通過架構來執行這些規則，最后實現對分布式數據庫開發的透明性。接下來要介紹的就是在使用Mycat過程中遇到的核心概念，以及這些概念對應的配置方式和對應的配置文件。方便我們落地Mycat中間件的應用。

圖4

Mycat核心概念圖

如圖4所示，改圖描述了Mycat 核心概念之間的關系，并且描述了這些核心概念在哪些配置文件中進行配置。

我們從上往下跟著序號來看這些概念：

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

上面我們將Mycat核心概念以及它們對應的配置文件給大家做了整體介紹，接下來將對上面的概念做深入的描述。

1.用戶(User)

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

圖5

用戶的定義Server.xml文件

可以看到定義了用戶名為“test”，密碼“password”是123456.在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，也就是不能進行四種操作的意思。

2.邏輯庫(schema)

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

如圖6所示：

圖6

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

定義了名為“test_db”的邏輯數據庫。

sqlMaxLimit 用來限制每次查詢數據能否返回的最大行數，這里設置的是“1000”，當為“-1”的時候就沒有限制。

checkSQLschema 是一個是否通過庫名和表名方式訪問數據庫的開關，默認情況下是“fasle”。

3.邏輯表(table)

既然有邏輯庫就一定有邏輯表，通常意義上邏輯表會和物理表進行對應，有可能是一個邏輯表對應多個分布在不同數據節點的物理表;也有可能對應一張沒有進行分片的物理表。同樣這些配置都是在schema.xml配置文件中完成的。

如圖7 所示：

圖7

在邏輯庫中定義邏輯表

• 在上面定義的邏輯庫“test_db”中定義了一個邏輯表，表的名字叫做“order” ，邏輯表的名字需要和物理表的名字保持一致。因為在Mycat不會再定義邏輯表與物理表之間的關系了，因此使用這種隱性的方式讓它們進行對應。
• “primaryKey”標簽是定義邏輯表的主鍵，邏輯表的主鍵和物理表的主鍵也是保持一致的。設置主鍵的目的是，如果在數據分片時沒有選擇主鍵，Mycat會通過這個定義主鍵的定義對物理表進行查詢，從而提高查詢的效率。
• 在“dataNode”標簽中 定義了物理數據庫的名字。如果一張物理表分片存儲在多個物理數據庫，那么每個物理數據庫需要通過逗號進行分割。這里物理節點的順序也就是索引的順序。如圖中顯示的“orderdb01”的索引就是0，“orderdb02”的索引就是1。
• 最后在Rule標簽中定義的是水平分片的規則，具體的定義方式在后面進行詳細講解。

4.數據節點(DataNode)

定義邏輯存儲對應的物理數據庫，這里包含兩個重要的信息：

• 保存數據的數據庫主機(集群)的名字
• 物理數據庫的名稱

同樣在schema.xml配置文件的dataNode標簽下配置。

如圖8 所示：

圖8

數據節點定義

“dataHost”標簽描述了物理數據庫的數據庫服務器(服務器節點/集群)。

“database”標簽描述了客戶端物理數據庫的名字，在服務器節點上必須存在這個數據庫。

從兩個數據節點(“orderdb01”，“orderdb02”)都定義到一個“mysql01”的datahost可以看出，它們的數據庫都存放在同一個數據庫集群中。

5.數據主機集群(DataHost)

數據主機集群主要是描述存放數據庫的主機信息，通常來說是描述一個數據庫服務器的集群。

如圖9 所示：

圖9

數據主機集群

dataHost中定義了“mysql01”的數據庫主機集群，其中包括“maxCon”(最大連接數)，“minCon”(最小連接數)，“balance”(讀寫分離開關)，“dbType”(數據庫類型)等標簽。

重要的是，在這個集群中定義了三臺數據庫的服務器。”192.168.0.1”這臺是寫服務器，與之對應有一臺讀服務器，它是“192.168.0.2”。另外，還有一臺寫服務器是”192.168.0.3”。

6.分片規則(TableRule)&函數(Function)

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

如圖10所示：

圖10

tableRule和function 定義

• 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進行取模。

根據上面給出的配置規則的定義，可以得到圖11所示分片規則。

圖11

分片規則定義路由選擇

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

總結

本文從分布式數據存儲入手，描述了Mycat在分布式數據庫中起到了怎樣的作用。然后介紹了Mycat的六大模塊：通信協議、SQL執行、路由解析、數據庫連接、結果集處理、監控管理，是如何工作的。

最后通過介紹Mycat七大核心概念：用戶、邏輯庫、邏輯表、數據節點、數據主機集群、分片規則、分片函數，以及對應的三個配置文件：Server.xml、Schema.xml 和Rule.xml文件是如何幫助應用程序使用好Mycat中間件的。