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

作者：瞿鍇，同程藝龍資深 DBA

隨著互聯(lián)網(wǎng)的飛速發(fā)展，業(yè)務(wù)量可能在短短的時(shí)間內(nèi)爆發(fā)式地增長，對(duì)應(yīng)的數(shù)據(jù)量可能快速地從幾百 GB 漲到幾百個(gè) TB，傳統(tǒng)的單機(jī)數(shù)據(jù)庫提供的服務(wù)，在系統(tǒng)的可擴(kuò)展性、性價(jià)比方面已經(jīng)不再適用。為了應(yīng)對(duì)大數(shù)據(jù)量下業(yè)務(wù)服務(wù)訪問的性能問題，MySQL 數(shù)據(jù)庫常用的分庫、分表方案會(huì)隨著 MySQL Sharding（分片）的增多，業(yè)務(wù)訪問數(shù)據(jù)庫邏輯會(huì)越來越復(fù)雜。而且對(duì)于某些有多維度查詢需求的表，需要引入額外的存儲(chǔ)或犧牲性能來滿足查詢需求，這樣會(huì)使業(yè)務(wù)邏輯越來越重，不利于產(chǎn)品的快速迭代。

TiDB 作為 PingCAP 旗下開源的分布式數(shù)據(jù)庫產(chǎn)品，具有多副本強(qiáng)一致性的同時(shí)能夠根據(jù)業(yè)務(wù)需求非常方便的進(jìn)行彈性伸縮，并且擴(kuò)縮容期間對(duì)上層業(yè)務(wù)無感知。TiDB 包括三大核心組件：TiDB/TiKV/PD。

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

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

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

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

由此可見，分布式系統(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)問題時(shí)不能及時(shí)自動(dòng)完成故障轉(zhuǎn)移，需要運(yùn)維人員人工干預(yù)。有些則需要寫大量的 DSL 甚至與 Shell 腳本一起混合使用，可移植性較差，維護(hù)成本比較高。

針對(duì) TiDB 這種復(fù)雜的分布式數(shù)據(jù)庫，我們考慮通過對(duì) TiDB 容器化管理，實(shí)現(xiàn)以下幾個(gè)目的：

一、屏蔽底層物理資源

二、提升資源利用率（CPU、內(nèi)存）

三、提升運(yùn)維效率

四、精細(xì)化管理

因此結(jié)合上述需要，我們開發(fā)了雷神系統(tǒng)來統(tǒng)一管理和維護(hù) TiDB，其整體架構(gòu)如下：

從架構(gòu)圖中可以看出此方案是 TiDB 的私有云架構(gòu)。最下層是容器云，中間一層是開發(fā)的容器編排工具，最上面一層針對(duì) TiDB 特性和實(shí)際使用中遇到的問題點(diǎn)，進(jìn)行了針對(duì)性開發(fā)從而實(shí)現(xiàn)了 TiDB 集群實(shí)例的統(tǒng)一化管理。下面將逐個(gè)介紹各個(gè)模塊的功能。

