摘要：作為一個(gè)開(kāi)源的分布式數(shù)據(jù)庫(kù)產(chǎn)品，具有多副本強(qiáng)一致性的同時(shí)能夠根據(jù)業(yè)務(wù)需求非常方便的進(jìn)行彈性伸縮，并且擴(kuò)縮容期間對(duì)上層業(yè)務(wù)無(wú)感知。另外本身維護(hù)了數(shù)據(jù)多副本，這點(diǎn)和分布式文件系統(tǒng)的多副本是有重復(fù)的。

作者：鄧栓
來(lái)源：細(xì)說(shuō)云計(jì)算

作為一款定位在 Cloud-native 的數(shù)據(jù)庫(kù)，現(xiàn)如今 TiDB 在云整合上已取得了階段性的進(jìn)展。日前 Cloud TiDB 產(chǎn)品在 UCloud 平臺(tái)正式開(kāi)啟公測(cè)，TiDB 彈性伸縮的特性在 Cloud 提供的基礎(chǔ)設(shè)施支持下發(fā)揮的淋漓盡致。在感受云數(shù)據(jù)庫(kù)魅力的同時(shí)，讓我們來(lái)一探究竟，看一下 TiDB 與 Cloud 背后的技術(shù)秘密。

首先還是要先從 TiDB 的架構(gòu)說(shuō)起，TiDB 和傳統(tǒng)的單機(jī)關(guān)系型數(shù)據(jù)庫(kù)有什么不同？相信長(zhǎng)期以來(lái)一直關(guān)注 TiDB 的同學(xué)都比較了解了，但這里還是科普一下。TiDB 作為一個(gè)開(kāi)源的分布式數(shù)據(jù)庫(kù)產(chǎn)品，具有多副本強(qiáng)一致性的同時(shí)能夠根據(jù)業(yè)務(wù)需求非常方便的進(jìn)行彈性伸縮，并且擴(kuò)縮容期間對(duì)上層業(yè)務(wù)無(wú)感知。TiDB 的主體架構(gòu)包含三個(gè)模塊，對(duì)應(yīng) GitHub 上面 PingCAP 組織下的三個(gè)開(kāi)源項(xiàng)目，TiDB / TiKV / PD：

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

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

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

上面的這三個(gè)模塊，每個(gè)角色都是一個(gè)多節(jié)點(diǎn)組成的集群，所以最終 TiDB 的架構(gòu)看起來(lái)是這樣的。

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

在云時(shí)代，容器成為應(yīng)用分發(fā)部署的基本單位，而谷歌基于內(nèi)部使用數(shù)十年的容器編排系統(tǒng) Borg 經(jīng)驗(yàn)推出的開(kāi)源容器編排系統(tǒng) Kubernetes 成為當(dāng)前容器編排技術(shù)的主流。作為 Cloud Native Database，TiDB 選擇擁抱容器技術(shù)，并與 Kubernetes 進(jìn)行深度整合，使其可以非常方便地基于 Kubernetes 完成數(shù)據(jù)庫(kù)的自動(dòng)化管理。

Kubernetes 項(xiàng)目可以說(shuō)是為 Cloud 而生，利用云平臺(tái)的 IaaS 層提供的 API 可以很方便的和云進(jìn)行整合。這樣我們要做的事情就很明確了，只要讓 TiDB 與 Kubernetes 結(jié)合的更好，進(jìn)而就實(shí)現(xiàn)了和各個(gè)云平臺(tái)的整合， 使得 TiDB 在云上的快速部署和高效運(yùn)維成為現(xiàn)實(shí)。

Kubernetes 最早是作為一個(gè)純粹的容器編排系統(tǒng)而誕生的，用戶部署好 Kubernetes 集群之后，直接使用其內(nèi)置的各種功能部署應(yīng)用服務(wù)。由于這個(gè) PaaS 平臺(tái)使用起來(lái)非常便利，吸引了很多用戶，不同用戶也提出了各種不同的需求，有些特性需求 Kubernetes 直接在其核心代碼里面實(shí)現(xiàn)了，但是有些特性并不適合合并到主干分支，為滿足這類需求，Kubernetes 開(kāi)放出一些 API 供用戶自己擴(kuò)展，實(shí)現(xiàn)自己的需求。當(dāng)前 Kubernetes 已經(jīng)發(fā)展到 v1.8，其內(nèi)部的 API 變得越來(lái)越開(kāi)放，使其更像是一個(gè)跑在云上的操作系統(tǒng)。用戶可以把它當(dāng)作一套云的 SDK 或 Framework 來(lái)使用，而且可以很方便地開(kāi)發(fā)組件來(lái)擴(kuò)展?jié)M足自己的業(yè)務(wù)需求。對(duì)有狀態(tài)服務(wù)的支持就是一個(gè)很有代表性的例子。

