近日，國內(nèi)云計算服務(wù)商UCloud與國內(nèi)開源分布式NewSOL數(shù)據(jù)庫TiDB團(tuán)隊PingCAP正式達(dá)成合作，雙方聯(lián)手在UCloud全球數(shù)據(jù)中心推出了新一代TiDB的云端版本-Cloud TiDB。

作為一款定位于Cloud-native的數(shù)據(jù)庫，目前TiDB在云整合上已取得了階段性進(jìn)展。Cloud TiDB產(chǎn)品在UCloud平臺正式開啟公測，TiDB彈性伸縮特性在Cloud提供的基礎(chǔ)設(shè)施支持下得到了淋漓盡致地體現(xiàn)。在感受云數(shù)據(jù)庫魅力的同時，讓我們來探索—下TiDB與Cloud背后的技術(shù)秘密。

一、TiDB與傳統(tǒng)單機關(guān)系型數(shù)據(jù)庫的區(qū)別

首先，從TiDB的架構(gòu)說起。TiDB作為一款開源的分布式數(shù)據(jù)庫產(chǎn)品，具有多副本，能夠根據(jù)業(yè)務(wù)需求非常方便地進(jìn)行彈性伸縮，并且擴縮容期間對上層業(yè)務(wù)無影響。

TiDB的主體架構(gòu)包含三個模塊，對應(yīng)Githuh上PingCAP組織下的三個開源項目（TiDB/TiKV/PD）：

1） TiDB主要是負(fù)責(zé)SQL的解析器和優(yōu)化器，它相當(dāng)于計算執(zhí)行層，同時也負(fù)責(zé)客戶端接人和交互；

2） TiKV是一套分布式的Kev-Value存儲引擎，它承擔(dān)整個數(shù)據(jù)庫的存儲層，數(shù)據(jù)水平擴展和多副本高可用特性都在這一層實現(xiàn)；

3） PD相當(dāng)于分布式數(shù)據(jù)庫的大腦，一方面負(fù)責(zé)收集和維護(hù)數(shù)據(jù)在各個TiKV節(jié)點的分布情況，另一方面PD承擔(dān)調(diào)度器的角色，根據(jù)數(shù)據(jù)分布狀況以及各個存儲節(jié)點的負(fù)載來采取合適的調(diào)度策略，維持整個系統(tǒng)的平衡與穩(wěn)定。

上述三個模塊中的每個角色都是一個多節(jié)點組成的集群，所以最終TiDB的架構(gòu)如圖1所示。

由此可見，分布式系統(tǒng)本身的復(fù)雜性不僅導(dǎo)致人工部署和運維成本較高，而且容易出錯。傳統(tǒng)的自動化部署運維T具（如Puppet/Chef/SaltStack/Ansihle等），由于缺乏狀態(tài)管理，在節(jié)點出現(xiàn)問題時不能及時自動完成故障轉(zhuǎn)移，需要人工干預(yù)，有些則需要寫大量DSL甚至與Shell腳本一起混合使用，可移植性較差，維護(hù)成本比較高。

在云時代，容器成為應(yīng)用分發(fā)部署的基本單位，谷歌基于內(nèi)部使用數(shù)十年的容器編排系統(tǒng)Borg經(jīng)驗，推出的開源容器編排系統(tǒng)Kuhernetes就成為當(dāng)前容器編排技術(shù)的主流。

二、TiDB與Kubernetes的深度整合

作為Cloud Native Datahase，TiDB選擇擁抱容器技術(shù)，并與Kuhernetes進(jìn)行深度整合，使其可以非常方便地基于Kuhernetes完成數(shù)據(jù)庫白動化管理。甚至可以說Kuhernetes項目是為Cloud而生，利用云平臺IaaS層提供的API可以很方便地與云進(jìn)行整合。這樣只要讓TiDB與Kuhernetes結(jié)合得更好，進(jìn)而就能實現(xiàn)其與各個云平臺的整合，使TiDB在云上的快速部署和高效運維成為現(xiàn)實。

1.Kubernetes簡介

Kuhernetes最早是作為一個純粹的容器編排系統(tǒng)而誕生，用戶部署好Kuhernetes集群之后，直接使用其內(nèi)置的各種功能部署應(yīng)用服務(wù)。由于這個PaaS平臺使用起來非常便利，吸引了很多用戶，不同用戶也提出了各種不同需求，有些特性需求Kuhernetes可直接在其核心代碼里實現(xiàn)，但有些特性并不適合合并到主程序中。

