TiDB整體架構(gòu)及的作用是什么，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

站在用戶的角度思考問題，與客戶深入溝通，找到開原網(wǎng)站設(shè)計(jì)與開原網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、域名注冊、虛擬空間、企業(yè)郵箱。業(yè)務(wù)覆蓋開原地區(qū)。

據(jù)我所知，目前很多公司都在生產(chǎn)環(huán)境使用TiDB了，例如:小米，小紅書，餓了嗎，美團(tuán)等。

      如今硬件的性價(jià)比越來越高，網(wǎng)絡(luò)傳輸速度越來越快，數(shù)據(jù)庫分層的趨勢逐漸顯現(xiàn)，人們已經(jīng)不再強(qiáng)求用一個(gè)解決方案來解決所有的存儲問題，而是通過分層，讓緩存與數(shù)據(jù)庫負(fù)責(zé)各自擅長的業(yè)務(wù)場景。  

當(dāng)前數(shù)據(jù)庫領(lǐng)域面臨各種問題，如在縮放、一致性、大數(shù)據(jù)分析、與云基礎(chǔ)架構(gòu)集成等方面均存在諸多問題，現(xiàn)有的數(shù)據(jù)庫解決方案和大數(shù)據(jù)分析引擎解決方案基本處于割裂的狀態(tài)，由于 Oracle、MySQL 數(shù)據(jù)庫并不是面向分布式環(huán)境而設(shè)計(jì)，因此即使勉強(qiáng)通過分庫、分表或中間件的方式，在數(shù)據(jù)庫層面做了分片，從本質(zhì)上看也只是復(fù)制了相同的堆棧，而非針對分布式系統(tǒng)進(jìn)行存儲和計(jì)算優(yōu)化，這正是進(jìn)行跨業(yè)務(wù)查詢或跨物理機(jī)查詢和寫入十分繁瑣的本質(zhì)原因。NOSQL 雖然解決了數(shù)據(jù)庫彈性擴(kuò)展的難題，但是卻放棄了數(shù)據(jù)的強(qiáng)一致性以及對 ACID 事務(wù)的支持，帶來了新的問題。

為了解決這一問題，TiDB 在架構(gòu)上將計(jì)算和存儲層進(jìn)行高度的抽象和分離，對混合負(fù)載的場景通過 IO 優(yōu)先級隊(duì)列，智能副本調(diào)度，行列混合存儲等技術(shù)使其變?yōu)榭赡堋iDB 作為開源的分布式關(guān)系數(shù)據(jù)庫，其特點(diǎn)是幾乎可以 100% 兼容 MySQL 接口，也兼容 MySQL 的語法和協(xié)議，在保證不喪失 ACID 事務(wù)的前提下，能夠彈性伸縮，高可用，可以同時(shí)處理 OLTP 和 OLAP 工作負(fù)載，不再需要 ETL。

TiDB整體架構(gòu)圖

TiDB 產(chǎn)品的整體架構(gòu)是高度分層的，由分布式 SQL 層（TiDB）、分布式 KV 存儲引擎（TiKV）以及管理整個(gè)集群的 PD 模塊組成。無限水平擴(kuò)展是 TiDB 的一大特點(diǎn)，這里所說的水平擴(kuò)展包括兩方面：計(jì)算能力和存儲能力。

HTAP 給開發(fā)者提供了一個(gè)實(shí)時(shí)數(shù)據(jù)分析方面的新思路，不需要再去維護(hù)另一個(gè)離線的數(shù)據(jù)倉庫，既減輕了 ETL 的工作，又能節(jié)省很大一部分建立數(shù)據(jù)倉庫所用到的存儲和計(jì)算成本，HTAP 將是未來的重要趨勢。黃東旭介紹了 TiDB 的四個(gè)主要應(yīng)用場景，一是 MySQL 分片與合并；二是直接替換 MySQL；三是用做數(shù)據(jù)倉庫；四是作為其他系統(tǒng)的一個(gè)模塊。

用例1：MySQL分片與合并

Syncer