目前主流的的容器編排系統(tǒng) Kuberbetes 曾是我們?nèi)萜髡{(diào)度的首選解決方案。但 TiDB 作為數(shù)據(jù)庫服務(wù)需要將數(shù)據(jù)庫存儲(chǔ)到本地磁盤，而 Kuberbetes 對(duì) Local Storage 不支持（目前新的版本已經(jīng)開始支持）。針對(duì) TiDB 的特性和業(yè)務(wù)需求，我們決定自己實(shí)現(xiàn)一套容器編排系統(tǒng)，具體解決以下問題：

支持 LocalStorage，解決數(shù)據(jù)存儲(chǔ)問題

基于 cpuset-cpus 實(shí)現(xiàn) CPU 資源的隨機(jī)均衡分配

定制化，支持 label，實(shí)現(xiàn)特定服務(wù)運(yùn)行在特定宿主機(jī)上；宿主機(jī)資源限制

容器的主動(dòng)發(fā)現(xiàn)和通知，以便將之前未管理的宿主機(jī)接入統(tǒng)一管理

容器的全生命周期的管理

容器異常的修復(fù)和通知

雷神 Thor 采用了模塊化設(shè)計(jì)，分為控制模塊和代理模塊，其整體架構(gòu)如下：

說明：

控制模塊包含了 Allocator，Label，Discover，Manage，Customize。Allocator 主要負(fù)責(zé)宿主機(jī)資源的分配；Label 主要用于標(biāo)簽定制；Customize 主要負(fù)責(zé)定制化需求； Discover 主要負(fù)責(zé)容器的發(fā)現(xiàn)和異常檢測；Manage 主要負(fù)責(zé)整體的調(diào)度和分發(fā)。

代理模塊主要負(fù)責(zé)資源檢查和信息收集、接受控制端的命令。

集群管理是整套系統(tǒng)的核心模塊之一，包含了 TiDB 集群的日常維護(hù)操作，實(shí)現(xiàn)了 TiDB 初始化、平滑升級(jí)、彈性容量管理、監(jiān)控的整合、集群的維護(hù)、節(jié)點(diǎn)的維護(hù)等功能。雖然 PingCAP 提供了基于 Ansible 的自動(dòng)部署方案，但是依然需要填寫大量的內(nèi)容和檢查相關(guān)機(jī)器設(shè)定來完成部署。通過此系統(tǒng)只需要將需求按照如何格式提交，即可完成整套集群的部署，部署時(shí)間從之前 2 個(gè)小時(shí)，縮減為 2 分鐘左右。

數(shù)據(jù)庫管理是日常運(yùn)維很核心的一塊，此模塊通過任務(wù)完成統(tǒng)計(jì)信息更新、過載保護(hù)、慢查詢分析和 SQL 預(yù)警。

TiDB 雖然會(huì)自動(dòng)更新統(tǒng)計(jì)信息，但需要達(dá)到固定的變更百分比，因 TiDB 是作為分片庫的合并庫，數(shù)據(jù)量高達(dá)幾十億，若依賴自身的統(tǒng)計(jì)信息維護(hù)，將出現(xiàn)因統(tǒng)計(jì)信息不準(zhǔn)確而觸發(fā)的慢查詢，故針對(duì)此種情況，設(shè)計(jì)和開發(fā)統(tǒng)計(jì)信息自動(dòng)更新，除常規(guī)設(shè)定外，還可設(shè)定例外，避免因統(tǒng)計(jì)信息更新時(shí)影響業(yè)務(wù)的正常使用。

通過對(duì) SQL 的執(zhí)行時(shí)間和內(nèi)存的使用情況分析，針對(duì)不同的集群可以定制不同的過載保護(hù)策略，也可以使用統(tǒng)一的過載保護(hù)策略；當(dāng)觸發(fā)策略時(shí)，會(huì)將相關(guān)信息通過微信的方式通知相關(guān)人員。

通過 ELK 構(gòu)建慢查詢分析系統(tǒng)，通過 mysql-sniffer、flume、kafka、spark、hadoop 構(gòu)建 SQL 預(yù)警，通過對(duì)趨勢的分析和預(yù)判，為后續(xù)自動(dòng)化容量管理做數(shù)據(jù)的積累。

我們嘗試將 TiDB 作為所有數(shù)據(jù)的集合庫提供復(fù)雜查詢，分片集群則提供簡單查詢，同時(shí)由于 TiDB 高度兼容 MySQL 的連接協(xié)議為滿足復(fù)雜的業(yè)務(wù)查詢需求，我們基于 PingCAP 的數(shù)據(jù)同步工具 Syncer 進(jìn)行了代碼重構(gòu)，開發(fā)了 hamal 同步工具，可以自定義庫名和表名，同時(shí)新增了同步狀態(tài)監(jiān)控，如 TPS、延遲等，如果出現(xiàn)異常，會(huì)通過微信告警。從 MySQL 將數(shù)據(jù)實(shí)時(shí)同步到 TiDB 來確保數(shù)據(jù)的一致。該實(shí)時(shí)同步查詢系統(tǒng)架構(gòu)如下所示：

Hamal 是偽裝成 mysql 從，從 mysql 主上通過主從復(fù)制協(xié)議來解析成對(duì)應(yīng)的 sql 語句，并經(jīng)過過濾、改寫等步驟，將最終語句在目標(biāo)庫執(zhí)行的工具。Hamal 主要包含以下特性：

position 以及 gtid 模式支持

自動(dòng)切換主從支持（需要提前配置好主從服務(wù)列表）

多目標(biāo)庫支持（多 tidb-server）

binlog 心跳支持

庫、表級(jí)別過濾，重寫支持（用于分片合庫）

庫表級(jí)別額外索引支持

拆解字段支持（額外輸出選擇某幾個(gè)字段的小表）

字段過濾支持

智能更新表結(jié)構(gòu)

多線程合并小事務(wù)后執(zhí)行，多種分發(fā)策略

純文本執(zhí)行模式支持

Hamal 的內(nèi)部實(shí)現(xiàn)如下：

從架構(gòu)圖中可以看出，通過設(shè)定不同的 generators，hamal 支持同步到不同目的庫或者其他存儲(chǔ)方式。

監(jiān)控對(duì)于系統(tǒng)的重要性不言而喻。能否有效的告警直接影響著監(jiān)控的質(zhì)量，因此監(jiān)控的核心是監(jiān)控?cái)?shù)據(jù)的采集和有效的告警。監(jiān)控?cái)?shù)據(jù)主要有三種系統(tǒng)本身的運(yùn)行狀態(tài)，例如 CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)的使用情況；各種應(yīng)用的運(yùn)行狀況，例如數(shù)據(jù)庫、容器等，處理網(wǎng)絡(luò)上發(fā)送過來的數(shù)據(jù)。通過監(jiān)控項(xiàng)設(shè)定和監(jiān)控例外，可以靈活的定制監(jiān)控信息的收集。合理、靈活的監(jiān)控規(guī)則可以幫助更快、更精確的定位異常，通過告警策略和告警例外滿足不同的告警需求。監(jiān)控和告警中心的架構(gòu)圖如下：

