|
來源：開發(fā)者頭條 最近公司推薦了mycat分布式中間件解決數(shù)據(jù)庫分布式方案，今天到mycat官網(wǎng)學了一翻（http://www.），匯總下幾個重點： 1、mycat是什么？ mycat是一個開源的分布式數(shù)據(jù)庫系統(tǒng),是一個實現(xiàn)了 MySQL 協(xié)議的Server,前端用戶可以把它看作是一個數(shù)據(jù)庫代理,用 MySQL 客戶端工具和命令進行訪問,后端可以用 MySQL 原生(Native)協(xié)議訪問數(shù)據(jù)庫（不限于MYSQL數(shù)據(jù)庫）, 其核心功能是分表分庫,即將一個多表水平分割為 N 個小表,存儲在后端的數(shù)據(jù)庫中。 以下是幾種通俗的方式介紹MYCAT： 1）對于 DBA 來講: Mycat 就是 MySQL Server,而 Mycat 后面連接的 MySQL Server,就好象是 MySQL 的存儲引擎,如 InnoDB,MyISAM 等,因此,Mycat 本身并不存儲數(shù)據(jù),數(shù)據(jù)是在后端的 MySQL 上存儲的,因此數(shù)據(jù)可靠性 以及事務等都是 MySQL 保證的,簡單的說,Mycat 就是 MySQL 最佳伴侶,它在一定程度上讓 MySQL 擁有了 能跟Oracle PK 的能力。 2）對于開發(fā)來講: Mycat 就是一個近似等于 MySQL 的數(shù)據(jù)庫服務器,你可以用連接 MySQL 的方式去連接 Mycat(除了端 口不同,默認的 Mycat 端口是 8066 而非 MySQL 的 3306,因此需要在連接字符串上增加端口信息),大多數(shù) 情況下,可以用你熟悉的對象映射框架使用 Mycat,但建議對于分片表,盡量使用基礎的 SQL 語句,因為返樣能 達到最佳性能,特別是幾千萬甚至幾百億條記錄的情況下。 3）對于架構師來講： Mycat 是一個強大的數(shù)據(jù)庫中間件,不僅僅可以用作讀寫分離、以及分表分庫、容災備份,而且可以用于多 租戶應用開發(fā)、平臺基礎設施、讓你的架構具備很強的適應性和靈活性,借助于即將發(fā)布的 Mycat 智能優(yōu)化模 塊,系統(tǒng)的數(shù)據(jù)訪問瓶頸和熱點一目了然,根據(jù)返些統(tǒng)計分析數(shù)據(jù),你可以自動或手工調(diào)整后端存儲,將不同的 表映射到不同存儲引擎上,而整個應用的代碼一行也不用改變。
2）雙活部署 mycat、zk均采用雙中心部署
3、常見的數(shù)據(jù)庫切分優(yōu)化方案 傳統(tǒng)數(shù)據(jù)庫存在著先天性的弊端,但是 NoSQL 數(shù)據(jù)庫又無法將其替今,NoSQL 只能作 為傳統(tǒng)數(shù)據(jù)的補充而不能將其替今,數(shù)據(jù)庫性能優(yōu)化除了在應用層對數(shù)據(jù)檢索方面的調(diào)優(yōu)，在架構方面主要對數(shù)據(jù)庫進行切分，接下來主要從數(shù)據(jù)庫切分的兩個方面進行介紹: 1）垂直切分： 如果應用系統(tǒng)各業(yè)務或服務之間的耦合度低，相互影響小，可以接不同的模塊分解，將數(shù)據(jù)庫切分到不同的數(shù)據(jù)庫。
2）水平切分： 上面垂直切分，當某個業(yè)務量很大時仍然會有性能問題，比如某個表的數(shù)據(jù)量過大，這時需要進行水平切分，將大表切分為多個子表。各個子表之間根據(jù)預先設置的分布規(guī)則，再通過數(shù)據(jù)庫查詢JOIN在一起。 水平分片常見的規(guī)則有：
有了數(shù)據(jù)分布，現(xiàn)在要解決的問題是如何讓應用更加透明的訪問分片的數(shù)據(jù)，目前主要有兩種思路： 1）客戶端模式：在每個應用程序模塊中配置管理自己需要的一個或多個數(shù)據(jù)源，直接訪問各個數(shù)據(jù)庫，在模塊內(nèi)完成數(shù)據(jù)的整合； 2）通過中間代理層來統(tǒng)一管理數(shù)據(jù)源，后端數(shù)據(jù)庫集群對前端應用程序透明； mycat提供了模式2的解決方案。 不過，因為分片需要注意以下幾件事： 能不切分盡量不切分 如果要切分要選擇合適的規(guī)則 數(shù)據(jù)切分盡量通過數(shù)據(jù)冗余或表分組來降低跨庫JOIN的可能 4、mycat的幾個主要組成概念 MyCAT使用MySQL的通訊協(xié)議模擬成一個MySQL服務器，并建立了完整的Schema（數(shù)據(jù)庫）、Table （數(shù)據(jù)表）、User（用戶）的邏輯模型，并將這套邏輯模型映射到后端的存儲節(jié)點DataNode（MySQL Instance）上的真實物理庫中，這樣一來，所有能使用MySQL的客戶端以及編程語言都能將MyCAT當成是MySQLServer來使用，不必開發(fā)新的客戶端協(xié)議。 當MyCAT收到一個客戶端發(fā)送的SQL請求時，會先對SQL進行語法分析和檢查，分析的結果用于SQL路由，SQL路由策略支持傳統(tǒng)的基于表格的分片字段方式進行分片，也支持獨有的基于數(shù)據(jù)庫E-R關系的分片策略，對于路由到多個數(shù)據(jù)節(jié)點（DataNode）的SQL，則會對收到的數(shù)據(jù)集進行“歸并”然后輸出到客戶端。 SQL執(zhí)行的過程，簡單的說，就是把SQL通過網(wǎng)絡協(xié)議發(fā)送給后端的真正的數(shù)據(jù)庫上進行執(zhí)行，對于MySQL Server來說，是通過MySQL網(wǎng)絡協(xié)議發(fā)送報文，并解析返回的結果，若SQL不涉及到多個分片節(jié)點，則直接返回結果，寫入客戶端的SOCKET流中，這個過程是非阻塞模式（NIO）。 DataNode是MyCAT的邏輯數(shù)據(jù)節(jié)點，映射到后端的某一個物理數(shù)據(jù)庫的一個Database，為了做到系統(tǒng)高可用，每個DataNode可以配置多個引用地址（DataSource），當主DataSource被檢測為不可用時，系統(tǒng)會自動切換到下一個可用的DataSource上，這里的DataSource即可認為是Mysql的主從服務器的地址。 在介紹mycat的主要組成部份時，先了解一下MYCAT的原理： MyCat技術原理中最重要的一個動詞是“攔截”，它攔截了用戶發(fā)送過來的SQL語句，首先對SQL語句做了一些特定的分析：如分片分析、路由分析、讀寫分離分析、緩存分析等，然后將此SQL發(fā)往后端的真實數(shù)據(jù)庫，并將返回的結果做適當?shù)奶幚?，最終再返回給用戶。 1）數(shù)據(jù)庫中間件 數(shù)據(jù)被分到多個分片數(shù)據(jù)庫后，應用如果需要讀取數(shù)據(jù)，需要多個數(shù)據(jù)源的數(shù)據(jù)，如果沒有數(shù)據(jù)庫中間件，那么應用需要花大量的工作去處理分片后的數(shù)據(jù)訪問問題，所以mycat首先是一個數(shù)據(jù)庫中間件，對于數(shù)據(jù)庫能用的事務、數(shù)據(jù)處理由中間件處理。 數(shù)據(jù)庫中間件的方式，使底層分布式數(shù)據(jù)對于上層應用而言是透明的，相當一個邏輯數(shù)據(jù)庫。 2）邏輯表 上面提到MYCAT是一個邏輯庫，那上面的表即是邏輯表，具體包括：
3）分片節(jié)點： 數(shù)據(jù)切分到多個不同的數(shù)據(jù)庫，切分后的數(shù)據(jù)庫可以按主從方式組成一組，分片節(jié)點就是datanode 4）分片規(guī)則： 數(shù)據(jù)分片需要提前定好規(guī)則，即大表要被分成若干分片表，要有一定的規(guī)則。 5）常用的幾個配置文件 MyCAT目前通過配置文件的方式來定義邏輯庫和相關配置： · MYCAT_HOME/conf/schema.xml中定義邏輯庫，表、分片節(jié)點等內(nèi)容； · MYCAT_HOME/conf/rule.xml中定義分片規(guī)則； · MYCAT_HOME/conf/server.xml中定義用戶以及系統(tǒng)相關變量，如端口等。 5、重點概念介紹之：【實施難點】分庫分表 首先先講講分庫分表的步驟： 1）尋找大表： 2）擴大拆分表范圍：有些表的數(shù)據(jù)可能沒有達到預定的大表數(shù)據(jù)量，但這些表與第一步提到的大表有關聯(lián)查詢，這些表需要一并找出來，然后定分片算法和拆分策略 3）定分片策略：這項工作很重要不僅需要懂mycat的同學參與，還需要懂應用的同學參與進來。 以下是互聯(lián)網(wǎng)上的一個案例以上面幾點的說明： 1）單表數(shù)據(jù)量在800以上視為大表 2）針對業(yè)務特點，按經(jīng)營區(qū)域、訂單單位、管理城市、經(jīng)營城市、店鋪、時間等進行拆分 3）對于部份字段拆表仍很大的情況，采用多個字段共同拆表 接下來講講分片的細節(jié)： 現(xiàn)在大部分表都不是孤立存在，以一個用戶表與用戶明細表為例，為了能夠執(zhí)行t_user與t_user_detail的聯(lián)合查詢， MyCAT將子表的存儲位置依賴于主表，并且物理上緊鄰存放，解決了JOIN的效率和性能問題，根據(jù)這一思路，提出了基于E-R關系的數(shù)據(jù)分片策略，子表的記錄與所關聯(lián)的父表記錄存放在同一個數(shù)據(jù)分片上。 以t_user與t_user_detail例子為例，schema.xml中定義如下的分片配置： <table name="t_user" dataNode="dn$1-32" rule="mod-long"> <childTable name="t_user_detail" primaryKey="id" joinKey="user_id"parentKey="user_id" /> </table t_user采用mod-long這個分片策略，分片在dn1-dn32上，t_user_detail依賴父表進行分片，兩個表的關聯(lián)關系為t_user_detail.user_id=t_user.id。于是數(shù)據(jù)分片和存儲的示意圖如下： 這樣一來，分片dn1-32上的t_user與hn1-32上的t_user_detail就可以進行局部的JOIN聯(lián)合，再合并兩個節(jié)點的數(shù)據(jù)即可完成整體的JOIN，試想一下，每個分片上t_user_detail表有1000萬條，則10個分片就有1個億，基于E-R映射的數(shù)據(jù)分片模式，基本上解決了80%以上的企業(yè)應用所面臨的問題。 多對多的表通常情況下，有以下幾種： l 主表+關系表+字典表 l 主表A+關系表+主表B 對于第一種，字典表可以被定義為“全局表”，字典表的記錄規(guī)?？梢栽趲浊У綆资f之間，基本是變動比較少的表，由MyCAT自動實時同步到所有分片，這樣就可以三個表都做JOIN操作了。 對于第二種，需要從業(yè)務角度來看，關系表更偏向哪個表，即“A的關系”還是“B的關系”，來決定關系表跟從那個方向存儲。目前還暫時無法很好支持這種模式下的3個表之間的關聯(lián)。未來版本中將考慮將中間表進行雙向復制，以實現(xiàn)從A-關系表 以及B-關系表的雙向關聯(lián)查詢。 關于全局表的實現(xiàn)方式，全局表在數(shù)據(jù)**或更新的時候，會自動在全局表定義的所有數(shù)據(jù)節(jié)點上執(zhí)行相同的操作，以保證所有數(shù)據(jù)節(jié)點都一致，由于這個特性，全局表可以跟任何分片或不分片的表格進行JOIN操作。對數(shù)據(jù)更新不頻繁的，規(guī)模不是很大的（100萬之內(nèi)）的表都可以定義為MyCAT的全局表，以實現(xiàn)用存儲換性能的目標。 配置為： 6、重點概念介紹之：MYSQL主從復制 經(jīng)驗告訴我們數(shù)據(jù)庫的性能問題往往出在SQL查詢之上，正常情況下一個查詢語句幾十毫秒內(nèi)可以完成，但查詢則可能幾秒，或幾分鐘以上。在沒有讀寫分離的系統(tǒng)上，一些復雜的SQL查詢會導致數(shù)據(jù)庫CPU爆表，系統(tǒng)陷入癱瘓，嚴重情況下可能導致數(shù)據(jù)庫崩潰。下面這個是MYSQL提供的主從數(shù)據(jù)庫的機制：
注：主從數(shù)據(jù)庫數(shù)據(jù)的復制可以通過日志、SQL等方式進行同步、異步、半異步的方式處理。
簡單列一下mycat的功能： 1）mycat配置 mycat的服務增減、日志管理等基本配置 2）mycat監(jiān)控 流量分析、連接分析、活動線程分析、緩沖隊列分析、TPS分析、內(nèi)存分析、JVM性能監(jiān)控
3）sql監(jiān)控 按用戶統(tǒng)計SQL讀寫比例、耗時、執(zhí)行時間、響應時間、排前面的50條SQL語句、高頻SQL、耗時長的SQL |
|
|
