在《云計算架構(gòu)下 Cloud TiDB的技術(shù)奧秘（上）》中，分析了TiDB與傳統(tǒng)單機關(guān)系型數(shù)據(jù)庫的區(qū)別，以及與幾種技術(shù)整合之后所形成的總體架構(gòu)。接下來，我們將深度探討Cloud TiDB的關(guān)鍵特性和實現(xiàn)細(xì)節(jié)。
自動化運維
數(shù)據(jù)庫產(chǎn)品上云的一個先決條件是能實現(xiàn)自動化的運維管理，因為在云上靠手工運維幾乎是不現(xiàn)實的。
第一步，用Kubernetes將云平臺的主機資源管理起來，組成一個大資源池；
第二步，再通過tidb-opeartor及tidb-cloud-manager等組件，來自動化完成TiDB實例的一鍵部署、擴容縮容、在線滾動升級、自動故障轉(zhuǎn)移等運維操作。
◆ 來看集群創(chuàng)建。在上篇文章里提到過TiDB包含tidb、tikv和pd三大核心組件，每個服務(wù)又都是一個多節(jié)點的分布式結(jié)構(gòu)，服務(wù)和服務(wù)之間的啟動順序也存在依賴關(guān)系。此外，pd節(jié)點的創(chuàng)建和加入集群方式與etcd類似，是需要先創(chuàng)建一個單節(jié)點的initial集群，后加入的節(jié)點需要用特殊的join方式，啟動命令上也有差別。
有一些操作完成后還需要調(diào)用API進行通知。Kubernetes自身提供的StatefulSet很難應(yīng)付這種復(fù)雜部署，所以需要tidb-operator中實現(xiàn)特定Controller來完成這一系列操作。同時，結(jié)合Kubernetese強大的調(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)度在原地，這也是要由tidb-operator的Controller來保證。
TiDB的數(shù)據(jù)副本之間由Raft算法來保證一致性，當(dāng)集群中某一個節(jié)點暫時斷開，可以不影響整個服務(wù)，所以在集群升級過程中，必須嚴(yán)格按照服務(wù)的依賴關(guān)系，再依次對Pod進行升級。
◆ 當(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)上運維還有很多case需要考慮，這些都以程序的方式在tidb-operator里實現(xiàn)。借助Kubernetes和tidb-operator來代替人工，高效地完成TiDB數(shù)據(jù)庫在云平臺上的復(fù)雜運維管理。
（圖：Cloud
TiDB 總體架構(gòu)圖）
動態(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后臺，同樣借助Kubernetes和tidb-operator的能力來完成TiDB增減節(jié)點操作。Kubernetes本身的運作是基于一種Reconcile機制，簡單來說就是當(dāng)用戶提交一個新請求，比如期望集群里跑5個TiKV節(jié)點，而目前正在跑的只有3個，那么 Reconcile機制就會發(fā)現(xiàn)這個差異，先由Kubernetes調(diào)度器根據(jù)集群整體資源情況，并結(jié)合TiDB節(jié)點分配的親和性原則和資源隔離原則來分配節(jié)點。另外很重要一點是選擇有空閑Local PV的機器來創(chuàng)建Pod并進行掛載，最終通過tidb-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變成tombstone狀態(tài)，而tidb-operator也會通知Kubernetes銷毀這些Pod，并且由tidb-volume-manager來回收Local PV。
資源隔離
資源隔離也是云上用戶關(guān)心的一個問題。尤其是數(shù)據(jù)庫這類應(yīng)用，不同租戶的數(shù)據(jù)庫實例，甚至一個租戶的多套數(shù)據(jù)庫實例，都跑在一套大Kubernetes管理集群上，相互間會不會有資源爭搶問題？某個實例執(zhí)行高負(fù)載計算任務(wù)時，CPU、內(nèi)存、I/O等會不會對同臺機器上部署的其他實例產(chǎn)生影響？
其實，容器本身就是資源隔離的一個解決方案，容器底層是Linux內(nèi)核提供的cgroups 技術(shù)，用于限制容器內(nèi)的CPU、內(nèi)存以及IO等資源的使用，并通過namespace技術(shù)實現(xiàn)隔離。而Kubernetes作為容器編排系統(tǒng)，能根據(jù)集群中各個節(jié)點的資源狀況，選擇最優(yōu)策略來調(diào)度容器。同時，tidb-operator會根據(jù)TiDB自身特性和約束來綜合決策TiDB節(jié)點的調(diào)度分配。
舉例來說，當(dāng)一個Kubernetes集群橫跨多個可用區(qū)，用戶申請創(chuàng)建一個TiDB集群，那么首先根據(jù)高可用性原則，將存儲節(jié)點盡量分配到不同可用區(qū)，并給TiKV打上label。那么同一個可用區(qū)內(nèi)也盡量不把多個TiKV部署到相同的物理節(jié)點上，以保證集群資源最大化利用。
此外，每個Local PV也是一塊獨立磁盤，每個TiKV的Pod分別掛載不同的盤，所以I/O上也是完全隔離。
Kubernetes還可以配置Pod之間的親和性(affinity)和反親和性(anti-affinity)。例如：在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，再通過配置Namespace、TiKV節(jié)點以及區(qū)域的對應(yīng)關(guān)系，由PD模塊來進行調(diào)度，從而實現(xiàn)不同業(yè)務(wù)數(shù)據(jù)在物理上的隔離。
高可用性
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)，因此tidb-operator在調(diào)度TiKV節(jié)點時需要避免出現(xiàn)這種情況。
另外，TiDB支持基于label的數(shù)據(jù)調(diào)度，能給不同TiKV實例加上描述物理信息的label，例如地域(Region)、可用區(qū)(AZ)、機架(Rack)、主機(Host)，當(dāng)PD在對數(shù)據(jù)進行調(diào)度時，就會參考這些信息更加智能地制定調(diào)度策略，盡最大可能保證數(shù)據(jù)的可用性。
例如，PD會基于label信息盡量把相同數(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)問題時，也能第一時間讓tidb-operator對集群進行自動修復(fù) (self-healing)。具體表現(xiàn)為tidb/tikv/pd實例出現(xiàn)故障時，執(zhí)行安全的下線操作，同時增加新實例來保證集群的規(guī)模和之前一致。
小結(jié)
TiDB作為一款Cloud Native Database，通過tidb-operator方式充分發(fā)揮Kubernetes平臺的強大能力，實現(xiàn)云上自動化管理，極大降低人力運維成本。用戶可以根據(jù)業(yè)務(wù)需要進行動態(tài)擴容縮容，多租戶隔離特性讓不同租戶的實例可以共享計算和存儲資源，互不干擾，同時最大程度充分使用云上資源。Raft算法和tidb-operator自動修復(fù)能力以及兩層調(diào)度機制保證了Cloud TiDB的高可用性。