為了滿足這類需求，Kubernetes開放出一些API供用戶自己擴展，實現(xiàn)自身需求。當(dāng)前Kuhernetes已經(jīng)升級到1.8版本，內(nèi)部API變得越來越開放，使其更像是一個跑在云上的操作系統(tǒng)。用戶可以把它當(dāng)作一套云的SDK或Framework來使用，而且可以很方便地開發(fā)組件來擴展?jié)M足自身業(yè)務(wù)需求，對有狀態(tài)服務(wù)的支持就是一個代表性實例。

在最早期，Kuhernetes項目只支持無狀態(tài)服務(wù)（ Stateless Service）來管理，無狀態(tài)服務(wù)通過ReplicationController定義多個副本，由Kuhernetes調(diào)度器來決定在不同節(jié)點上啟動多個Pod，實現(xiàn)負(fù)載均衡和故障轉(zhuǎn)移。對于無狀態(tài)服務(wù)，多個副本對應(yīng)的Pod是等價的，所以當(dāng)節(jié)點出現(xiàn)故障時，在新節(jié)點上啟動一個Pod與失效的Pod是等價的，不會涉及狀態(tài)遷移問題，因而管理非常簡單。

2.有狀態(tài)服務(wù)Stateful Service

不過，對于有狀態(tài)服務(wù)（Stateful Service），由于需要將數(shù)據(jù)持久化到磁盤，使得不同Pod之間不能再認(rèn)為成等價，也就不能再像無狀態(tài)服務(wù)那樣隨意地進(jìn)行調(diào)度遷移。Kuhernetes l.3版本提出PetSet的概念，用來管理有狀態(tài)服務(wù)并在1.5版本中將其更名為StatefulSet。

StatefuISet明確定義了一組Pod中的每個身份，啟動和升級都按特定順序來操作。另外，使用持久化卷存儲（PersistentVolume）來作為存儲數(shù)據(jù)的載體，當(dāng)節(jié)點失效Pod需要遷移時，對應(yīng)的PV通過umount/mount方式跟著一起遷移到新節(jié)點，或者直接使用分布式文件系統(tǒng)作PV底層存儲，使Pod在遷移后仍然能訪問到之前的數(shù)據(jù)。

同時，Pod在發(fā)生遷移時，其網(wǎng)絡(luò)身份（例如IP地址）是會發(fā)生變化的，很多分布式系統(tǒng)不能接受這種情況，所以Statef'uISet在遷移Pod時可以通過綁定域名的方式來保證Pod在集群中網(wǎng)絡(luò)身份不發(fā)生變化。

然而，現(xiàn)實中一些分布式系統(tǒng)更為復(fù)雜，StatefulSet也顯得捉襟見肘。舉例來說，某些分布式系統(tǒng)的節(jié)點在加入集群或下線時，還需要做些額外的注冊和清理操作，或者在滾動升級時，要考量版本兼容性等問題。

基于上述原因，CoreOS公司提出了Operator概念，并實現(xiàn)了etcd-operator和prometheus-operator來管理Etcd和Prometheus這樣復(fù)雜的分布式系統(tǒng)。用戶可以開發(fā)自己的Operator，在Kuhernetes之上實現(xiàn)白定義的Controller，將有狀態(tài)服務(wù)領(lǐng)域中特定的運維知識編碼進(jìn)去，從而實現(xiàn)對特定分布式系統(tǒng)的管理。同時，Operator本身也是跑在Kuhernetes中的一個Pod（deployment），對Kubernetes系統(tǒng)并無危害。

3.TiDB多組件支持

針對TiDB這種復(fù)雜的分布式服務(wù)，我們開發(fā)了tidh-operator等一系列組件，來管理TiDB集群實例在Kubernetes平臺上的創(chuàng)建、銷毀、擴容、縮容、滾動升級和故障轉(zhuǎn)移等運維操作。同時，在上層封裝了一個tidh-cloud-manager組件，提供RESTful接口，實現(xiàn)了與云平臺的控制臺打通功能。這就完成了一個DBaaS（數(shù)據(jù)庫即服務(wù)）架構(gòu)的基本形態(tài)。

由于TiDB對磁盤1/0有比較高的要求，通過PV掛載網(wǎng)絡(luò)盤，會有明顯的性能損耗。另外，TiKV本身維護(hù)了數(shù)據(jù)多副本，這點和分布式文件系統(tǒng)的多副本是有重復(fù)的，所以要給Pod上掛載本地磁盤，并且在Kuhernetes上把Local PV管理起來，作為一種特定資源來維護(hù)。

