-     前言    -

經(jīng)過小編這幾天的學(xué)習(xí)理解，對TiDB數(shù)據(jù)庫有了一定理解，所以現(xiàn)在回來總結(jié)。

-     整體框架    -

TiDB主要分為3個(gè)核心組件：TiDB Server ,PD Server 和TiKV Server，還有用于解決用戶復(fù)雜OLAP需求的TiSpark組件。部署一個(gè)單機(jī)版的TiDB，這三個(gè)組件都需要啟動(dòng)。如果用生產(chǎn)環(huán)境，需要使用Ansible部署TiDB集群。

一個(gè)完整的TiDB集群框架如下圖：

TiKV Server

TiKV Server 負(fù)責(zé)存儲(chǔ)數(shù)據(jù)，對于數(shù)據(jù)存儲(chǔ)需要保證實(shí)現(xiàn)以下功能：

• 支持跨數(shù)據(jù)中心的容災(zāi)；

• 寫入速度足夠快；

• 讀取速度方便；

• 支持?jǐn)?shù)據(jù)修改與并發(fā)修改數(shù)據(jù)；

• 多條記錄修改后保證原子性。

TiKV采用Key-Value模型存儲(chǔ)數(shù)據(jù)，并且提供有序遍歷方法。TiKV是一個(gè)巨大的Map，TiKV存儲(chǔ)的是key-value pair，key-value pair按照key的二進(jìn)制順序有序，查找到某個(gè)key的位置，可以不斷地調(diào)用Next方法以遞增的順序獲取比這個(gè)key大的key-value。

TiKV的存儲(chǔ)模型與SQL中Table無關(guān)，TiKV就是一個(gè)高性能高可靠性的巨大的（分布式）的map。

TiKV通過RocksDB將數(shù)據(jù)持久化到磁盤上，而不是直接向磁盤上寫數(shù)據(jù)，也就是說具體的數(shù)據(jù)落地是用RocksDB負(fù)責(zé)。RokcsDB 是一個(gè)高性能的單機(jī)引擎，有FaceBook的團(tuán)隊(duì)做持續(xù)優(yōu)化。

如果要做到數(shù)據(jù)不丟失，支持跨數(shù)據(jù)中心的容災(zāi)，就需要將數(shù)據(jù)負(fù)責(zé)到多臺(tái)機(jī)器上，但是這個(gè)時(shí)候就涉及到數(shù)據(jù)一致性的問題了。TiDB采用Raft協(xié)議來保證數(shù)據(jù)一致性，Raft是一個(gè)一致性算法，PingCAP公司對Raft協(xié)議的實(shí)現(xiàn)做了大量的優(yōu)化來保證這一協(xié)議切實(shí)可行。

Raft是一個(gè)一致性協(xié)議，提供了以下幾個(gè)重要的功能：

• Leader選舉；

• 成員變更；

• 日志復(fù)制；

TiKV利用Raft來做數(shù)據(jù)復(fù)制，每個(gè)數(shù)據(jù)變更都會(huì)落地為一條Raft日志，通過Raft的日志復(fù)制功能，將數(shù)據(jù)安全可靠地同步到Group的多數(shù)節(jié)點(diǎn)中，以防單機(jī)失效。數(shù)據(jù)的寫入是通過Raft這一層的接口寫入，而不是直接寫RocksDB。通過Raft實(shí)現(xiàn)，我們擁有一個(gè)分布式的巨大Map，也就不用擔(dān)心某臺(tái)機(jī)器掛掉。

下圖為數(shù)據(jù)的存儲(chǔ)流程。

經(jīng)過前面的理解，可以將TiKV看作是一個(gè)kv系統(tǒng)，TiKV是以Region為單位做存儲(chǔ)與復(fù)制，將key-value分段存儲(chǔ)在節(jié)點(diǎn)上，每一段是一系列連續(xù)的key,也就是分Range，每一段就是一個(gè)Region。每個(gè)Region中存儲(chǔ)的數(shù)據(jù)不超過一定的大小（默認(rèn)是64mb),每一個(gè)Region都可以用StartKey到EndKey這樣一個(gè)左閉右開區(qū)間來描述。

