為了方便描述，圖中 Sharding-JDBC 部分稱為老 Sharding 集群，DBProxy 部分稱為新 Sharding 集群。

新 Sharding 集群按照 order_id 取模通過 DBproxy 寫入各分表，解決數(shù)據(jù)分布不均、熱點(diǎn)等問題。

將老 Sharding 集群的數(shù)據(jù)通過使用 DRC（摩拜自研的開源異構(gòu)數(shù)據(jù)同步工具 Gravity）全量+增量同步到新 Sharding 集群，并將增量數(shù)據(jù)進(jìn)行打標(biāo)，反向同步鏈路忽略帶標(biāo)記的流量，避免循環(huán)復(fù)制。

為支持上線過程中業(yè)務(wù)回滾至老 Sharding 集群，需要將新 Sharding 集群上的增量數(shù)據(jù)同步回老 Sharding 集群，由于寫回老 Sharding 集群需要耦合業(yè)務(wù)邏輯，因此 DRC（Gravity）負(fù)責(zé)訂閱 DBProxy-Sharding 集群的增量數(shù)放入 Kafka，由業(yè)務(wù)方開發(fā)一個(gè)消費(fèi) Kafka 的服務(wù)將數(shù)據(jù)寫入到老 Sharding 集群。

新的 TiDB 集群作為訂單合庫(kù)，使用 DRC（Gravity）從新 Sharding 集群同步數(shù)據(jù)到 TiDB中。

新方案中 DBProxy 集群負(fù)責(zé) order_id 的讀寫流量，TiDB 合庫(kù)作為 readonly 負(fù)責(zé)其他多維度的查詢。

2.3.1 上線初期新集群流量灰度到 20% 的時(shí)候，發(fā)現(xiàn) TiDB coprocessor 非常高，日志出現(xiàn)大量 server is busy 錯(cuò)誤。

問題分析：

訂單數(shù)據(jù)單表超過 100 億行，每次查詢涉及的數(shù)據(jù)分散在 1000+ 個(gè) Region 上，根據(jù) index 構(gòu)造的 handle 去讀表數(shù)據(jù)的時(shí)候需要往這些 Region 上發(fā)送很多 distsql 請(qǐng)求，進(jìn)而導(dǎo)致 coprocessor 上 gRPC 的 QPS 上升。

TiDB 的執(zhí)行引擎是以 Volcano 模型運(yùn)行，所有的物理 Executor 構(gòu)成一個(gè)樹狀結(jié)構(gòu)，每一層通過調(diào)用下一層的 Next/NextChunk() 方法獲取結(jié)果。Chunk 是內(nèi)存中存儲(chǔ)內(nèi)部數(shù)據(jù)的一種數(shù)據(jù)結(jié)構(gòu)，用于減小內(nèi)存分配開銷、降低內(nèi)存占用以及實(shí)現(xiàn)內(nèi)存使用量統(tǒng)計(jì)/控制，TiDB 2.0 中使用的執(zhí)行框架會(huì)不斷調(diào)用 Child 的 NextChunk 函數(shù)，獲取一個(gè) Chunk 的數(shù)據(jù)。每次函數(shù)調(diào)用返回一批數(shù)據(jù)，數(shù)據(jù)量由一個(gè)叫 tidb_max_chunk_size 的 session 變量來控制，默認(rèn)是 1024 行。訂單表的特性，由于數(shù)據(jù)分散，實(shí)際上單個(gè) Region 上需要訪問的數(shù)據(jù)并不多。所以這個(gè)場(chǎng)景 Chunk size 直接按照默認(rèn)配置（1024）顯然是不合適的。

解決方案：

升級(jí)到 2.1 GA 版本以后，這個(gè)參數(shù)變成了一個(gè)全局可調(diào)的參數(shù)，并且默認(rèn)值改成了 32，這樣內(nèi)存使用更加高效、合理，該問題得到解決。

2.3.2 數(shù)據(jù)全量導(dǎo)入 TiDB 時(shí)，由于 TiDB 會(huì)默認(rèn)使用一個(gè)隱式的自增 rowid，大量 INSERT 時(shí)把數(shù)據(jù)集中寫入單個(gè) Region，造成寫入熱點(diǎn)。

解決方案：

通過設(shè)置 SHARD_ROW_ID_BITS，可以把 rowid 打散寫入多個(gè)不同的 Region，緩解寫入熱點(diǎn)問題：ALTER TABLE table_name SHARD_ROW_ID_BITS = 8;。