Kuhernetes方長期以來一直沒有提供Local PV支持，本地存儲只支持hostPath和emptyDir兩種方式。其中，hostPath的生命周期是脫離Kuhernetes管理的，使用hostPath的Pod銷毀后，里面的數(shù)據(jù)是不會被自動清理，下次再掛載Pod就會造成多余的數(shù)據(jù)。而emptyDir更像是一個臨時磁盤，在Pod重建時會被清理重置，不能成為持久化PV來使用。

為此，我們開發(fā)了一個tidh-volume-manager組件，用于管理Kuhernetes集群中每臺物理主機上的本地磁盤，并且將其變成一種特殊的PV資源。結(jié)合Operator在部署TiDB節(jié)點時會參考Local PV資源的情況，來選擇特定節(jié)點進(jìn)行部署，分配一個空的LocalPV和Pod綁定。而當(dāng)Pod銷毀時，會根據(jù)具體情況決定是否結(jié)束Local PV的生命周期，釋放掉的Local PV在經(jīng)歷一個GC周期后，被tidh-volume-managerl回收，清理其盤上數(shù)據(jù)等待再次被分配使用。

將這些組件整合起來，就形成了上圖描述的CloudTiDB總體架構(gòu)（圖2）。在Kubenete s管理的集群上，通過tidb-operator等組件針對性的調(diào)配和使用集群資源，從而實現(xiàn)TiDB集群實例的生命周期管理。通過這種方式實TiDB分布式數(shù)據(jù)庫和云平臺的整合。

三、Cloud TiDB的關(guān)鍵特性和實現(xiàn)細(xì)節(jié)

1.自動化運維

數(shù)據(jù)庫產(chǎn)品上云的一個先決條件是能實現(xiàn)自動化的運維管理，因為在云端靠人T運維幾乎是不現(xiàn)實的。第一步，用Kubernetes將云平臺的主機資源管理起來，組成一個大資源池；第二步，再通過tidh-opeartor及tidb-cloud-manager等組件，來自動化完成TiDB實例的一鍵部署、擴容縮容、在線滾動升級、自動故障轉(zhuǎn)移等運維操作。

集群創(chuàng)建。TiDB包含tidh、tikv和PD三大核心組件，每個服務(wù)又都是一個多節(jié)點的分布式結(jié)構(gòu)，服務(wù)和服務(wù)之間的啟動順序也存在依賴關(guān)系。此外，PD節(jié)點的創(chuàng)建和加入集群方式與etcd類似，是需要先創(chuàng)建一個單節(jié)點的initial集群，后加入的節(jié)點需要用特殊的加入方式，啟動命令上也有差別。

有一些操作完成后還需要調(diào)用API進(jìn)行通知。Kuhernetes自身提供的StatefuISet很難應(yīng)付這種復(fù)雜部署，所以需要tidb-operator中實現(xiàn)特定Controller來完成這一系列操作。同時，結(jié)合Kuhernete se強大的調(diào)度功能，合理規(guī)劃和分配整個集群資源，盡量讓新部署的TiDB實例節(jié)點在集群中均勻分布，最終通過LB給對應(yīng)的租戶使用。

在線升級也類似。由于tikv/PD的Pod掛載是本地存儲，并不能像云平臺提供的塊存儲或網(wǎng)絡(luò)文件系統(tǒng)那樣可以隨意掛載。如果tikv/PD遷移到其他節(jié)點，相當(dāng)于數(shù)據(jù)目錄也被清空，所以必須保證tikv/PD的Pod在升級完成后仍然能夠調(diào)度在原地，這也是要由tidh-operator的Controller來保證。

TiDB的數(shù)據(jù)副本之間由Raft算法來保證一致性，當(dāng)集群中某一個節(jié)點暫時斷開，可以不影響整個服務(wù)，所以在集群升級過程中，必須嚴(yán)格按照服務(wù)的依賴關(guān)系，再依次對Pod進(jìn)行升級。

當(dāng)節(jié)點出現(xiàn)故障時，同樣是由于掛載本地數(shù)據(jù)盤的原因，也不能像StatefulSet那樣直接把Pod遷移走。當(dāng)TiDB Operator檢測到節(jié)點失效，首先要等一段時間，以確認(rèn)節(jié)點不會再恢復(fù)了，再開始遷移恢復(fù)的操作。