系統(tǒng)會(huì)通過一個(gè)組件來負(fù)責(zé)將Region盡可能均勻的散步在集群中所有的節(jié)點(diǎn)上，這樣一方面實(shí)現(xiàn)了存儲(chǔ)容量的水平擴(kuò)展，另一方面也實(shí)現(xiàn)了負(fù)載均衡。為了保證上層客戶端能夠訪問所需要的數(shù)據(jù)，系統(tǒng)會(huì)有一個(gè)組件記錄Region在節(jié)點(diǎn)上面的分布情況，可以通過任意一個(gè)key就能查詢到這個(gè)key在哪個(gè)Region中，以及這個(gè)Region在哪個(gè)節(jié)點(diǎn)上。

TiKV以Region為單位做數(shù)據(jù)的復(fù)制，也就是一個(gè)Region的數(shù)據(jù)會(huì)保存多個(gè)副本，每個(gè)副本叫做一個(gè)Replica.Replica之間是通過Raft來保證數(shù)據(jù)的一致性，一個(gè)Region的多個(gè)Replica會(huì)保存在不同的節(jié)點(diǎn)上，構(gòu)成一個(gè)Raft Group。其中Replica會(huì)作為這個(gè)Group的leader，其他的Replica作為Follower。所有的讀和寫都是通過Leader進(jìn)行，在由leader復(fù)制給Follower。

如圖：

小結(jié)：TiKV是一個(gè)分布式key-value存儲(chǔ)系統(tǒng)，一個(gè)巨大的分布式Map系統(tǒng)，一個(gè)全局有序的分布式key-value引擎。

-     PD Server    -

Placement Driver（簡稱PD）是TiDB里面全局中心總控節(jié)點(diǎn)，是整個(gè)集群的管理模塊，負(fù)責(zé)整個(gè)集群的調(diào)度。

TiDB作為一個(gè)分布式高可用存儲(chǔ)系統(tǒng)，系統(tǒng)需要具備多副本容錯(cuò)，動(dòng)態(tài)擴(kuò)容、縮容，容忍節(jié)點(diǎn)掉線以及自動(dòng)錯(cuò)誤恢復(fù)的功能，且整個(gè)系統(tǒng)負(fù)載均與，方便管理。需要滿足這些功能，TiDB就需要收集足夠的信息，比如每個(gè)節(jié)點(diǎn)的狀態(tài)、每個(gè)Raft Group的信息，業(yè)務(wù)訪問操作的統(tǒng)計(jì)等。PD根據(jù)這些信息以及調(diào)度的策略，置頂出了盡量滿足這些需求的調(diào)度計(jì)劃，并提供基本操作來完成這個(gè)計(jì)劃。

-     信息收集    -

調(diào)度依賴于這個(gè)集群信息的收集，PD需要知道每個(gè)TiKV節(jié)點(diǎn)的狀態(tài)以及每個(gè)Region的狀態(tài)。TiKV集群會(huì)向PD匯報(bào)兩類信息。

一、每個(gè)TiKV節(jié)點(diǎn)會(huì)定期向PD匯報(bào)節(jié)點(diǎn)的整體信息

TiKV節(jié)點(diǎn)（store)與PD之間存在心跳包，一方面PD通過心跳包檢測每個(gè)Store是否存活，以及是否有新加入的Store；另一方面也會(huì)攜帶這個(gè)Store的狀態(tài)信息，主要包括：

• 總磁盤容量

• 可用磁盤容量

• 承載的Region數(shù)量

• 數(shù)據(jù)寫入速度

• 發(fā)送/接受的Snapshot數(shù)量（Replica之間可能會(huì)通過Snapshot同步數(shù)據(jù)）

• 是否過載