Kubernetes 項(xiàng)目最早期只支持無(wú)狀態(tài)服務(wù) (Stateless Service) 來(lái)管理的，無(wú)狀態(tài)服務(wù)通過(guò) ReplicationController 定義多個(gè)副本，由 Kubernetes 調(diào)度器來(lái)決定在不同節(jié)點(diǎn)上啟動(dòng)多個(gè) Pod，實(shí)現(xiàn)負(fù)載均衡和故障轉(zhuǎn)移。對(duì)于無(wú)狀態(tài)服務(wù)，多個(gè)副本對(duì)應(yīng)的 Pod 是等價(jià)的，所以在節(jié)點(diǎn)出現(xiàn)故障時(shí)，在新節(jié)點(diǎn)上啟動(dòng)一個(gè) Pod 與失效的 Pod 是等價(jià)的，不會(huì)涉及狀態(tài)遷移問(wèn)題，因而管理非常簡(jiǎn)單。但是對(duì)于有狀態(tài)服務(wù) (Stateful Service)，由于需要將數(shù)據(jù)持久化到磁盤，使得不同 Pod 之間不能再認(rèn)為成等價(jià)，也就不能再像無(wú)狀態(tài)服務(wù)那樣隨意進(jìn)行調(diào)度遷移。Kubernetes v1.3 版本提出 PetSet 的概念用來(lái)管理有狀態(tài)服務(wù)并于 v1.5 將其更名為 StatefulSet。StatefulSet 明確定義一組 Pod 中每個(gè)的身份，啟動(dòng)和升級(jí)都按特定順序來(lái)操作。另外使用持久化卷存儲(chǔ) (PersistentVolume) 來(lái)作為存儲(chǔ)數(shù)據(jù)的載體，當(dāng)節(jié)點(diǎn)失效 Pod 需要遷移時(shí)，對(duì)應(yīng)的 PV 也會(huì)重新掛載，而 PV 的底層依托于分布式文件系統(tǒng)，所以 Pod 仍然能訪問(wèn)到之前的數(shù)據(jù)。同時(shí) Pod 在發(fā)生遷移時(shí)，其網(wǎng)絡(luò)身份例如 IP 地址是會(huì)發(fā)生變化的，很多分布式系統(tǒng)不能接受這種情況。所以 StatefulSet 在遷移 Pod 時(shí)可以通過(guò)綁定域名的方式來(lái)保證 Pod 在集群中網(wǎng)絡(luò)身份不發(fā)生變化。

然而現(xiàn)實(shí)中一些分布式系統(tǒng)更為復(fù)雜，StatefulSet 也顯得捉襟見(jiàn)肘。舉例來(lái)說(shuō)，某些分布式系統(tǒng)的節(jié)點(diǎn)在加入集群或下線時(shí)還需要做些額外的注冊(cè)和清理操作，或者滾動(dòng)升級(jí)要考量版本兼容性等?；谶@個(gè)原因 CoreOS 公司提出了 Operator 概念，并實(shí)現(xiàn)了 etcd-operator 和 prometheus-operator 來(lái)管理 Etcd 和 Prometheus 這樣的復(fù)雜分布式系統(tǒng)。用戶可以開(kāi)發(fā)自己的 Operator，在 Kubernetes 之上實(shí)現(xiàn)自定義的 Controller，將有狀態(tài)服務(wù)的領(lǐng)域特定的運(yùn)維知識(shí)編碼進(jìn)去，從而實(shí)現(xiàn)對(duì)特定分布式系統(tǒng)的管理。同時(shí) Operator 本身也是跑在 Kubernetes 中的一組 Pod（deployment），對(duì) Kubernetes 系統(tǒng)并無(wú)侵入性。

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