首先，調(diào)度選擇一個新節(jié)點啟動一個Pod，然后通知TiDB將失效節(jié)點放棄掉，并將新啟的Pod加入集群。后面會由TiDB的PD模塊來完成數(shù)據(jù)副本數(shù)恢復(fù)以及數(shù)據(jù)往新節(jié)點上遷移，從而重新維持集群內(nèi)數(shù)據(jù)平衡。

以上僅列舉了TiDB幾種典型的運維操作流程，實際生產(chǎn)上運維還有很多情況需要考慮，這些都以程序的方式在tidb-operator里實現(xiàn)。借助Kuhernetes和tidh-operator來代替人T，高效地完成TiDB數(shù)據(jù)庫在云平臺上的復(fù)雜運維管理。

2.動態(tài)擴縮容

彈性水平伸縮是TiDB數(shù)據(jù)庫最主要的特性之一。在大數(shù)據(jù)時代，人們對數(shù)據(jù)存儲的需求快速膨脹，有時用戶很難預(yù)估自己業(yè)務(wù)規(guī)模的增長速度，如果采用傳統(tǒng)存儲方案，可能很快發(fā)現(xiàn)存儲容量達(dá)到了瓶頸，然后不得不停機來做遷移和擴容。如果使用Cloud TiDB的方案，這個過程就非常簡單，只需在Cloud控制臺上修改一下TiDB的節(jié)點數(shù)量，就能快速完成擴容操作，期間還不會影響業(yè)務(wù)的正常服務(wù)。

那么，在Cloud后臺，同樣借助Kuhernetes和tidh-operator的能力來完成TiDB增減節(jié)點操作。Kubernetes本身的運作是基于一種Reconcile機制，簡單來說就是當(dāng)用戶提交一個新請求，比如期望集群里跑5個TiKV節(jié)點，而目前正在跑的只有3個，那么Reconcile機制就會發(fā)現(xiàn)這個差異，先由Kuhernetes調(diào)度器根據(jù)集群整體資源情況，并結(jié)合TiDB節(jié)點分配的親和性原則和資源隔離原則來分配節(jié)點。另外，很重要一點是選擇有空閑Local PV的機器來創(chuàng)建Pod并進(jìn)行掛載，最終通過tidh-operator將2個節(jié)點加入TiDB集群。

縮容的過程也類似。假如數(shù)據(jù)庫存儲的總數(shù)據(jù)量變少，需要減少節(jié)點以節(jié)省成本，首先用戶通過云控制臺向后端提交請求，在一個Reconciling周期內(nèi)發(fā)現(xiàn)差異，tidb-operator的Controller開始通知TiDB集群執(zhí)行節(jié)點下線的操作。安全下線可能是比較長的過程，因為需要由PD模塊將下線節(jié)點的數(shù)據(jù)搬移到其他節(jié)點，期間集群都可以正常服務(wù)。當(dāng)下線完成，這些TiKV變成tomhstone狀態(tài)，而tidb-operator也會通知Kuhernetes銷毀這些Pod，并且由tidh-volume -manager來回收Local PV。

3.資源隔離

資源隔離也是云上用戶關(guān)心的一個問題。尤其是數(shù)據(jù)庫這類應(yīng)用，不同租戶的數(shù)據(jù)庫實例，甚至一個租戶的多套數(shù)據(jù)庫實例，都在Kubernetes管理集群上，相互間會不會有資源爭搶問題？某個實例執(zhí)行高負(fù)載計算任務(wù)時，CPU、內(nèi)存、1/0等會不會對同臺機器上部署的其他實例產(chǎn)生影響？

其實，容器本身就是資源隔離的一個解決方案，容器底層是Llnux內(nèi)核提供的cgroups技術(shù)，用于限制容器內(nèi)的CPU、內(nèi)存以及IO等資源的使用，并通過namespace技術(shù)實現(xiàn)隔離。而Kuhernetes作為容器編排系統(tǒng)，能根據(jù)集群中各個節(jié)點的資源狀況，選擇最優(yōu)策略來調(diào)度容器。同時，tidh-operator會根據(jù)TiDB自身特性和約束來綜合決策TiDB節(jié)點的調(diào)度分配。

例如，當(dāng)一個Kuhernetes集群橫跨多個可用區(qū)，用戶申請創(chuàng)建一個TiDB集群，那么首先根據(jù)高可用性原則，將存儲節(jié)點盡量分配到不同可用區(qū)，并給TiKV打上標(biāo)簽。那么同一個可用區(qū)內(nèi)也盡量不把多個TiKV部署到相同的物理節(jié)點上，以保證集群資源最大化利用。

此外，每個Local PV也是一塊獨立磁盤，每個TiKV的Pod分別掛載不同的盤，所以1/0上也是完全隔離。

