在《云計算架構下 Cloud TiDB的技術奧秘「上」》中，分析了TiDB與傳統單機關系型數據庫的區別，以及與幾種技術整合之后所形成的總體架構。接下來，我們將深度探討Cloud TiDB的關鍵特性和實現細節。

自動化運維

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

• 來看集群創建。在上篇文章里提到過TiDB包含tidb、tikv和pd三大核心組件，每個服務又都是一個多節點的分布式結構，服務和服務之間的啟動順序也存在依賴關系。此外，pd節點的創建和加入集群方式與etcd類似，是需要先創建一個單節點的initial集群，后加入的節點需要用特殊的join方式，啟動命令上也有差別。

有一些操作完成后還需要調用API進行通知。Kubernetes自身提供的StatefulSet很難應付這種復雜部署，所以需要tidb-operator中實現特定Controller來完成這一系列操作。同時，結合Kubernetese強大的調度功能，合理規劃和分配整個集群資源，盡量讓新部署的TiDB實例節點在集群中均勻分布，最終通過LB暴露給對應的租戶使用。

• 在線升級也類似。由于tikv/pd的Pod掛載是本地存儲，并不能像云平臺提供的塊存儲或網絡文件系統那樣可以隨意掛載。如果tikv/pd遷移到其它節點，相當于數據目錄也被清空，所以必須保證tikv/pd的Pod在升級完成后仍然能夠調度在原地，這也是要由tidb-operator的Controller來保證。

TiDB的數據副本之間由Raft算法來保證一致性，當集群中某一個節點暫時斷開，可以不影響整個服務，所以在集群升級過程中，必須嚴格按照服務的依賴關系，再依次對Pod進行升級。

• 當節點出現故障時，同樣是由于掛載本地數據盤的原因，也不能像StatefulSet那樣直接把Pod遷移走。當TiDB Operator檢測到節點失效，首先要等一段時間，以確認節點不會再恢復了，再開始遷移恢復的操作。

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

以上僅列舉了TiDB幾種典型的運維操作流程，實際生產上運維還有很多case需要考慮，這些都以程序的方式在tidb-operator里實現。借助Kubernetes和tidb-operator來代替人工，高效地完成TiDB數據庫在云平臺上的復雜運維管理。

（圖：Cloud TiDB總體架構圖）

動態擴縮容

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

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

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

資源隔離

資源隔離也是云上用戶關心的一個問題。尤其是數據庫這類應用，不同租戶的數據庫實例，甚至一個租戶的多套數據庫實例，都跑在一套大Kubernetes管理集群上，相互間會不會有資源爭搶問題？某個實例執行高負載計算任務時，CPU、內存、I/O等會不會對同臺機器上部署的其他實例產生影響？

其實，容器本身就是資源隔離的一個解決方案，容器底層是Linux內核提供的cgroups 技術，用于限制容器內的CPU、內存以及IO等資源的使用，并通過namespace技術實現隔離。而Kubernetes作為容器編排系統，能根據集群中各個節點的資源狀況，選擇最優策略來調度容器。同時，tidb-operator會根據TiDB自身特性和約束來綜合決策TiDB節點的調度分配。

舉例來說，當一個Kubernetes集群橫跨多個可用區，用戶申請創建一個TiDB集群，那么首先根據高可用性原則，將存儲節點盡量分配到不同可用區，并給TiKV打上label。那么同一個可用區內也盡量不把多個TiKV部署到相同的物理節點上，以保證集群資源最大化利用。

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

Kubernetes還可以配置Pod之間的親和性(affinity)和反親和性(anti-affinity)。例如：在TiKV和TiDB之間，可以通過親和性使其調度到網絡延時較小的節點上，提高網絡傳輸效率。TiKV之間借助反親和性，使其分散部署到不同主機、機架和可用區上，降低因硬件或機房故障而導致的數據丟失風險。

上面解釋了容器層的隔離，也可以看作是物理層的隔離。再來看數據層的隔離，TiDB的調度體系也有所考慮，比如一個大的TiDB集群，節點分布在很多臺主機，跨越多個機架、可用區，那么用戶可以定義Namespace，這是一個邏輯概念，不同業務的數據庫和表放置在不同的Namespace，再通過配置Namespace、TiKV節點以及區域的對應關系，由PD模塊來進行調度，從而實現不同業務數據在物理上的隔離。

高可用性

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

另外，TiDB支持基于label的數據調度，能給不同TiKV實例加上描述物理信息的label，例如地域(Region)、可用區(AZ)、機架(Rack)、主機(Host)，當PD在對數據進行調度時，就會參考這些信息更加智能地制定調度策略，盡最大可能保證數據的可用性。

例如，PD會基于label信息盡量把相同數據的副本分散調度到不同的主機、機架、可用區、地域上，這樣在物理節點掛掉、機架掉電或機房出故障時，其它地方仍然有該數據足夠的副本數。借助tidb-operator中controller-manager組件，可以自動給TiKV 實例加上物理拓撲位置標簽，充分發揮PD對數據的智能調度能力，實現數據層面的高可用性。

同時，還可以達到實例級別的高可用性，通過Kubernetes強大的調度規則和擴展的調度器，按優先級會盡量選擇讓TiKV部署到不同的主機、機架和可用區上，把因主機、機架、機房出問題造成的影響降到最低，使數據具有最大的高可用性。

另外，運行在Kubernetes之上，能實時監測到TiDB各組件運行情況，當出現問題時，也能第一時間讓tidb-operator對集群進行自動修復 (self-healing)。具體表現為tidb/tikv/pd實例出現故障時，執行安全的下線操作，同時增加新實例來保證集群的規模和之前一致。

小結

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

UCloud和PingCAP公司深度合作，推出的Cloud TiDB產品現已開啟公測，歡迎大家來體驗云計算架構下的新一代數據庫。