由于 TiDB 對(duì)磁盤 I/O 有比較高的要求，通過(guò) PV 掛載網(wǎng)絡(luò)盤性能上會(huì)有明顯的性能損耗。另外 TiKV 本身維護(hù)了數(shù)據(jù)多副本，這點(diǎn)和分布式文件系統(tǒng)的多副本是有重復(fù)的。所以我們要給 Pod 上掛載本地磁盤，并且在 Kubernetes 上面把 Local PV 管理起來(lái)，作為一種特定的資源來(lái)維護(hù)。Kubernetes 長(zhǎng)期以來(lái)官方一直沒(méi)有提供 Local PV 支持，本地存儲(chǔ)只支持 hostPath 和 emptyDir 兩種方式。其中 hostPath 的生命周期是脫離 Kubernetes 管理的，使用 hostPath 的 Pod 銷毀后，里面的數(shù)據(jù)是不會(huì)被自動(dòng)清理，下次再掛載 Pod 就會(huì)造成臟數(shù)據(jù)。而 emptyDir 更像一個(gè)臨時(shí)磁盤，在 Pod 重建時(shí)會(huì)被清理重置，不能成為持久化 PV 來(lái)使用。為此我們開(kāi)發(fā)了一個(gè) tidb-volume-manager 組件，用于管理 Kubernetes 集群中每臺(tái)物理主機(jī)上的本地磁盤，并且將其暴露成一種特殊的 PV 資源。結(jié)合 Operator 在部署 TiDB 節(jié)點(diǎn)時(shí)會(huì)參考 Local PV 資源的情況來(lái)選擇特定的節(jié)點(diǎn)來(lái)部署，分配一個(gè)空的 Local PV 和 Pod 綁定。而當(dāng) Pod 銷毀時(shí)候會(huì)根據(jù)具體情況來(lái)決定是否結(jié)束 Local PV 的生命周期，釋放掉的 Local PV 再經(jīng)歷一個(gè) gc 周期后，被 tidb-volume-manager 回收，清理其盤上數(shù)據(jù)等待再次被分配使用。

將這些組件整合起來(lái)，就形成了上圖描述了 Cloud TiDB 的總體架構(gòu)，在 Kubenetes 管理的集群之上通過(guò) tidb-operator 等組件來(lái)針對(duì)性的調(diào)配和使用集群資源，從而實(shí)現(xiàn) TiDB 集群實(shí)例的生命周期管理。通過(guò)這種方式，來(lái)實(shí)現(xiàn) TiDB 分布式數(shù)據(jù)庫(kù)和云平臺(tái)的整合。接下來(lái)，我們?cè)籴槍?duì) Cloud TiDB 的關(guān)鍵特性和實(shí)現(xiàn)細(xì)節(jié)分別進(jìn)行解讀。

數(shù)據(jù)庫(kù)產(chǎn)品上云的一個(gè)先決條件是能實(shí)現(xiàn)自動(dòng)化的運(yùn)維管理，否則在云上靠手工運(yùn)維幾乎是不現(xiàn)實(shí)的。我們首先用 Kubernetes 將云平臺(tái)的主機(jī)資源管理起來(lái)，組成一個(gè)大的資源池。然后再通過(guò) tidb-opeartor 及 tidb-cloud-manager 等組件來(lái)自動(dòng)化完成 TiDB 實(shí)例的一鍵部署、擴(kuò)容縮容、在線滾動(dòng)升級(jí)、自動(dòng)故障轉(zhuǎn)移等運(yùn)維操作。

首先拿集群創(chuàng)建來(lái)說(shuō)。前面提到過(guò)，TiDB 包含三大核心組件：TiDB / TiKV / PD，每個(gè)服務(wù)又都是一個(gè)多節(jié)點(diǎn)的分布式結(jié)構(gòu)。服務(wù)和服務(wù)之間的啟動(dòng)順序也存在依賴關(guān)系。此外，PD 節(jié)點(diǎn)的創(chuàng)建和加入集群方式和 etcd 類似，是需要先創(chuàng)建一個(gè)單節(jié)點(diǎn)的 initial 集群，后面加入的節(jié)點(diǎn)需要用特殊的 join 方式，啟動(dòng)命令上都有差別。有一些操作完成后還需要調(diào)用 API 進(jìn)行通知。Kubernetes 自身提供的 StatefulSet 是很難應(yīng)付這種復(fù)雜的部署，所以需要 tidb-operator 中實(shí)現(xiàn)特定的 Controller 來(lái)完成這樣一系列的操作。并且結(jié)合 Kubernetese 強(qiáng)大的調(diào)度功能，合理的規(guī)劃和分配整個(gè)集群資源，盡量讓新部署的 TiDB 實(shí)例節(jié)點(diǎn)在集群中均勻分布，最終通過(guò) LB 暴露給對(duì)應(yīng)的租戶使用。

