數據庫路由中間件MyCat - 使用篇（1）

此文已由做者張鎬薪受權網易雲社區發佈。

歡迎訪問網易雲社區，瞭解更多網易技術產品運營經驗。

基本概念

直接介紹概念太枯燥了，仍是拿個和背景篇類似的例子介紹 業務場景：客戶完成下單，快遞員接受並更新運單狀態，客戶能夠隨時查看運單狀態的任務。一票快遞可能有多個子母件。同時，咱們須要標記每一個運單的狀態，運單狀態的解釋和含義保存在運單狀態字典表中。 所以，咱們須要創建以下表：咱們如今按照業務將數據庫垂直拆分紅運單庫（單表2000tps，6000W數據），快遞員庫（單表1500tps，100W數據），客戶庫（單表1500tps，1000W數據記錄）；假設每一個MySQL數據庫單表不能超過2000W數據，單表不能超過1000tps。那麼運單庫則須要分紅3片，客戶庫須要分紅2片，統一由MyCat管理。以下圖所示：

1.邏輯庫

MyCat做爲一箇中間件，對應用應爲無感知的。 應用訪問MyCat，根據以前所述，應用感知到後臺只是一個（或者多個，和訪問MySQL實例同樣）數據庫（假設只有一個數據庫，這個庫叫SF，裏面有運單相關表，快遞員相關表和客戶相關表）；這裏MyCat的數據庫就是邏輯庫。訪問MyCat，結果應該以下面所示雖然其中的表可能存在於不一樣的庫，可是表面上，他們屬於同一個MyCat實例中的同一個邏輯庫。因此，雖然上面的架構圖顯示他們不在同一個數據庫，可是在MyCat中，他們在同一個邏輯庫。

2.邏輯表

在邏輯庫下的表就是邏輯表。邏輯表能夠分片，也能夠不分片。 orders代表顯是要分片的表，可是在MyCat看來，他們雖然分佈在不一樣的分片節點上（分佈在不一樣的MySQL數據庫上），但仍視爲是同一個邏輯表，在同一個邏輯庫裏。

2.1分片表

分片表，是指那些原有的很大數據的表，須要切分到多個數據庫的表，這樣，每一個分片都有一部分數據，全部分片構成了完整的數據。分片表都有本身的分片規則，根據分片規則肯定分片。 配置裏面，以下配置：

<table name="orders" primaryKey="id" dataNode="test$1-2" rule="mod-long"></table>

意思就是用mod-long規則根據主鍵id將運單表orders分割到test1，test2這兩個數據庫（分片節點）上。請求狀況1：

select * from orders where id = 1;

對於分片表的查詢，若是按照分片列查詢，則請求只會被髮送到一個分片上。請求狀況2：

select * from orders where id < 100 and id > 0;

對於分片表的查詢，若是按照分片列範圍（在字段類型支持範圍的狀況下）查詢，則請求會根據分片規則計算兩個邊界值，而後將請求發送到對應結果的分片上，併合並每一個分片的結果。請求狀況3：

select * from orders where initialpoint = 'Beijing';

像這種根據非分片列查詢的狀況，請求會被髮送到全部分片上，併合並每一個分片的結果。請求狀況4：請求爲更新類型的sql語句，與查詢的三種狀況相同處理。

2.2 非分片表

一個數據庫中並非全部的表都很大，某些表是能夠不用進行切分的，非分片是相對分片表來講的，就是那些不須要進行數據切分的表。 例如：

<table name="courier" primaryKey="id" dataNode="test3"></table>

意思就是快遞員表不用分片，保存在test3這個分片節點上。 對於非分片表的操做和對普通數據庫的同樣，由於不涉及到分佈式數據庫。

2.3 ER表

關係型數據庫是基於實體關係模型（Entity-Relationship Model)之上，經過其描述了真實世界中事物與關係，Mycat中的ER表便是來源於此。根據這一思路，提出了基於E-R關係的數據分片策略，子表的記錄與所關聯的父表記錄存放在同一個數據分片上，即子表依賴於父表，經過表分組（Table Group）保證數據Join不會跨庫操做。 表分組（Table Group）是解決跨分片數據join的一種很好的思路，也是數據切分規劃的重要一條規則。 以下：

<!-- 運單表，對主鍵id對2取模 --><table name="orders" primaryKey="id" dataNode="test$1-2" rule="mod-long">
    <!-- 運單子母件表，運單表的子表，order_id與orders的id列對應 -->
    <childTable name="orders_cargo" joinKey="order_id" parentKey="id">
    </childTable>        </table>

運單表爲分片表，運單表和運單子母件表爲一對多關係，能夠作成父子表。 對於子表的sql請求，都是經過joinKey對應到父表對應字段後，按照以前分片表的規則進行處理。

