目錄
前言
當今社會一些公司試圖通過收購等手段遏制開源產品的發展，那麼，那些開源產品愛好者們和貢獻者們獲得了什麼呢？在【無私奉獻】的過程中他們獲得了知識——信息社會最有價值的資產，他們可以用這些知識以任何形式換來不可估量的財富，信息社會的開源組織使【按勞分配】達到了前所未有的公平與公正。企業所採取的期權激勵、扁平化管理、自由工作時間等模式，正是對公司這種生產關係【自頂向下】的改良，以適應持久技術進步帶來的生產力的高速發展。但公司的本質：追求股東利益最大化，使其不可能實現真正意義的去中心化。信息社會的開源組織形態是對原有公司模式【自底向上】的一次顛覆式創新，他們將帶來生產力的極速發展。這種組織先天具有開放、共享、敏捷、去中心化等等這些可以帶來高效率的特性，可以想像擁有傑出技術與高效團隊的開源組織可以創造出超越一切公司的更優秀的產品。
關於分佈式數據庫中間件產品 Mycat，它並不是由任何一家公司主導開發的，而是由民間自發組織的由那些喜愛它的不知名的開源愛好者們協同開發的，而如今該產品的發展速度極快，其影響力也逐漸擴大。國內外類似的開源組織和產品還有很多，這些開源產品潛力無限，無論開發效率和質量都逐漸超越任何一家公司的產品。
開源分佈式數據庫中間件MyCat架構簡介——MyCat源起
一、數據庫切分概述：OLTP和OLAP
在互聯網時代，海量數據的存儲與訪問成爲系統設計與使用的瓶頸問題，對於海量數據處理，按照使用場景，主要分爲兩種類型：聯機事務處理（OLTP）和聯機分析處理（OLAP）。
聯機事務處理（OLTP）：也稱爲面向交易的處理系統，其基本特徵是原始數據可以立即傳送到計算中心進行處理，並在很短的時間內給出處理結果。
聯機分析處理（OLAP）：是指通過多維的方式對數據進行分析、查詢和報表，可以同數據挖掘工具、統計分析工具配合使用，增強決策分析功能。
對於兩者的主要區別可以用下表來說明：
|
OLTP
|
OLAP | |
|---|---|---|
|
系統功能
|
日常交易處理
|
統計、分析、報表
|
|
DB 設計
|
面向實時交易類應用
|
面向統計分析類應用
|
|
數據處理
|
當前的, 最新的細節的, 二維的分立的
|
歷史的, 聚集的, 多維的集成的, 統一的
|
|
實時性
|
實時讀寫要求高
|
實時讀寫要求低
|
|
事務
|
強一致性
|
弱事務
|
|
分析要求
|
低、簡單
|
高、複雜
|
二、關係型數據庫和NoSQL數據庫
針對上面兩類系統有多種技術實現方案，存儲部分的數據庫主要分爲兩大類：關係型數據庫與NoSQL數據庫。
關係型數據庫：是建立在關係模型基礎上的數據庫，其藉助於集合代數等數學概念和方法來處理數據庫中的數據。主流Oracle、DB2、MS SQL Server和mysql都屬於這類傳統的關係型數據庫。
NoSQL數據庫：全稱爲Not Only SQL，意思就是適用關係型數據庫的時候就使用關係型數據庫，不適用的時候也沒有必要非使用關係型數據庫不可，可以考慮使用更加合適的數據存儲。主要分爲臨時性鍵值存儲（memcached、Redis）、永久性鍵值存儲（ROMA、Redis）、面向文檔的數據庫（MongoDB、CouchDB）、面向列的數據庫（Cassandra、HBase），每種NoSQL都有其特有的使用場景及優點。
Oracle，MySQL 等傳統的關係數據庫非常成熟並且已大規模商用，爲什麼還要用NoSQL數據庫呢？主要是由於隨着互聯網發展，數據量越來越大，對性能要求越來越高，傳統數據庫存在着先天性的缺陷，即單機（單庫）性能瓶頸，並且擴展困難。這樣既有單機單庫瓶頸，卻又擴展困難，自然無法滿足日益增長的海量數據存儲及其性能要求，所以纔會出現了各種不同的NoSQL產品，NoSQL 根本性的優勢在於在雲計算時代，簡單、易於大規模分佈式擴展，並且讀寫性能非常高。
三、關係型數據庫和NoSQL數據庫的特點及優缺點
1、關係型數據庫
特點：
- 數據關係模型基於關係模型，結構化存儲，完整性約束；
- 基於二維表及其之間的聯繫，需要連接、並、交、差、除等數據操作；
- 採用結構化的查詢語言（SQL）做數據讀寫；
- 操作需要數據的一致性，需要事務甚至是強一致性；
優點：
- 保持數據的一致性（事務處理）；
- 可以進行join等複雜查詢；
- 通用化，技術成熟；
缺點:
- 數據讀寫必須經過sql解析，大量數據、高併發下讀寫性能不足；
- 對數據做讀寫，或修改數據結構時需要加鎖，影響併發操作；
- 無法適應非結構化存儲；
- 擴展困難；
- 昂貴、複雜；
2、NoSQL數據庫
特點：
- 非結構化的存儲；
- 基於多維關係模型；
- 具有特有的使用場景；
優點：
- 高併發，大數據下讀寫能力較強；
- 基本支持分佈式，易於擴展，可伸縮；
- 簡單，弱結構化存儲；
缺點：
- join等複雜操作能力較弱；
- 事務支持較弱；
- 通用性差；
- 無完整約束複雜業務場景支持較差；
雖然在雲計算時代，傳統數據庫存在着先天性的弊端，但是NoSQL數據庫又無法將其替代，NoSQL只能作爲傳統數據的補充而不能將其替代，所以規避傳統數據庫的缺點是目前大數據時代必須要解決的問題。如果傳統數據易於擴展，可切分，就可以避免單機（單庫）的性能缺陷，但是由於目前開源或者商用的傳統數據庫基本不支持大規模自動擴展，所以就需要藉助第三方來做處理，那就是本文要講的數據切分，下面就來分析一下如何進行數據切分。
四、關於數據切分
簡單來說，就是指通過某種特定的條件，將我們存放在同一個數據庫中的數據分散存放到多個數據庫（主機）上面，以達到分散單臺設備負載的效果。
數據的切分（Sharding）根據其切分規則的類型，可以分爲兩種切分模式：一種是按照不同的表（或者Schema）來切分到不同的數據庫（主機）之上，這種切可以稱之爲數據的垂直（縱向）切分；另外一種則是根據表中的數據的邏輯關係，將同一個表中的數據按照某種條件拆分到多臺數據庫（主機）上面，這種切分稱之爲數據的水平（橫向）切分。
垂直切分的最大特點就是規則簡單，實施也更爲方便，尤其適合各業務之間的耦合度非常低，相互影響很小，業務邏輯非常清晰的系統。在這種系統中，可以很容易做到將不同業務模塊所使用的表分拆到不同的數據庫中。根據不同的表來進行拆分，對應用程序的影響也更小，拆分規則也會比較簡單清晰。
水平切分，水平切分與垂直切分相比，相對來說稍微複雜一些。因爲水平切分需要將同一個表中的不同數據拆分到不同的數據庫中，對於應用程序來說，拆分規則本身就較根據表名來拆分更爲複雜，後期的數據維護也會更爲複雜一些。
1、垂直切分
一個數據庫由很多表的構成，每個表對應着不同的業務，垂直切分是指按照業務將表進行分類，分佈到不同的數據庫上面，這樣也就將數據或者說壓力分擔到不同的庫上面，如下圖：
如上圖系統被切分成了商品系統、用戶系統、訂單系統、購物車系統。
一個架構設計較好的應用系統，其總體功能肯定是由很多個功能模塊所組成的，而每一個功能模塊所需要的數據對應到數據庫中就是一個或者多個表。而在架構設計中，各個功能模塊相互之間的交互點越統一越少，系統的耦合度就越低，系統各個模塊的維護性以及擴展性也就越好。這樣的系統，實現數據的垂直切分也就越容易。
但是往往系統之有些表難以做到完全的獨立，存在這擴庫join的情況，對於這類的表，就需要去做平衡，是數據庫讓步業務，共用一個數據源，還是分成多個庫，業務之間通過接口來做調用。在系統初期，數據量比較少，或者資源有限的情況下，會選擇共用數據源，但是當數據發展到了一定的規模，負載很大的情況，就需要必須去做分割。
一般來講業務存在着複雜join的場景是難以切分的，往往業務獨立的易於切分。如何切分，切分到何種程度是考驗技術架構的一個難題。
垂直切分的優點：
- 拆分後業務清晰，拆分規則明確；
- 系統之間整合或擴展容易；
- 數據維護簡單；
垂直切分的缺點：
- 部分業務表無法join，只能通過接口方式解決，提高了系統複雜度；
- 受每種業務不同的限制存在單庫性能瓶頸，不易數據擴展跟性能提高；
- 事務處理複雜；
- 由於垂直切分是按照業務的分類將表分散到不同的庫，所以有些業務表會過於龐大，存在單庫讀寫與存儲瓶頸，所以就需要水平拆分來做解決；
2、水平切分
相對於垂直拆分，水平拆分不是將表做分類，而是按照某個字段的某種規則來分散到多個庫之中，每個表中包含一部分數據。簡單來說，我們可以將數據的水平切分理解爲是按照數據行的切分，就是將表中的某些行切分到一個數據庫，而另外的某些行又切分到其他的數據庫中，如圖：
這樣所有的數據查詢join都會在單庫內解決；如果從商戶的角度來講，要查詢某個商家某天所有的訂單數，就需要按照商戶ID做拆分；但是如果系統既想按會員拆分，又想按商家數據，則會有一定的困難。如何找到合適的分片規則需要綜合考慮衡量。
幾種典型的分片規則包括：
- 按照用戶ID求模，將數據分散到不同的數據庫，具有相同數據用戶的數據都被分散到一個庫中；
- 按照日期，將不同月甚至日的數據分散到不同的庫中；
- 按照某個特定的字段求摸，或者根據特定範圍段分散到不同的庫中；
如圖，切分原則都是根據業務找到適合的切分規則分散到不同的庫，下面根據商品ID（ItemId）求模舉例：
水平切分優點：
- 拆分規則抽象好，join操作基本可以數據庫做；
- 不存在單庫大數據，高併發的性能瓶頸；
- 應用端改造較少；
- 提高了系統的穩定性跟負載能力；
水平切分的缺點：
- 拆分規則難以抽象；
- 分片事務一致性難以解決；
- 數據多次擴展難度跟維護量極大；
- 跨庫join性能較差；
垂直切分和水平切分的共同的缺點：
- 引入分佈式事務的問題；
- 跨節點join的問題；
- 跨節點合併排序分頁問題；
- 多數據源管理問題；
3、針對數據源管理，目前主要的兩種思路
第一種：客戶端模式，在每個應用程序模塊中配置管理自己需要的一個（或者多個）數據源，直接訪問各個數據庫，在模塊內完成數據的整合；
第二種：通過中間代理層來統一管理所有的數據源，後端數據庫集羣對前端應用程序透明；
可能90%以上的人在面對上面這兩種解決思路的時候都會傾向於選擇第二種，尤其是系統不斷變得龐大複雜的時候。確實，這是一個非常正確的選擇，雖然短期內需要付出的成本可能會相對更大一些，但是對整個系統的擴展性來說，是非常有幫助的。
Mycat 通過數據切分解決傳統數據庫的缺陷，又有了NoSQL易於擴展的優點。通過中間代理層規避了多數據源的處理問題，對應用完全透明，同時對數據切分後存在的問題，也做了解決方案。下面章節就分析，mycat 的由來及如何進行數據切分問題。由於數據切分後數據 join 的難度，在此也分享一下數據切分的經驗（四個原則）：
- 第一原則：能不切分儘量不要切分；
- 第二原則：如果要切分一定要選擇合適的切分規則，提前規劃好；
- 第三原則：數據切分儘量通過數據冗餘或表分組（Table Group）來降低跨庫Join的可能；
- 第四原則：由於數據庫中間件對數據Join實現的優劣難以把握，而且實現高性能難度極大，業務讀取儘量少使用多表join；
五、Mycat的由來
如果我有一個32核心的服務器，我就可以實現1個億的數據分片，我有32核心的服務器麼？沒有，所以我至今無法實現1個億的數據分片。——Mycat's Plan
上面這句話是Mycat 1.0快要完成時候的一段感言，而當發展到Mycat 1.3的時候，又有了一個新的Plan：
如果我們有10臺物理機，我們就可以實現1000億的數據分片，我們有10臺物理機麼？沒有，所以，Mycat至今沒有機會驗證1000億大數據的支撐能力——Mycat's Plan 2.0
“每一個成功的男人背後都有一個女人”。自然Mycat也逃脫不了這個法則。Mycat背後是阿里曾經開源的知名產品——Cobar。Cobar的核心功能和優勢是 MySQL 數據庫分片，此產品曾經廣爲流傳，據說最早的發起者對 Mysql 很精通，後來從阿里跳槽了，阿里隨後開源的 Cobar，並維持到2013年年初，然後，就沒有然後了。
Cobar 的思路和實現路徑的確不錯。基於 Java 開發的，實現了 MySQL 公開的二進制傳輸協議，巧妙地將自己僞裝成一個MySQLServer，目前市面上絕大多數 MySQL 客戶端工具和應用都能兼容。比自己實現一個新的數據庫協議要明智的多，因爲生態環境在哪裏擺着。Cobar 使用起來也非常方便。由於是基於Java語言開發的，下載下來解壓，安裝JDK，然後配置幾個不是很複雜的配置文件，猛擊鼠標，就能啓動 Cobar。因此這個開源產品贏得了很多Java粉絲以及PHP用戶的追捧。
當然，笨人(Leader us)也跟着進入，並且在某個大型雲項目中——“苦海無邊”的煎着熬，良久。愛情就像是見鬼。只有撞見了，你纔會明白愛情是怎麼回事。TA是如此神祕，欲語還羞。情竇初開的你又玩命將TA的優點放大，使自己成爲一隻迷途的羔羊。每個用過 Cobar 的人就像談過一段一波三折、蕩氣迴腸的愛情，令你肝腸寸斷。就像圍城：裏面的人已經出不來了，還有更多的人拼命想擠進去。僅以此文，獻給哪些努力在IT界尋求未來的精英和小白們，還有更多被無視的，正準備轉行的同仁，同在江湖混，不容易啊，面試時候就裝裝糊塗，放人家一馬，說不定，以後又是一個Made in China的喬布斯啊。
曾經的Cobar
Cobar 曾是多少IT騷年心中的那個TA，有關Cobar的這段美好的描述(不能說是廣告)俘虜了衆多程序猿躁動純真的心：Cobar是阿里巴巴研發的關係型數據的分佈式處理系統，該產品成功替代了原先基於Oracle的數據存儲方案，目前已經接管了3000+個MySQL數據庫的schema，平均每天處理近50億次的SQL執行請求。
50億有多大？99%的普通人類看到這個數字，已經不能呼吸。當然，我指的是-RMB。99%的程序猿除了對工資比較敏感，其實對數字通常並不感冒。上面這個簡單的數字描述，已立刻讓我們程序型的大腦短路。恨不得立刻百度Cobar，立刻Download，立刻熬夜研究。做個簡單的推算，50億次請求轉換爲每個schema每秒的數據訪問請求即TPS，於是我們得到一個讓自己不能相信的數字：20TPS，每秒不到20個訪問。
Cobar最重要的特性是分庫分表。Cobar可以讓你把一個MySQL的Table放到10個甚至100個位於不同物理機上的MySQL服務器上去存儲，而在用戶看來是一張表（邏輯表）。這樣功能很有價值。比如：我們有1億的訂單，則可以劃分爲10個分片，存儲到2-10個物理機上。每個MySQL服務器的壓力減少，而系統的響應時間則不會增加。看上去很完美的功能，而且潛意識裏，執行這句SQL：select count(*) from employee，對於這類的SQL，100%的人都會認爲：會返回1條數據，但事實上，Cobar會返回N條數據，N=分片個數。接下來我們繼續執行SQL:select count(*) from employee order by employee_date你會發現奇怪的亂序現象，而且結果還隨機，這是因爲，Cobar只是簡單的把上述SQL發給了後端N個分片對應的MySQL服務器去執行，然後把結果集直接輸出….再繼續看看，我們常用的Limit分頁的結果…可以麼？答案是：<不可以>，這個問題可以在客戶端程序裏做些工作來解決。所以隨後出現了Cobar Client。據我所知，很多Cobar的使用者也都是自行開發了類似Cobar Client的工具來解決此類問題。從實際應用效果來說，一方面，客戶端編程方式解決，困難度很高，Bug率也居高不下；另一方面，對於DBA和運維來說，增加了困難度。當你發現這個問題的嚴重性，再回頭看看Cobar的官方文檔，你會悵然若失，四顧茫然。
Mycat 閃耀登場
當大批軟件工程師開始覺醒，用互聯網思維思考和規劃自己的人生，第四次工業革命才拉開序幕——《Mycat宣言》Mycat最早的版本完成於2013年年底，實現於霧霾中的北京城。Mycat 要解決的第一個問題就是要將Cobar後端實現爲非阻塞模式。
將 Cobar 從“個人版”提升到真正的“企業版”。據未經證實的渠道瞭解，非開源的 Cobar 內部版本已經實現後端 NIO，但是並沒有開源出來。於是 Mycat 註定要誕生了，儘管可能不會是Leader-us 發起的。但軟件界裏，總會有那麼一些桀驁（jié ào）不馴的人，用一個電腦，在某一個不經意的晚上，寫了一段代碼，驚豔了這個世界。Mycat 的前身是 OpencloudDB，而現在的 Mycat QQ 羣則用來開發一個叫做 Mycloud OA 的雲平臺的 SAAS 企業辦公軟件的，半年的時間裏，這個羣聚集了一大幫IT人，擁有超過10個“顧問”頭銜的、超過十個“架構師”頭銜的、超過20個“研發”頭銜的龐大志願者團隊，然後，僅有不到3個人提交過文檔和少量代碼，其他的人都很專業的談論着需求、談論着框架、談論着市場，最後的最後，大家都變成了資深醬油瓶，於是 Mycloud OA 出師未捷身先死。
OpencloudDB 改名爲 Mycat，一個原因是簡單好記，另外一個原因，是打算未來入駐 Apache。因爲 Apache Tomcat 也是一 只貓，從年齡來看，Tomcat 算是 Mycat 表姐吧，從相貌身材來看，Tomcat 她表妹，絕對是東方第一萌妹子，雖然目前 Rainbow 大俠設計的 Mycat Logo，看起來是個 100% 的女漢子。Mycat 1.0的發佈，立即引起不少人的關注，曾經參與 Mycloud OA 開發的一些小夥伴陸續加入進來，資深醬油師 Michael 還註冊了一個 opencloud DB 的網站，隨後又實現了 Mycat 全局序列號（基於文件方式）；一些瞭解或使用過 Cobar 的同學也陸續加入，網名爲無影的大俠，提供了最早的 Mycat 分頁排序的源碼，最早在生產系統上部署了 Mycat 並且採用 HA Proxy 方式做高可用方案；隨後，一個叫做小魚的 PHP 高手，在不到3個月時間內，用 Mycat 改造了原先的電商系統。後來又有一些美容美髮的 SAAS 創業項目採用了 Mycat；再後來，一些比較大的電信軟件領域的公司和項目開始使用 Mycat，他們中的大多數都對 Mycat 做過不少的貢獻，比如測試，Bug 修復等。
直到今天，Mycat 核心研發團隊裏的大多數人，都是來自上述這些公司。Mycat １.3的誕生，是 Mycat 歷史上最重大的一個里程碑。在這個版本里，需求、測試和功能開發各項工作，首次從個人爲主變爲開源團隊爲主的模式，更多的人蔘與到需求、開發、測試以及Bug修復活動中，基本上確定的 Bug 都在24小時內修復並有志願者或用戶確認修復。Mycat 1.3版本的性能與1.2比提升巨大，功能更完備，這是因爲包括武、成都-研發、冰峯影、Leader-us 等實力派編程高手各自負責一部分重要模塊並一起協同研發，後來又加入聆聽、從零開始、南哥、Mclaren、兵臨城下等新的一批實力派編程達人，以及正在排隊等待收編的PCY實力派干將，其他關於參與 Mycat 官網建設、文檔編寫和翻譯的就更多了（當然也失聯很多）。截至目前，Mycat 志願者團隊有以 Marshy 大美女爲首的負責官網和廣告的團隊，以 Leader-us 爲首的負責 Mycat-Server 研發的團隊、以 Rainbow 爲首的 Mycat-Web 的研發團隊、以海王星爲首的 QA 團隊，以及羣龍無首的測試團隊和DBA團隊。
此外，Mycat 開源社區正在進一步強化數據庫監控、智能調優等方面的功能，未來將實現一鍵優化的能力，根據攔截到的SQL的執行統計數據，自動分析熱點數據、給出建議的索引和優化措施以及讀寫分離的建議，DBA一鍵完成優化，數據遷移也將可以在節目上點擊鼠標完成。Mycat 截至到2015年4月，保守估計已經有超過60個項目在使用，主要應用在電信領域、互聯網項目，大部分是交易和管理系統，少量是信息系統。比較大的系統中，數據規模單表單月30億。以後 Mycat 和 Mycat 社區成爲IT和互聯網創業的最佳伴侶。
參考文獻：
MyCat官網：【MyCat官方網站】
GitHub：【MyCATApache】
Issues：【Mycat-Server-issues】
MyCat指南：【MyCat指南CSDN】
好了，關於 開源分佈式數據庫中間件MyCat架構簡介——MyCat源起 就寫到這兒了，如果還有什麼疑問或遇到什麼問題歡迎掃碼提問，也可以給我留言哦，我會一一詳細的解答的。
歇後語：“ 共同學習，共同進步 ”，也希望大家多多關注CSND的IT社區。
| 作 者： | 華 仔 |
| 聯繫作者： | [email protected] |
| 來 源： | CSDN (Chinese Software Developer Network) |
| 原 文： | https://blog.csdn.net/Hello_World_QWP/article/details/104945508 |
| 版權聲明： | 本文爲博主原創文章，請在轉載時務必註明博文出處！ |