在線升級(jí)也是類似。由于 TiKV / PD 的 Pod 掛載的是本地存儲(chǔ)，并不能像云平臺(tái)提供的塊存儲(chǔ)或網(wǎng)絡(luò)文件系統(tǒng)那樣可以隨意掛載。如果 TiKV / PD 遷移到其它節(jié)點(diǎn)，相當(dāng)于數(shù)據(jù)目錄也被清空，所以必須保證 TiKV / PD 的 Pod 在升級(jí)完成后仍然能夠調(diào)度在原地，這也是要由 tidb-operator 的 Controller 來(lái)保證。TiDB 的數(shù)據(jù)副本之間由 Raft 算法來(lái)保證一致性，因此當(dāng)集群中某一個(gè)節(jié)點(diǎn)暫時(shí)斷開(kāi)可以不影響整個(gè)服務(wù)的。所以在集群升級(jí)的過(guò)程中，必須嚴(yán)格按照服務(wù)的依賴關(guān)系，再依次對(duì) Pod 進(jìn)行升級(jí)。

當(dāng)節(jié)點(diǎn)出現(xiàn)故障時(shí)，同樣是由于掛載本地?cái)?shù)據(jù)盤的原因，也不能像 StatefulSet 那樣直接把 Pod 遷移走。當(dāng) TiDB Operator 檢測(cè)到節(jié)點(diǎn)失效，首先要等一定的時(shí)間確認(rèn)節(jié)點(diǎn)不會(huì)再恢復(fù)了，開(kāi)始遷移恢復(fù)的操作。首先調(diào)度選擇一個(gè)新節(jié)點(diǎn)啟動(dòng)一個(gè) Pod, 然后通知 TiDB 將失效的節(jié)點(diǎn)放棄掉，并將新啟的 Pod 加入集群。后面會(huì)由 TiDB 的 PD 模塊來(lái)完成數(shù)據(jù)副本數(shù)的恢復(fù)，以及數(shù)據(jù)往新節(jié)點(diǎn)上進(jìn)行搬移，從而重新維持集群內(nèi)數(shù)據(jù)平衡。

以上只是列舉了 TiDB 幾種典型的運(yùn)維操作流程，實(shí)際生產(chǎn)上運(yùn)維還有很多 case 需要考慮，這些都以程序的方式實(shí)現(xiàn)在 tidb-operator 里面。借助 Kubernetes 和 tidb-operator 來(lái)代替人工，高效的完成 TiDB 數(shù)據(jù)庫(kù)在云平臺(tái)上的復(fù)雜運(yùn)維管理。

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

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

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

資源隔離也是云上用戶關(guān)心的一個(gè)問(wèn)題。尤其是數(shù)據(jù)庫(kù)這類應(yīng)用，不同租戶的數(shù)據(jù)庫(kù)實(shí)例，甚至一個(gè)租戶的多套數(shù)據(jù)庫(kù)實(shí)例，都跑在一套大的 Kubernetes 管理的集群上，相互間會(huì)不會(huì)有資源的爭(zhēng)搶問(wèn)題，某個(gè)實(shí)例執(zhí)行高負(fù)載的計(jì)算任務(wù)時(shí)，CPU、內(nèi)存、I/O 等會(huì)不會(huì)對(duì)同臺(tái)機(jī)器上部署的其他實(shí)例產(chǎn)生影響。其實(shí)容器本身就是資源隔離的一個(gè)解決方案，容器的底層是 Linux 內(nèi)核提供的 cgroups 技術(shù)，用于限制容器內(nèi)的 CPU、內(nèi)存以及 IO 等資源的使用，并通過(guò) namespace 技術(shù)實(shí)現(xiàn)隔離。而 Kubernetes 作為容器編排系統(tǒng)，能夠根據(jù)集群中各個(gè)節(jié)點(diǎn)的資源狀況，選擇最優(yōu)的策略來(lái)調(diào)度容器。同時(shí) tidb-operator 會(huì)根據(jù) TiDB 自身的特性和約束，來(lái)綜合決策 TiDB 節(jié)點(diǎn)的調(diào)度分配。舉例來(lái)說(shuō)，當(dāng)一個(gè) Kubernetes 集群橫跨多個(gè)可用區(qū)，用戶申請(qǐng)創(chuàng)建一個(gè) TiDB 集群，那么首先根據(jù)高可用性原則，將存儲(chǔ)節(jié)點(diǎn)盡量分配到不同的可用區(qū)，并給 TiKV 打上 label。那么同一個(gè)可用區(qū)內(nèi)也盡量不把多個(gè) TiKV 部署到相同的物理節(jié)點(diǎn)上，以保證集群資源最大化利用。此外，每個(gè) Local PV 也是一塊獨(dú)立的磁盤，每個(gè) TiKV 的 Pod 分別掛載不同的盤，所以 I/O 上也是完全隔離的。Kubernetes 還可以配置 Pod 之間的親和性(affinity)和反親和性(anti-affinity)，例如 TiKV 和 TiDB 之間我們可以通過(guò)親和性使其調(diào)度到網(wǎng)絡(luò)延時(shí)較小的節(jié)點(diǎn)之上，提高網(wǎng)絡(luò)傳輸效率，TiKV 之間借助反親和性，使其分散部署到不同的主機(jī)、機(jī)架和可用區(qū)上，降低因硬件或機(jī)房故障造成的丟數(shù)據(jù)的風(fēng)險(xiǎn)。

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

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