2.3.3 異地機(jī)房由于網(wǎng)絡(luò)延遲相對(duì)比較高，設(shè)計(jì)中賦予它的主要職責(zé)是災(zāi)備，并不提供服務(wù)。曾經(jīng)出現(xiàn)過一次大約持續(xù) 10s 的網(wǎng)絡(luò)抖動(dòng)，TiDB 端發(fā)現(xiàn)大量的 no Leader 日志，Region follower 節(jié)點(diǎn)出現(xiàn)網(wǎng)絡(luò)隔離情況，隔離節(jié)點(diǎn) term 自增，重新接入集群時(shí)候會(huì)導(dǎo)致 Region 重新選主，較長(zhǎng)時(shí)間的網(wǎng)絡(luò)波動(dòng)，會(huì)讓上面的選主發(fā)生多次，而選主過程中無法提供正常服務(wù)，最后可能導(dǎo)致雪崩。

問題分析：

Raft 算法中一個(gè) Follower 出現(xiàn)網(wǎng)絡(luò)隔離的場(chǎng)景，如下圖所示。

Follower C 在 election timeout 沒收到心跳之后，會(huì)發(fā)起選舉，并轉(zhuǎn)換為 Candidate 角色。

每次發(fā)起選舉時(shí)都會(huì)把 term 加 1，由于網(wǎng)絡(luò)隔離，選舉失敗的 C 節(jié)點(diǎn) term 會(huì)不斷增大。

在網(wǎng)絡(luò)恢復(fù)后，這個(gè)節(jié)點(diǎn)的 term 會(huì)傳播到集群的其他節(jié)點(diǎn)，導(dǎo)致重新選主，由于 C 節(jié)點(diǎn)的日志數(shù)據(jù)實(shí)際上不是最新的，并不會(huì)成為 Leader，整個(gè)集群的秩序被這個(gè)網(wǎng)絡(luò)隔離過的 C 節(jié)點(diǎn)擾亂，這顯然是不合理的。

解決方案：

TiDB 2.1 GA 版本引入了 Raft PreVote 機(jī)制，該問題得到解決。

在 PreVote 算法中，Candidate 首先要確認(rèn)自己能贏得集群中大多數(shù)節(jié)點(diǎn)的投票，才會(huì)把自己的 term 增加，然后發(fā)起真正的投票，其他節(jié)點(diǎn)同意發(fā)起重新選舉的條件更嚴(yán)格，必須同時(shí)滿足 ：

沒有收到 Leader 的心跳，至少有一次選舉超時(shí)。

Candidate 日志足夠新。PreVote 算法的引入，網(wǎng)絡(luò)隔離節(jié)點(diǎn)由于無法獲得大部分節(jié)點(diǎn)的許可，因此無法增加 term，重新加入集群時(shí)不會(huì)導(dǎo)致重新選主。

在線業(yè)務(wù)集群，承載了用戶余額變更、我的消息、用戶生命周期、信用分等 P1 級(jí)業(yè)務(wù)，數(shù)據(jù)規(guī)模和訪問量都在可控范圍內(nèi)。產(chǎn)出的 TiDB Binlog 可以通過 Gravity 以增量形式同步給大數(shù)據(jù)團(tuán)隊(duì)，通過分析模型計(jì)算出用戶新的信用分定期寫回 TiDB 集群。

數(shù)據(jù)沙盒，屬于離線業(yè)務(wù)集群，是摩拜單車的一個(gè)數(shù)據(jù)聚合集群。目前運(yùn)行著近百個(gè) TiKV 實(shí)例，承載了 60 多 TB 數(shù)據(jù)，由公司自研的 Gravity 數(shù)據(jù)復(fù)制中心將線上數(shù)據(jù)庫(kù)實(shí)時(shí)匯總到 TiDB 供離線查詢使用，同時(shí)集群也承載了一些內(nèi)部的離線業(yè)務(wù)、數(shù)據(jù)報(bào)表等應(yīng)用。目前集群的總寫入 TPS 平均在 1-2w/s，QPS 峰值 9w/s+，集群性能比較穩(wěn)定。該集群的設(shè)計(jì)優(yōu)勢(shì)有如下幾點(diǎn)：

可供開發(fā)人員安全的查詢線上數(shù)據(jù)。

特殊場(chǎng)景下的跨庫(kù)聯(lián)表 SQL。

大數(shù)據(jù)團(tuán)隊(duì)的數(shù)據(jù)抽取、離線分析、BI 報(bào)表。

可以隨時(shí)按需增加索引，滿足多維度的復(fù)雜查詢。

離線業(yè)務(wù)可以直接將流量指向沙盒集群，不會(huì)對(duì)線上數(shù)據(jù)庫(kù)造成額外負(fù)擔(dān)。

分庫(kù)分表的數(shù)據(jù)聚合。

數(shù)據(jù)歸檔、災(zāi)備。

4.1.1 TiDB server oom 重啟