Kuhernetes還可以配置Pod之間的親和性（affinity）和反親和性（anti-affinit）T）。例如，在TiKV和TiDB之間，可以通過親和性使其調(diào)度到網(wǎng)絡(luò)延時較小的節(jié)點上，提高網(wǎng)絡(luò)傳輸效率。TiKV之間借助反親和性，使其分散部署到不同主機、機架和可用區(qū)上，降低因硬件或機房故障而導(dǎo)致的數(shù)據(jù)丟失風(fēng)險。

上面解釋了容器層的隔離，也可以看做是物理層的隔離。再來看數(shù)據(jù)層的隔離，TiDB的調(diào)度體系也有所考慮，比如一個大的TiDB集群，節(jié)點分布在很多臺主機，跨越多個機架、可用區(qū)，那么用戶可以定義Namespace，這是一個邏輯概念，不同業(yè)務(wù)的數(shù)據(jù)庫和表放置在不同的Namespace，再通過配置Name space、TiKV節(jié)點以及區(qū)域的對應(yīng)關(guān)系，由PD模塊來進(jìn)行調(diào)度，從而實現(xiàn)不同業(yè)務(wù)數(shù)據(jù)在物理上的隔離。

4.高可用性

TiDB作為一個分布式數(shù)據(jù)庫，本身就具有高可用性，每個核心組件都可以獨立地擴縮容。任意一個模塊在部署多份副本時，如果有一個掛掉，整體仍然可以正常對外提供服務(wù)，這是由Raft協(xié)議保證的。但是，如果對數(shù)據(jù)庫節(jié)點的調(diào)度不加任何限制，包含一份數(shù)據(jù)的多個副本的節(jié)點可能會被調(diào)度到同一臺主機。這時如果主機發(fā)生故障，就會同時失去多個本，一個Raft分組內(nèi)失去多數(shù)派節(jié)點就會導(dǎo)致整個集群處于不可用狀態(tài)，因此tidh-operator在調(diào)度TiKV節(jié)點時需要避免出現(xiàn)這種情況。

另外，TiDB支持基于標(biāo)簽的數(shù)據(jù)調(diào)度，能給不同TiKV實例加上描述物理信息的標(biāo)簽。例如，地域（Region）、口]用區(qū)（AZ）、機架（Rack）、主機（Host），當(dāng)PD在對數(shù)據(jù)進(jìn)行調(diào)度時，就會參考這些信息更加智能地制定調(diào)度策略，盡最大可能保證數(shù)據(jù)的可用性。

例如，PD會基于標(biāo)簽信息盡量把相同數(shù)據(jù)的副本分散調(diào)度到不同的主機、機架、可用區(qū)、地域上，這樣在物理節(jié)點掛掉、機架掉電或機房出故障時，其他地方仍然有該數(shù)據(jù)足夠的副本數(shù)。借助tidb-operator中controller-manager組件，可以自動給TiKV實例加上物理拓?fù)湮恢脴?biāo)簽，充分發(fā)揮PD對數(shù)據(jù)的智能調(diào)度能力，實現(xiàn)數(shù)據(jù)層面的高可用性。

同時，還可以達(dá)到實例級別的高可用性，通過Kubernetes強大的調(diào)度規(guī)則和擴展的調(diào)度器，按優(yōu)先級會選擇讓TiKV部署到不同的主機、機架和可用區(qū)上，把因主機、機架、機房出問題造成的影響降到最低，使數(shù)據(jù)具有最大的高可用性。

另外，運行在Kubernetes之上，能實時監(jiān)測到TiDB各組件運行情況，當(dāng)出現(xiàn)問題時，也能第一時間讓tidh-operator對集群進(jìn)行自動修復(fù)（self-healing）。具體表現(xiàn)為tidh/tikv/PD實例出現(xiàn)故障時，執(zhí)行安全的下線操作，同時增加新實例來保證集群的規(guī)模和之前一致。

TiDB作為一款Cloud Native Datahase，通過tidh-operator方式充分發(fā)揮Kuhernetes平臺的強大能力，實現(xiàn)云上自動化管理，極大降低人力運維成本。用戶可以根據(jù)業(yè)務(wù)需要進(jìn)行動態(tài)擴容縮容，多租戶隔離特性讓不同租戶的實例可以共享計算和存儲資源，互不干擾，同時最大程度充分使用云上資源。Raft算法和tidh-operator自動修復(fù)能力以及兩層調(diào)度機制保證了Cloud TiDB的高可用性。