另外 TiDB 支持基于 label 的數(shù)據(jù)調(diào)度的，給不同的 TiKV 實(shí)例加上描述物理信息的 label，例如地域(Region)、可用區(qū)(AZ)、機(jī)架(Rack)、主機(jī)(Host)，這樣 PD 在對(duì)數(shù)據(jù)進(jìn)行調(diào)度時(shí)就會(huì)參考這些信息更加智能的制定調(diào)度策略，盡最大可能保證數(shù)據(jù)的可用性。例如 PD 會(huì)基于 label 信息盡量把相同數(shù)據(jù)的副本分散調(diào)度到不同的主機(jī)、機(jī)架、可用區(qū)、地域上，這樣在物理節(jié)點(diǎn)掛掉或機(jī)架掉電或機(jī)房出故障時(shí)，其它地方仍然有該數(shù)據(jù)足夠的副本數(shù)。借助 tidb-operator 中 controller-manager 組件我們可以自動(dòng)給 TiKV 實(shí)例加上物理拓?fù)湮恢脴?biāo)簽，充分發(fā)揮 PD 對(duì)數(shù)據(jù)的智能調(diào)度能力，實(shí)現(xiàn)數(shù)據(jù)層面的高可用性。

同時(shí)我們還可以實(shí)現(xiàn)實(shí)例級(jí)別的高可用性，通過(guò) Kubernetes 強(qiáng)大的調(diào)度規(guī)則和我們擴(kuò)展的調(diào)度器，我們按優(yōu)先級(jí)會(huì)盡量選擇讓 TiKV 部署到不同的主機(jī)、機(jī)架和可用區(qū)上，把因主機(jī)、機(jī)架、機(jī)房出問(wèn)題造成的影響降到最低，使數(shù)據(jù)具有最大的高可用性。
另外運(yùn)行在 Kubernetes 之上我們能實(shí)時(shí)監(jiān)測(cè)到 TiDB 各組件的運(yùn)行情況，當(dāng)出現(xiàn)問(wèn)題時(shí)，我們也能第一時(shí)間讓 tidb-operator 對(duì)集群進(jìn)行自動(dòng)修復(fù) (self-healing)。具體表現(xiàn)為 TiDB / TiKV / PD 實(shí)例出現(xiàn)故障時(shí)，執(zhí)行安全的下線操作。同時(shí)增加新的實(shí)例，來(lái)保證集群的規(guī)模和之前一致。

TiDB 作為一款 Cloud Native Database，通過(guò) tidb-operator 的方式充分發(fā)揮 Kubernetes 平臺(tái)的強(qiáng)大能力，實(shí)現(xiàn)云上自動(dòng)化管理，極大降低人力運(yùn)維成本。用戶可以根據(jù)業(yè)務(wù)需要進(jìn)行動(dòng)態(tài)擴(kuò)容縮容，多租戶隔離特性讓不同租戶的實(shí)例可以共享計(jì)算和存儲(chǔ)資源，互不干擾，同時(shí)最大程度充分使用云上資源。Raft 算法和 tidb-operator 自動(dòng)修復(fù)能力以及兩層調(diào)度機(jī)制保證了 Cloud TiDB 的高可用性。UCloud 和 PingCAP 公司深度合作，推出 Cloud TiDB 產(chǎn)品現(xiàn)已開(kāi)啟公測(cè)，歡迎大家來(lái)體驗(yàn)云時(shí)代的新一代數(shù)據(jù)庫(kù)。