其中，監(jiān)控?cái)?shù)據(jù)的采集一部分依賴于現(xiàn)有監(jiān)控系統(tǒng)中的數(shù)據(jù)，如 zabbix 之類；一部分通過 TiDB 的 API 獲取，一部分是開源的收集器，因此導(dǎo)致原始數(shù)據(jù)存儲(chǔ)在不同類型的數(shù)據(jù)庫，通過開發(fā)的同步工具，將上述數(shù)據(jù)同步獨(dú)立部署的 TiDB 集群，以便后續(xù)的數(shù)據(jù)分析?？梢暬膶?shí)現(xiàn)主要基于 grafana 來完成。告警模塊是基于實(shí)際的需求，進(jìn)行開發(fā)和實(shí)現(xiàn)的，未采用現(xiàn)有的一些開源方案。

在對(duì) TiDB 的使用過程中，我們按照 1 庫 1 集群的方式進(jìn)行服務(wù)部署，這種部署方式可以有效避免不同庫的壓力不均導(dǎo)致相互影響的問題，同時(shí)性能監(jiān)控精準(zhǔn)到庫級(jí)別，而使用了雷神系統(tǒng)后，能夠有效的在單臺(tái)服務(wù)器上對(duì)各種服務(wù)資源進(jìn)行快速部署，提升資源利用率的同時(shí)避免資源爭用帶來的問題。

系統(tǒng)上線一年以來，已完成公司所有 TiDB 集群從物理機(jī)部署到容器化的平穩(wěn)遷移；管理了數(shù)百臺(tái)機(jī)器和數(shù)十套 TiDB Cluster，接入應(yīng)用數(shù)百個(gè)，承載著幾十 T 的數(shù)據(jù)量，峰值 TPS 數(shù)十萬；上線前部署一個(gè) TiDB 集群需要花費(fèi)將近 2 個(gè)小時(shí)，雷神系統(tǒng)上線后只需要 2 分鐘即可部署完成。有效的提升了 DBA 的運(yùn)維效率和整個(gè) TiDB 服務(wù)的可用性。

未來我們將繼續(xù)深入，從審計(jì)和 SQL 分析方面著手，為業(yè)務(wù)提供更多的效率提升和穩(wěn)定性保障。

原文鏈接：雷神Thor—TIDB自動(dòng)化運(yùn)維平臺(tái)