很多使用過 TiDB 的朋友可能都遇到過這一問題，當(dāng) TiDB 在遇到超大請(qǐng)求時(shí)會(huì)一直申請(qǐng)內(nèi)存導(dǎo)致 oom, 偶爾因?yàn)橐粭l簡(jiǎn)單的查詢語句導(dǎo)致整個(gè)內(nèi)存被撐爆，影響集群的總體穩(wěn)定性。雖然 TiDB 本身有 oom action 這個(gè)參數(shù)，但是我們實(shí)際配置過并沒有效果。

于是我們選擇了一個(gè)折中的方案，也是目前 TiDB 比較推薦的方案：?jiǎn)闻_(tái)物理機(jī)部署多個(gè) TiDB 實(shí)例，通過端口進(jìn)行區(qū)分，給不穩(wěn)定查詢的端口設(shè)置內(nèi)存限制（如圖 5 中間部分的 TiDBcluster1 和 TiDBcluster2）。例：

[tidb_servers]
tidb-01-A ansible_host=$ip_address deploy_dir=/$deploydir1 tidb_port=$tidb_port1 tidb_status_port=$status_port1
tidb-01-B ansible_host=$ip_address deploy_dir=/$deploydir2 tidb_port=$tidb_port2 tidb_status_port=$status_port2  MemoryLimit=20G 

實(shí)際上 tidb-01-A、tidb-01-B 部署在同一臺(tái)物理機(jī)，tidb-01-B 內(nèi)存超過閾值會(huì)被系統(tǒng)自動(dòng)重啟，不影響 tidb-01-A。

TiDB 在 2.1 版本后引入新的參數(shù) tidb_mem_quota_query，可以設(shè)置查詢語句的內(nèi)存使用閾值，目前 TiDB 已經(jīng)可以部分解決上述問題。

4.1.2 TiDB-Binlog 組件的效率問題

大家平時(shí)關(guān)注比較多的是如何從 MySQL 遷移到 TiDB，但當(dāng)業(yè)務(wù)真正遷移到 TiDB 上以后，TiDB 的 Binlog 就開始變得重要起來。TiDB-Binlog 模塊，包含 Pump&Drainer 兩個(gè)組件。TiDB 開啟 Binlog 后，將產(chǎn)生的 Binlog 通過 Pump 組件實(shí)時(shí)寫入本地磁盤，再異步發(fā)送到 Kafka，Drainer 將 Kafka 中的 Binlog 進(jìn)行歸并排序，再轉(zhuǎn)換成固定格式輸出到下游。

使用過程中我們碰到了幾個(gè)問題：

Pump 發(fā)送到 Kafka 的速度跟不上 Binlog 產(chǎn)生的速度。

Drainer 處理 Kafka 數(shù)據(jù)的速度太慢，導(dǎo)致延時(shí)過高。

單機(jī)部署多 TiDB 實(shí)例，不支持多 Pump。

其實(shí)前兩個(gè)問題都是讀寫 Kafka 時(shí)產(chǎn)生的，Pump&Drainer 按照順序、單 partition 分別進(jìn)行讀&寫，速度瓶頸非常明顯，后期增大了 Pump 發(fā)送的 batch size，加快了寫 Kafka 的速度。但同時(shí)又遇到一些新的問題：

當(dāng)源端 Binlog 消息積壓太多，一次往 Kafka 發(fā)送過大消息，導(dǎo)致 Kafka oom。

當(dāng) Pump 高速大批寫入 Kafka 的時(shí)候，發(fā)現(xiàn) Drainer 不工作，無法讀取 Kafka 數(shù)據(jù)。

和 PingCAP 工程師一起排查，最終發(fā)現(xiàn)這是屬于 sarama 本身的一個(gè) bug，sarama 對(duì)數(shù)據(jù)寫入沒有閾值限制，但是讀取卻設(shè)置了閾值：https://github.com/Shopify/sarama/blob/master/real_decoder.go#L88。

最后的解決方案是給 Pump 和 Drainer 增加參數(shù) Kafka-max-message 來限制消息大小。單機(jī)部署多 TiDB 實(shí)例，不支持多 Pump，也通過更新 ansible 腳本得到了解決，將 Pump.service 以及和 TiDB 的對(duì)應(yīng)關(guān)系改成 Pump-8250.service，以端口區(qū)分。

針對(duì)以上問題，PingCAP 公司對(duì) TiDB-Binlog 進(jìn)行了重構(gòu)，新版本的 TiDB-Binlog 不再使用 Kafka 存儲(chǔ) binlog。Pump 以及 Drainer 的功能也有所調(diào)整，Pump 形成一個(gè)集群，可以水平擴(kuò)容來均勻承擔(dān)業(yè)務(wù)壓力。另外，原 Drainer 的 binlog 排序邏輯移到 Pump 來做，以此來提高整體的同步性能。