• 標(biāo)簽信息（標(biāo)簽是具備層級(jí)關(guān)系的一系列Tag）

二、每個(gè)Raft Group的Leader會(huì)定期向PD匯報(bào)信息

每個(gè)Raft Group的Leader和PD之間存在心跳包，用于匯報(bào)這個(gè)Region的狀態(tài)，主要包括下面幾點(diǎn)信息：

• leader的位置

• Followers的位置

• 掉線Replica的個(gè)數(shù)

• 數(shù)據(jù)寫入/讀取的速度

PD不斷的通過這兩類心跳消息收集整個(gè)集群的信息，再以這些信息座位決策的依據(jù)。除此之外，PD還可以通過管理接口接受額外的信息，用來做更準(zhǔn)確的決策。比如當(dāng)某個(gè)Store的心跳包中斷的時(shí)候，PD并不能判斷這個(gè)節(jié)點(diǎn)是臨時(shí)失效還是永久失效，只能經(jīng)過一段時(shí)間的等待（默認(rèn)是30分鐘），如果一直沒有心跳包，就認(rèn)為是Store已經(jīng)下線，再?zèng)Q定需要將這個(gè)Store上面的Region都調(diào)度走。

但是有的時(shí)候，是運(yùn)維人員主動(dòng)將某臺(tái)機(jī)器下線，這個(gè)時(shí)候，可以通過PD的管理接口通知PD改Store不可用，PD就可以馬上判斷判斷需要將這個(gè)Store上面的Region都調(diào)度走。

-     調(diào)度的策略    -

PD收集了這些信息后，還需要一些策略來制定具體的調(diào)度計(jì)劃。

一、一個(gè)Region的Replica數(shù)量正確

當(dāng)PD通過某個(gè)Region Leader的心跳包發(fā)現(xiàn)這個(gè)Region的Replica數(shù)量不滿足要求時(shí)，需要通過Add/Remove Replica 操作調(diào)整Replica數(shù)量。

二、一個(gè)Raft Group中的多個(gè)Replica不在同一個(gè)位置

三、副本在Store之間的分布均勻分配

每個(gè)副本中存儲(chǔ)的數(shù)據(jù)容量上限是固定的，所以維持每個(gè)節(jié)點(diǎn)上面副本數(shù)量的均衡，會(huì)使得總體負(fù)載更均衡。

四、Leader數(shù)量在Store之間均勻分配

Raft協(xié)議要讀取和寫入都通過Leader進(jìn)行，所以計(jì)算的負(fù)載主要在Leader上面，PD會(huì)盡可能講Leader在節(jié)點(diǎn)之間分散。

五、訪問熱點(diǎn)數(shù)量在Store之間均勻分配

每個(gè)Store以及Region Leader在上報(bào)信息是攜帶了當(dāng)前訪問負(fù)載的信息，比如Key的讀取/寫入速度。PD會(huì)檢測出訪問熱點(diǎn)，且將其在節(jié)點(diǎn)之間分散。

六、各個(gè)Store的存儲(chǔ)空間占用大致相等

每個(gè)Store啟動(dòng)的時(shí)候都會(huì)指定一個(gè)Capacity參數(shù)，表明這個(gè)Store的存儲(chǔ)空間上限，PD在做調(diào)度的時(shí)候，會(huì)考慮節(jié)點(diǎn)的存儲(chǔ)空間剩余量。

七、控制調(diào)度速度，避免影響在線服務(wù)

調(diào)度操作需要耗費(fèi)CPU、內(nèi)存、磁盤IO以及網(wǎng)絡(luò)帶寬，我們需要避免對線上服務(wù)造成太大影響。PD會(huì)對當(dāng)前正在進(jìn)行的操作數(shù)量進(jìn)行控制，默認(rèn)的速度控制是比較保守的，如果希望加快調(diào)度（比如已經(jīng)停服務(wù)升級(jí)，增加新節(jié)點(diǎn)，希望盡快調(diào)度），那么可以通過pd-ctl手動(dòng)加快調(diào)度速度。