2.4 全局表

一個真實的業務系統中，每每存在大量的相似字典表的表，這些表基本上不多變更，字典表具備如下幾個特性：

• 變更不頻繁

• 數據量整體變化不大

• 數據規模不大，不多有超過數十萬條記錄。

對於這類的表，在分片的狀況下，當業務表由於規模而進行分片之後，業務表與這些附屬的字典表之間的關聯，就成了比較棘手的問題，因此Mycat中經過數據冗餘來解決這類表的join，即全部的分片都有一份數據的拷貝，全部將字典表或者符合字典表特性的一些表定義爲全局表。 數據冗餘是解決跨分片數據join的一種很好的思路，也是數據切分規劃的另一條重要規則 好比：

<!-- 運單狀態信息表，公共表，放在和運單表一樣的分片上 --><table name="order_status_interception" primaryKey="id" type="global" dataNode="test$1-2"></table>

運單狀態信息字典表，只是註釋每種運單狀態，就是典型的字典表，與分片表orders爲多對一的關係。 對於全局表，全部的查詢請求，只會發送到其中一個全局表分片上執行，全部的更新請求，會在每一個全局表分片上執行。

2.5 如何決定？

根據以前的描述，咱們能夠推斷出，對於分片表的修改和查詢，若是是按照分片字段進行查找的話，則請求會被轉發到一個分片上。若是不是按照分片字段的話，就會把請求發到每個分片上進行查找。因此，分片字段的選擇比較重要！對於全局表，至關於在每一個分片上有一份相同的複製，修改請求會在每個分片上執行，可是查詢只會落到一個分片上。因此，全局表儘可能是不會改變的並且是須要和分片表作Join操做的，若是常常改變或者不須要作join，最好仍是作成非分片表。

先拋出了這幾種邏輯表的概念，你們先有個印象。如今咱們結合具體實際討論如何決定表的類型。

首先，orders表可定是分片表。orders_cargo表是子母件表，一個order可能有多個子母件，因此，最好把orders_cargo做爲orders的子表。 這種狀況下，orders與orders_cargo按照對應鍵（就是子表按照哪一個鍵與主表的哪一個鍵對應進行分片。好比orders_cargo就是order_id與orders的id對應。這是以order_id與orders的id進行join結果就是對的）join結果也是正確的。像這種簡單的從屬關係一對n的表，咱們處理起來很簡單，通常將它們按照須要作join的鍵設爲父子表便可。

可是下面的場景很麻煩，好比快遞員與運單就是多對多的關係，客戶對於運單也是多對多的關係（一個收方，一個寄方）。咱們既有快遞員須要查看本身的全部運單的場景和客戶查看本身全部運單的場景。相對的，咱們也有查看一個運單涉及到的快遞員還有客戶的場景。 customer表（客戶表）以及courier表（快遞員表）由於與分片表orders之間不作join操做，因此不用做爲公共表。 首先，關係表能夠做爲公共表，這樣的話，涉及到與分片表的join操做沒有限制，由於在每一個分片，公共表都是完整的。可是，關係表的更新很頻繁，咱們可能不能忍受每更新一次關係表就跑到每一個分片上都更新一次（性能，可靠性考慮）。 那麼做爲運單的子表呢？那麼查找一個運單涉及到的快遞員還有客戶就比較簡單。由於根據運單號（也就是分片id）查詢，MyCat就會根據分片規則給他定位到具體分片，而不是去按分片搜索。

可是相應的，快遞員查看本身全部運單的場景就比較慢，由於請求是發送到每個分片上查找。做爲快遞員的子表也有一樣的缺陷。 還有一種方法，就是這種關係表同時做爲運單和快遞員的子表。可是這樣，目前須要應用本身去作雙寫。MyCat目前還沒實現這種。固然，我以爲這是一個咱們本身能夠根據須要改進的地方。MyCat中間件根據關係冗餘表關係進行雙寫

另外，究竟取哪一種方法，都是從業務出發去考慮的。在這裏，若是從快遞員出發去查找以及從運單出發去查找的業務壓力差很少大的話，那麼最好就採用關係表同時做爲運單和客戶的子表這種方法。而後將快遞員和運單的業務獨立，每一個業務應用都去維護本身的關係表，同時經過消息隊列來保持關係表之間的一致性。這樣也不失爲一種方法。

免費體驗雲安全(易盾)內容安全、驗證碼等服務

更多網易技術、產品、運營經驗分享請點擊。

相關文章：
【推薦】 大數據技術在金融行業的應用前景
【推薦】 寓教於樂——玩轉角色互換遊戲
【推薦】 巧用Scrum與Kanban