4.1.3 監(jiān)控問題

當(dāng)前的 TiDB 監(jiān)控架構(gòu)中，TiKV 依賴 Pushgateway 拉取監(jiān)控?cái)?shù)據(jù)到 Prometheus，當(dāng) TiKV 實(shí)例數(shù)量越來越多，達(dá)到 Pushgateway 的內(nèi)存限制 2GB 進(jìn)程會(huì)進(jìn)入假死狀態(tài)，Grafana 監(jiān)控就會(huì)變成圖 7 的斷點(diǎn)樣子：

目前臨時(shí)處理方案是部署多套 Pushgateway，將 TiKV 的監(jiān)控信息指向不同的 Pushgateway 節(jié)點(diǎn)來分擔(dān)流量。這個(gè)問題的最終還是要用 TiDB 的新版本（2.1.3 以上的版本已經(jīng)支持），Prometheus 能夠直接拉取 TiKV 的監(jiān)控信息，取消對(duì) Pushgateway 的依賴。

下面簡(jiǎn)單介紹一下摩拜單車自研的數(shù)據(jù)復(fù)制組件 Gravity（DRC）。

Gravity 是摩拜單車數(shù)據(jù)庫(kù)團(tuán)隊(duì)自研的一套數(shù)據(jù)復(fù)制組件，目前已經(jīng)穩(wěn)定支撐了公司數(shù)百條同步通道，TPS 50000/s，80 線延遲小于 50ms，具有如下特點(diǎn)：

多數(shù)據(jù)源（MySQL, MongoDB, TiDB, PostgreSQL）。

支持異構(gòu)（不同的庫(kù)、表、字段之間同步），支持分庫(kù)分表到合表的同步。

支持雙活&多活，復(fù)制過程將流量打標(biāo)，避免循環(huán)復(fù)制。

管理節(jié)點(diǎn)高可用，故障恢復(fù)不會(huì)丟失數(shù)據(jù)。

支持 filter plugin（語句過濾，類型過濾，column 過濾等多維度的過濾）。

支持傳輸過程進(jìn)行數(shù)據(jù)轉(zhuǎn)換。

一鍵全量 + 增量遷移數(shù)據(jù)。

輕量級(jí)，穩(wěn)定高效，容易部署。

支持基于 Kubernetes 的 PaaS 平臺(tái)，簡(jiǎn)化運(yùn)維任務(wù)。

使用場(chǎng)景：

大數(shù)據(jù)總線：發(fā)送 MySQL Binlog，Mongo Oplog，TiDB Binlog 的增量數(shù)據(jù)到 Kafka 供下游消費(fèi)。

單向數(shù)據(jù)同步：MySQL → MySQL&TiDB 的全量、增量同步。

雙向數(shù)據(jù)同步：MySQL ? MySQL 的雙向增量同步，同步過程中可以防止循環(huán)復(fù)制。

分庫(kù)分表到合庫(kù)的同步：MySQL 分庫(kù)分表 → 合庫(kù)的同步，可以指定源表和目標(biāo)表的對(duì)應(yīng)關(guān)系。

數(shù)據(jù)清洗：同步過程中，可通過 filter plugin 將數(shù)據(jù)自定義轉(zhuǎn)換。

數(shù)據(jù)歸檔：MySQL→ 歸檔庫(kù)，同步鏈路中過濾掉 delete 語句。

Gravity 的設(shè)計(jì)初衷是要將多種數(shù)據(jù)源聯(lián)合到一起，互相打通，讓業(yè)務(wù)設(shè)計(jì)上更靈活，數(shù)據(jù)復(fù)制、數(shù)據(jù)轉(zhuǎn)換變的更容易，能夠幫助大家更容易的將業(yè)務(wù)平滑遷移到 TiDB 上面。該項(xiàng)目 已經(jīng)在 GitHub 開源，歡迎大家交流使用。

TiDB 的出現(xiàn)，不僅彌補(bǔ)了 MySQL 單機(jī)容量上限、傳統(tǒng) Sharding 方案查詢維度單一等缺點(diǎn)，而且其計(jì)算存儲(chǔ)分離的架構(gòu)設(shè)計(jì)讓集群水平擴(kuò)展變得更容易。業(yè)務(wù)可以更專注于研發(fā)而不必?fù)?dān)心復(fù)雜的維護(hù)成本。未來，摩拜單車還會(huì)繼續(xù)嘗試將更多的核心業(yè)務(wù)遷移到 TiDB 上，讓 TiDB 發(fā)揮更大價(jià)值，也祝愿 TiDB 發(fā)展的越來越好。