TiDB 應(yīng)用的第一類場景是 MySQL 的分片與合并。對于已經(jīng)在用 MySQL 的業(yè)務(wù)，分庫、分表、分片、中間件是常用手段，隨著分片的增多，跨分片查詢是一大難題。TiDB 在業(yè)務(wù)層兼容 MySQL 的訪問協(xié)議，PingCAP 做了一個(gè)數(shù)據(jù)同步的工具——Syncer，它可以把 TiDB 作為一個(gè) MySQL Slave，將 TiDB 作為現(xiàn)有數(shù)據(jù)庫的從庫接在主 MySQL 庫的后方，在這一層將數(shù)據(jù)打通，可以直接進(jìn)行復(fù)雜的跨庫、跨表、跨業(yè)務(wù)的實(shí)時(shí) SQL 查詢。黃東旭提到，“過去的數(shù)據(jù)庫都是一主多從，有了 TiDB 以后，可以反過來做到多主一從。”

用例2：直接替換MySQL

第二類場景是用 TiDB 直接去替換 MySQL。如果你的IT架構(gòu)在搭建之初并未考慮分庫分表的問題，全部用了 MySQL，隨著業(yè)務(wù)的快速增長，海量高并發(fā)的 OLTP 場景越來越多，如何解決架構(gòu)上的弊端呢?

在一個(gè) TiDB 的數(shù)據(jù)庫上，所有業(yè)務(wù)場景不需要做分庫分表，所有的分布式工作都由數(shù)據(jù)庫層完成。TiDB 兼容 MySQL 協(xié)議，所以可以直接替換 MySQL，而且基本做到了開箱即用，完全不用擔(dān)心傳統(tǒng)分庫分表方案帶來繁重的工作負(fù)擔(dān)和復(fù)雜的維護(hù)成本，友好的用戶界面讓常規(guī)的技術(shù)人員可以高效地進(jìn)行維護(hù)和管理。另外，TiDB 具有 NoSQL 類似的擴(kuò)容能力，在數(shù)據(jù)量和訪問流量持續(xù)增長的情況下能夠通過水平擴(kuò)容提高系統(tǒng)的業(yè)務(wù)支撐能力，并且響應(yīng)延遲穩(wěn)定。

黃東旭在演講中提到了摩拜單車的案例，摩拜早期的數(shù)據(jù)庫全部用 MySQL，隨著業(yè)務(wù)的快速增長，MySQL 的弊端逐漸顯現(xiàn)，摩拜單車于 2017 年初開始使用 TiDB 替換 MySQL。如今，摩拜的 IT 系統(tǒng)中已部署了數(shù)套 TiDB 集群，近百個(gè)節(jié)點(diǎn)，承載著數(shù)十 TB 的各類數(shù)據(jù)。

用例3：數(shù)據(jù)倉庫

TiDB 本身是一個(gè)分布式系統(tǒng)，第三種使用場景是將 TiDB 當(dāng)作數(shù)據(jù)倉庫使用。TPC-H 是數(shù)據(jù)分析領(lǐng)域的一個(gè)測試集，TiDB 2.0 在 OLAP 場景下的性能有了大幅提升，原來只能在數(shù)據(jù)倉庫里面跑的一些復(fù)雜的 Query，在 TiDB 2.0 里面跑，時(shí)間基本都能控制在 10 秒以內(nèi)。當(dāng)然，因?yàn)?OLAP 的范疇非常大，TiDB 的 SQL 也有搞不定的情況，為此 PingCAP 開源了 TiSpark，TiSpark 是一個(gè) Spark 插件，用戶可以直接用 Spark SQL 實(shí)時(shí)地在 TiKV 上做大數(shù)據(jù)分析。

用例4：作為其他系統(tǒng)的模塊

TiDB 是一個(gè)傳統(tǒng)的存儲跟計(jì)算分離的項(xiàng)目，其底層的 Key-Value 層，可以單獨(dú)作為一個(gè) HBase 的 Replacement 來用，它同時(shí)支持跨行事務(wù)。TiDB 對外提供兩個(gè) API 接口，一個(gè)是 ACID Transaction 的 API，用于支持跨行事務(wù)；另一個(gè)是 Raw API，它可以做單行的事務(wù)，換來的是整個(gè)性能的提升，但不提供跨行事務(wù)的 ACID 支持。用戶可以根據(jù)自身的需求在兩個(gè) API 之間自行選擇。例如有一些用戶直接在 TiKV 之上實(shí)現(xiàn)了 redis 協(xié)議，將 TiKV 替換一些大容量，對延遲要求不高的 Redis 場景。

看完上述內(nèi)容，你們掌握TiDB整體架構(gòu)及的作用是什么的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！