隨着互聯網的發展，業務愈來愈龐大，客戶羣體也愈來愈多，所要存儲的數據也愈來愈多，慢慢的就出現了分庫分表的中間件。mysql
好比cobar，TDDL，atlas，sharding-jdbc，mycat等，都是很是優秀的產品，解決了各類問題，可是引入了中間件確定就會增長各方面的維護成本等面試
這篇帶你們瞭解一款替代分庫分表的解決方案：分佈式數據庫：TIDBsql
前言
現在硬件的性價比愈來愈高，網絡傳輸速度愈來愈快，數據庫分層的趨勢逐漸顯現，人們已經再也不強求用一個解決方案來解決全部的存儲問題，而是經過分層，讓緩存與數據庫負責各自擅長的業務場景。數據庫
當前數據庫領域面臨各類問題，如在縮放、一致性、大數據分析、與雲基礎架構集成等方面均存在諸多問題，現有的數據庫解決方案和大數據分析引擎解決方案基本處於割裂的狀態，因爲 Oracle、MySQL 數據庫並非面向分佈式環境而設計，所以即便勉強經過分庫、分表或中間件的方式，在數據庫層面作了分片，從本質上看也只是複製了相同的堆棧，而非針對分佈式系統進行存儲和計算優化，這正是進行跨業務查詢或跨物理機查詢和寫入十分繁瑣的本質緣由。NoSQL 雖然解決了數據庫彈性擴展的難題，可是卻放棄了數據的強一致性以及對 ACID 事務的支持，帶來了新的問題。緩存
爲了解決這一問題，TiDB 在架構上將計算和存儲層進行高度的抽象和分離，對混合負載的場景經過 IO 優先級隊列，智能副本調度，行列混合存儲等技術使其變爲可能。微信
你們可能都沒有聽過TIDB這款分佈式數據庫，可是它已經出現好久了，隨着不斷完善，也受到愈來愈多的企業喜好，接下來讓咱們開始瞭解TIDB吧！
TIDB簡介
TIDB是什麼？
TiDB 是一個分佈式 NewSQL 數據庫。它支持水平彈性擴展、ACID 事務、標準 SQL、MySQL 語法和 MySQL 協議，具備數據強一致的高可用特性，是一個不只適合 OLTP 場景還適合OLAP 場景的混合數據庫。網絡
TIDB怎麼來的？
開源分佈式緩存服務 Codis 的做者，PingCAP 聯合創始人& CTO ，資深 infrastructure 工程師的黃東旭，擅長分佈式存儲系統的設計與實現，開源狂熱分子的技術大神級別人物。即便在互聯網如此繁榮的今天，在數據庫這片邊界模糊且不肯定地帶，他還在努力尋找肯定性的實踐方向。架構
2012 年末，他看到 Google 發佈的兩篇論文，獲得了很大的觸動，這兩篇論文描述了 Google 內部使用的一個海量關係型數據庫 F1/Spanner ，解決了關係型數據庫、彈性擴展以及全球分佈的問題，並在生產中大規模使用。「若是這個能實現，對數據存儲領域來講將是顛覆性的」，黃東旭爲完美方案的出現而興奮， PingCAP 的 TiDB 在此基礎上誕生了。併發
TIDB的架構
TiDB在總體架構基本是參考 Google Spanner 和 F1 的設計，上分兩層爲 TiDB 和 TiKV 。TiDB 對應的是 Google F1， 是一層無狀態的 SQL Layer ，兼容絕大多數 MySQL 語法，對外暴露 MySQL 網絡協議，負責解析用戶的 SQL 語句，生成分佈式的 Query Plan，翻譯成底層 Key Value 操做發送給 TiKV ， TiKV 是真正的存儲數據的地方，對應的是 Google Spanner ，是一個分佈式 Key Value 數據庫，支持彈性水平擴展，自動的災難恢復和故障轉移（高可用），以及 ACID 跨行事務。值得一提的是 TiKV 並不像 HBase 或者 BigTable 那樣依賴底層的分佈式文件系統，在性能和靈活性上能更好，這個對於在線業務來講是很是重要。app
因此一套這樣的架構是由這樣的3類角色共同組建而成。每一個部分的解釋以下：
1.TiDB Server
TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，並經過 PD 找到存儲計算所需數據的 TiKV 地址，與 TiKV 交互獲取數據，最終返回結果。TiDB Server 是無狀態的，其自己並不存儲數據，只負責計算，能夠無限水平擴展，能夠經過負載均衡組件（如LVS、HAProxy 或 F5）對外提供統一的接入地址。
2.PD Server
Placement Driver (簡稱 PD) 是整個集羣的管理模塊，其主要工做有三個：一是存儲集羣的元信息（某個 Key 存儲在哪一個 TiKV 節點）；二是對 TiKV 集羣進行調度和負載均衡（如數據的遷移、Raft group leader 的遷移等）；三是分配全局惟一且遞增的事務 ID。PD 是一個集羣，須要部署奇數個節點，通常線上推薦至少部署 3 個節點。
3.TiKV Server
TiKV Server 負責存儲數據，從外部看 TiKV 是一個分佈式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region，每一個 Region 負責存儲一個 Key Range （從 StartKey 到 EndKey 的左閉右開區間）的數據，每一個 TiKV 節點會負責多個 Region 。TiKV 使用 Raft 協議作複製，保持數據的一致性和容災。副本以 Region 爲單位進行管理，不一樣節點上的多個 Region 構成一個 Raft Group，互爲副本。數據在多個 TiKV 之間的負載均衡由 PD 調度，這裏也是以 Region 爲單位進行調度。
TIDB五大核心特性
一鍵水平擴縮容
得益於 TiDB 存儲計算分離的架構的設計，可按需對計算、存儲分別進行在線擴容或者縮容，擴容或者縮容過程當中對應用運維人員透明。
金融級高可用
數據採用多副本存儲，數據副本經過 Multi-Raft 協議同步事務日誌，多數派寫入成功事務才能提交，確保數據強一致性且少數副本發生故障時不影響數據的可用性。可按需配置副本地理位置、副本數量等策略知足不一樣容災級別的要求。
實時HTAP
提供行存儲引擎 TiKV、列存儲引擎 TiFlash 兩款存儲引擎，TiFlash 經過 Multi-Raft Learner 協議實時從 TiKV 複製數據，確保行存儲引擎 TiKV 和列存儲引擎 TiFlash 之間的數據強一致。TiKV、TiFlash 可按需部署在不一樣的機器，解決 HTAP 資源隔離的問題。
雲原生的分佈式數據庫
專爲雲而設計的分佈式數據庫，經過 TiDB Operator 可在公有云、私有云、混合雲中實現部署工具化、自動化。
兼容MYSQL5.7
專爲雲而設計的分佈式數據庫，經過 TiDB Operator 可在公有云、私有云、混合雲中實現部署工具化、自動化。
TIDB四大核心應用場景
HTAP 給開發者提供了一個實時數據分析方面的新思路，不須要再去維護另外一個離線的數據倉庫，既減輕了 ETL 的工做，又能節省很大一部分創建數據倉庫所用到的存儲和計算成本，HTAP 將是將來的重要趨勢。
黃東旭介紹了 TiDB 的四個主要應用場景，一是 MySQL 分片與合併；二是直接替換 MySQL；三是用作數據倉庫；四是做爲其餘系統的一個模塊。
MySQL分片與合併
Syncer：
TiDB 應用的第一類場景是 MySQL 的分片與合併。對於已經在用 MySQL 的業務，分庫、分表、分片、中間件是經常使用手段，隨着分片的增多，跨分片查詢是一大難題。TiDB 在業務層兼容 MySQL 的訪問協議，PingCAP 作了一個數據同步的工具——Syncer，它能夠把 TiDB 做爲一個 MySQL Slave，將 TiDB 做爲現有數據庫的從庫接在主 MySQL 庫的後方，在這一層將數據打通，能夠直接進行復雜的跨庫、跨表、跨業務的實時 SQL 查詢。黃東旭提到，過去的數據庫都是一主多從，有了 TiDB 之後，能夠反過來作到多主一從。
替換MySQL
第二類場景是用 TiDB 直接去替換 MySQL。若是你的IT架構在搭建之初並未考慮分庫分表的問題，所有用了 MySQL，隨着業務的快速增加，海量高併發的 OLTP 場景愈來愈多，如何解決架構上的弊端呢?
在一個 TiDB 的數據庫上，全部業務場景不須要作分庫分表，全部的分佈式工做都由數據庫層完成。TiDB 兼容 MySQL 協議，因此能夠直接替換 MySQL，並且基本作到了開箱即用，徹底不用擔憂傳統分庫分表方案帶來繁重的工做負擔和複雜的維護成本，友好的用戶界面讓常規的技術人員能夠高效地進行維護和管理。另外，TiDB 具備 NoSQL 相似的擴容能力，在數據量和訪問流量持續增加的狀況下可以經過水平擴容提升系統的業務支撐能力，而且響應延遲穩定。
黃東旭在演講中提到了摩拜單車的案例，摩拜早期的數據庫所有用 MySQL，隨着業務的快速增加，MySQL 的弊端逐漸顯現，摩拜單車於 2017 年初開始使用 TiDB 替換 MySQL。現在，摩拜的 IT 系統中已部署了數套 TiDB 集羣，近百個節點，承載着數十 TB 的各種數據。
數據倉庫
TiDB 自己是一個分佈式系統，第三種使用場景是將 TiDB 看成數據倉庫使用。TPC-H 是數據分析領域的一個測試集，TiDB 2.0 在 OLAP 場景下的性能有了大幅提高，原來只能在數據倉庫裏面跑的一些複雜的 Query，在 TiDB 2.0 裏面跑，時間基本都能控制在 10 秒之內。固然，由於 OLAP 的範疇很是大，TiDB 的 SQL 也有搞不定的狀況，爲此 PingCAP 開源了 TiSpark，TiSpark 是一個 Spark 插件，用戶能夠直接用 Spark SQL 實時地在 TiKV 上作大數據分析。
做爲其餘系統的模塊
TiDB 是一個傳統的存儲跟計算分離的項目，其底層的 Key-Value 層，能夠單獨做爲一個 HBase 的 Replacement 來用，它同時支持跨行事務。TiDB 對外提供兩個 API 接口，一個是 ACID Transaction 的 API，用於支持跨行事務；另外一個是 Raw API，它能夠作單行的事務，換來的是整個性能的提高，但不提供跨行事務的 ACID 支持。用戶能夠根據自身的需求在兩個 API 之間自行選擇。例若有一些用戶直接在 TiKV 之上實現了 Redis 協議，將 TiKV 替換一些大容量，對延遲要求不高的 Redis 場景。
與MySQL兼容性對比
TiDB 支持包括跨行事務，JOIN 及子查詢在內的絕大多數 MySQL 的語法，用戶能夠直接使用現有的 MySQL 客戶端鏈接。若是現有的業務已經基於 MySQL 開發，大多數狀況不須要修改代碼便可直接替換單機的 MySQL。
包括現有的大多數 MySQL 運維工具（如 PHPMyAdmin, Navicat, MySQL Workbench 等），以及備份恢復工具（如 mysqldump, mydumper/myloader）等均可以直接使用。
不過一些特性因爲在分佈式環境下無法很好的實現，目前暫時不支持或者是表現與 MySQL 有差別。
一些 MySQL 語法在 TiDB 中能夠解析經過，可是不會作任何後續的處理，例如 Create Table 語句中 Engine 以及 Partition 選項，都是解析並忽略。
不支持的特性有如下這些：
存儲過程，視圖，觸發器，自定義函數，外鍵約束，全文索引，空間索引，非 UTF8 字符集等
總結
本文帶你瞭解了TIDB這款分佈式數據庫，它的特性，應用場景以及與MySQl的兼容性對比，下篇將會介紹TIDB的部署搭建，計算，存儲，調度方面的知識！
假如面試中你被問到這些，我相信你看了這篇必定能撥動面試官的心！
這篇文章來自於個人好朋友狼王的公衆號 「Garnett的Java之路」。
狼王目前在互聯網公司從事架構開發，他的號都是高質量的技術文章，各種學習視頻和資料免費分享，期待你的到來！
公衆號二維碼以下，回覆【資料】能夠領取海量學習資源。
私人微信我也給大家要來了，能夠加他偷窺他的朋友圈，還能夠私聊他進技術羣，羣內有來自不一樣大廠的N多大佬。
本文分享自微信公衆號 - 悟空聊架構（PassJava666）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。