MyCat - 背景篇（1）

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

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

SQL與NoSQL

目前，對於互聯網海量數據的存儲以及處理，按使用場景，分爲OLTP（聯機事務處理，好比即時交易，強調快速響應與處理）與OLAP（聯機分析處理，好比BI，強調多維數據分析）。對於這些數據的存儲，主要有兩種解決方案，即基於SQL的關係型數據庫，和NoSQL的非關係型數據庫。 非關係型數據庫在某些特定場景下有奇效，好比鍵值存儲（redis,ROMA,Memcached）數據庫應用在排行更新，會話保存，面向文檔的數據庫（mongoDB、couchDB）應用在日誌記錄，面向列的數據庫（Cassandra、HBase）在博客中的應用。關係型數據庫最大的問題在於速度與可擴展性上，而這些NoSQL數據庫通常部署簡單，支持擴展，並且速度極高。 可是，NoSQL目前仍是隻能作爲關係型數據庫在某些特定應用場景的補充，不能徹底替代嚴謹規範的關係型數據庫。

關係型數據庫瓶頸

目前商用的數據庫以及開源的數據庫通常都不支持大規模自動擴展，單庫上面存在着性能瓶頸。通常的，MySQL數據庫單表超過1000W~2000W條記錄時，性能就會有比較明顯的降低。爲了提高性能以及能夠存儲數據的量，咱們須要分庫分表。

分庫分表

舉個例子，假設咱們原來的應用是爲了客戶完成下單，快遞員接受並更新運單狀態，客戶能夠隨時查看運單狀態的任務。一開始咱們的數據庫層架構設計（忽略其餘部分，好比緩存、CDN等）多是這樣：可是很快地，咱們發現，把全部的數據放在同一個庫裏面，隨着業務的增加，數據量太大，響應時間變得愈來愈慢。業務需求已經承受不住了。咱們首先作了垂直分片，按照業務模塊，將數據庫拆分紅了快遞員庫，運單庫和客戶庫來管理。再以後，咱們發現運單單表有效數據量量級已經超過了2000W條，爲了避免影響TPS與QPS。咱們須要把運單表作進一步的水平拆分。可是，水平分片後，像分片表關聯這種操做，好比order by,group by還有join就不能經過數據庫本身自己去完成了，由於每一個分片庫的數據都不是完整的。並且，跨分片事務（即分佈式事務，分佈式XA），比較難以實現。 拆分規則有不少種，須要根據具體業務決定。好比若是咱們總體業務TPS小於單庫可承受TPS，只是咱們天天要產生2000W記錄，並且這些記錄要保存一週。咱們能夠按照日期分片，好比周一的數據保存到庫1，以後以此類推。可是這樣作的缺點很明顯，同一天的寫壓力全都打到一個分片上，其餘分片處於寫空閒狀態。即便總體業務TPS小於單庫可承受TPS，這樣的架構也不利於之後業務增加進行擴展。 咱們還能夠按照運單號對某一數字（分片個數）取模，讓這些運單平均分佈到每一個後臺分片庫上。這樣，咱們能夠保證同一時間全部的分片都是工做狀態，沒有資源浪費。可是，將來若是分片不夠用了，擴容難仍是個問題。 還有不少其它分片的規則（好比wang-jeekins哈希取模範圍，擴容哈希範圍，id字段範圍等），在以後的MyCat中間件具體使用篇我會詳細介紹，並給出一些原創的可行的分片方案。

誰來分庫分表

實現這種分庫分表能夠有多種思路，看上面的架構圖，咱們能夠：

• 在數據庫層作手腳

• 在應用層作手腳

• 在應用層與數據庫層添加數據庫路由中間件（至關於代理）

  首先，在數據庫層作手腳，須要數據庫產品爲開源的，並且修改MySQL和MariaDB之類的數據庫須要至關專業的團隊以及較高的成本，因此，通常項目初期不會考慮這種方式。

而後是在應用層作手腳，像Ibatis sharding, shark，TDDL等。他們實現分庫分表的思路是很類似的：通常這些框架很輕量級，在應用端放一個jar。他們自己不必定都實現了動態配置，可是他們均可以和Disconf之類的動態配置中心結合，實現動態數據源與動態分片規則。首先，應用會訪問附近的配置中心，配置中心會告訴這個應用應該去訪問哪一個數據庫以及分片規則是什麼。以後，應用會本身去訪問數據庫，並做分片和合並結果。 這樣作的好處是：

• 實現分片和結果聚合的壓力分攤給了每個應用

• 根據應用業務場景開發對應的功能

• 輕量級，代碼少

• 能最大發揮後臺數據庫的能力 可是同時，也有它的侷限性：

• 依賴於額外的配置中心實現動態配置

• 對應用代碼有侵入性

• 使應用處理變重

• 應用出問題難以定位是哪裏出了問題

• 將業務開發與後臺數據庫分庫分表管理耦合，難於開發管理

最後，是代理的方式：實現思路大概是，實現mysql協議棧，將本身假裝成一個mysql數據庫，本身後臺管理全部mysql實例。應用無感知，只當後臺只是一個mysql實例。這個代理mysql實例，實現分庫分表，結果合併等功能。 這種代理實現的好處在於：

• 對應用沒有侵入性

• 壓力打在中間件上

• 統一管理後臺數據庫，能及時定位問題 可是，他也有本身的缺陷，首先就是壓力打在中間件上的話，可能不能發揮後臺數據庫最大的能力。由此，中間件須要作負載均衡集羣，這要求中間件必須是無狀態的。可是，這無疑增長了架構的複雜程度。目前，淘寶的高吞吐量業務仍是在用TDDL相似的產品也是這個緣由。 這兩種實現方式還都有共同的難以解決的問題，好比分佈式事務這個問題，目前也沒有很是完美的方案。還有，他們對於SQL都有限制（好比有的不支持DDL，大部分都不推薦使用大事務等） 總體說來，項目初期使用代理這種實現方式仍是利大於弊的，網上有不少開源產品，他們基本和淘寶的Amoeba和Cobar一脈相承。實際應用場景衆多，較爲可靠。本文即將介紹的MyCat也不例外。下一篇咱們將更詳細地介紹MyCat的背景 :-D

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

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

相關文章：
【推薦】 知物由學 | AI時代，那些黑客正在如何打磨他們的「利器」？（一）
【推薦】 Hive中文註釋亂碼解決方案
【推薦】 分佈式存儲系統可靠性系列三：設計模式