八、支持手動(dòng)下線節(jié)點(diǎn)

當(dāng)通過pd-ctl手動(dòng)下線節(jié)點(diǎn)后，PD會(huì)在一定速率控制下，將節(jié)點(diǎn)上的數(shù)據(jù)調(diào)度走。當(dāng)調(diào)度完成后，就會(huì)將這個(gè)節(jié)點(diǎn)置為下線狀態(tài)。

小結(jié)：作為中心中控節(jié)點(diǎn)，PD通過集成etcd，自動(dòng)得支持auto failover，無須擔(dān)心單點(diǎn)故障問題。同時(shí)PD也通過etcd的raft，保證了數(shù)據(jù)強(qiáng)一致性，不用擔(dān)心數(shù)據(jù)丟失問題。除此之外，PD還負(fù)責(zé)全局ID的生成，以及全局時(shí)間戳TSO的生成，保存整個(gè)集群TiKV的元信息，負(fù)責(zé)給client提供路由功能。

-     TiDB Server    -

TiDB Server負(fù)責(zé)接收應(yīng)用成發(fā)送過來的SQL請求，處理SQL相關(guān)的邏輯，并通過PD找到存儲(chǔ)所需數(shù)據(jù)的TiKV地址，與TiKV交互獲取數(shù)據(jù)，最終返回結(jié)果。TiDB Server是無狀態(tài)的，其本身并不存儲(chǔ)數(shù)據(jù)，只負(fù)責(zé)計(jì)算，可以無限水平擴(kuò)展，可以通過負(fù)載均衡組件（如LVS、HAProxy或F5）對外提供統(tǒng)一得結(jié)束地址。

TiDB本身并不存儲(chǔ)數(shù)據(jù)，節(jié)點(diǎn)之間完全對等，TiDB Server這一層最重要的工作是處理用戶請求，執(zhí)行SQL運(yùn)算邏輯。

因?yàn)門iKV是一個(gè)key-value的存儲(chǔ)引擎，需要做到SQL到kv的映射，這里可以去具體了解它的映射方案。

用戶的SQL請求會(huì)直接或者通過Load Balancer 發(fā)送到TiDB-Server，TiDB會(huì)解析MySQLProtocol Packet，獲取請求內(nèi)容，然后做語法分析、查詢計(jì)劃指定和優(yōu)化、執(zhí)行查詢計(jì)劃獲取和處理數(shù)據(jù)。數(shù)據(jù)全部存儲(chǔ)在TiKV集群中，這個(gè)過程中TiDB-server會(huì)和TiKV-Server交互，獲取數(shù)據(jù)，最后TiDB-Server需要將查詢結(jié)果返回給用戶。

-     TiSpark    -

TiSpark就是Spark SQL on TiKV，是解決用戶復(fù)雜OLAP需求的主要組件,將Spark SQL 直接運(yùn)行在TiDB存儲(chǔ)層上，同時(shí)融合TiKV 分布集群的優(yōu)勢，和 TiDB 一起為用戶一站式解決 HTAP （Hybrid Transactional/Analytical Processing）需求。TiSPark依賴于TiKV集群和PD的存在。如果需要用到TiSPark，也需要搭建一個(gè)Spark集群。由于目前項(xiàng)目中沒有用到TiSPark，在這里就不深入研究。

-     總結(jié)    -

TiKV Server負(fù)責(zé)存儲(chǔ)，PD Server 負(fù)責(zé)調(diào)度，TiDB Server負(fù)責(zé)計(jì)算，三者中間有個(gè)至關(guān)重要的協(xié)議Raft，這個(gè)協(xié)議保證了TiDB這個(gè)分布式數(shù)據(jù)庫的數(shù)據(jù)安全一致。

參考文檔：TiDB官方文檔

作者：引渡

來源：

blog.csdn.net/yye894817571/article/details/89394355