摘要：本文作者是矛盾螺旋隊的成員劉瑋，他們的項目在中獲得了三等獎。博康負責后端框架以及相應的修改，我負責后端查詢，振靖負責前端可視化。次日返回賽場，抽簽確定時間，最終為第四個出場。

本文作者是矛盾螺旋隊的成員劉瑋，他們的項目?TiEye?在 TiDB Hackathon 2018 中獲得了三等獎。TiEye 是?Region 信息變遷歷史可視化工具，通過 PD記錄 Region 的Split、Merge、ConfChange、LeaderChange 等信息，可以方便的回溯 Region 某個時間的具體狀態(tài)，為開發(fā)人員提供了方便的可視化展示界面及查詢功能。

Region 是 TiKV 的一個數(shù)據(jù)調度單元，TiKV 將數(shù)據(jù)按照鍵值范圍劃分為很多個 Region，分在集群的多臺機器上，通過調度 Region 來實現(xiàn)負載均衡以及數(shù)據(jù)存儲的擴展，同時一個 Region 也是一個 Raft Group，一個 Region 分布在多個 TiKV 實例上（通常是 3 個或者 5 個），通過 Raft 算法保證多副本的強一致性。

這個項目的靈感是之前在查一些問題的時候想到的，因為我們很多時候需要去知道 Region 在某個時間的狀態(tài)，這就需要通過日志從雜亂的信息中提取出來有用的信息來復原當時的場景，但實際并不是特別方便高效，尤其是在看多個 Region 之間的關系的時候。因此通過將 Region 信息變化歷史可視化，希望能為開發(fā)者們在定位問題的時候提供一個方便直觀的工具，同時還能通過它來分析 PD 的調度策略，以及調度帶來的寫放大問題等等。

一開始我們考慮的是通過一個獨立的服務去解析 PD 的日志來獲取 Region 信息的變化歷史，后來討論后認為這樣做不僅依賴于 PD 中的日志格式，造成系統(tǒng)耦合，同時 PD 的 leader 變遷導致日志內容不連續(xù)，以及日志中的信息并不是特別充分等問題也增加了開發(fā)難度。因此我們最后決定直接修改 PD 的源代碼，在每次 PD 變更 Region 的時候，記錄下這些信息并持久化。這樣既能保證在 PD 切換 leader 后的變化信息的連續(xù)性，又提供了更加豐富的歷史信息。同時，PD 添加相關的 API，以供前端進行查詢。

我們的團隊由三個人組成，分別是我（劉瑋）、周振靖和張博康，都畢業(yè)于北京郵電大學。我們在這次 Hackathon 之前就認識，因為大家都在北京，因此交流還是蠻方便的，在開賽大約一周前就確定了這個題目。其實我最初的想法是做一些有關于性能優(yōu)化的事情，但是在跟隊友們交流后還是決定做 Region 歷史可視化，其更具有實用性，也更適合在 Hackathon 上來做。

10:00 比賽正式開始。我們之前已經(jīng)討論好了項目的大體架構，因此沒有再做過多的討論就各自開始碼代碼了。博康負責后端框架以及 PD 相應的修改，我負責后端查詢 API，振靖負責前端可視化。

12:15 午餐。休息片刻，繼續(xù)碼代碼。

14:00 后端框架大體完成，已經(jīng)可以在 PD 中收集 Region 相應的狀態(tài)變化；前端部分已經(jīng)畫出簡單的 Region 分裂、合并等示意圖。

17:30 完成了最簡單的查詢邏輯，進行了第一次聯(lián)調，發(fā)現(xiàn)大家對于 Region 狀態(tài)的展示方式理解不一樣，于是再次討論統(tǒng)一了意見。

18:00 晚餐時間。

19:00 ~ 次日 2:30: 我們基本完成了后端開發(fā)，而前端這時還剩比較多的工作量。同時晚上在前端展示，后端查詢 API，數(shù)據(jù)持久化方面都發(fā)現(xiàn)了幾個 bug，大家一直忙到很晚才一一解決。

次日 9:00 返回賽場，抽簽確定 Demo 時間，最終為第四個出場。

次日 12:00 前端可視化基本完善，為界面做最后的調整。

次日 12:00 ~ 12:30 午餐時間

次日 13:00 ~ 14:00 準備 PPT 和展示錄屏

次日 14:30 ~ 18:30 Demo Time（B 站直播）

我們采取了前后端分離的架構。

前端是 Vue.js 框架，使用 Typescript 語言開發(fā)。由于看上去現(xiàn)有的圖表庫啥的并不能很好地滿足我們的需求，所以前端同學決定手擼 SVG。

后端則是 PD 提供的 API。數(shù)據(jù)存儲目前暫時存儲在 etcd，將來會考慮其它方案來應對數(shù)據(jù)規(guī)模太大的情況。我們將 Region 的變化分成了以下四種：

LeaderChange：Raft Group 選舉（或者是主動移交）了新的 leader

ConfChange：Raft Group 成員變更

Split：當某個 Region 數(shù)據(jù)超過一定闕值時（或被手動干預時）會分裂成鍵值范圍相鄰的兩個 Region

Merge：兩個鍵值范圍連續(xù)的 Region 合并成一個

Bootstrap：一個新的集群中第一個 Region 產生

在前端的表示方式如圖所示：

給 PD 添加的 API 則有如下幾種：

/pd/api/v1/history/list，GET 方法，返回全部歷史。

返回結果:

[
 ? {
 ? ? ? "timestamp":1544286220000000,
 ? ? ? "leader_store_id":0,
 ? ? ? "event_type":"Bootstrap",
 ? ? ? "Region":{
 ? ? ? ? ? "id":2,
 ? ? ? ? ? "start_key":"",
 ? ? ? ? ? "end_key":"",
 ? ? ? ? ? "Region_epoch":{
 ? ? ? ? ? ? ? "conf_ver":1,
 ? ? ? ? ? ? ? "version":1
 ? ? ? ? ? },

 ? ? ? ? ? "peers":[
 ? ? ? ? ? ? ? {
 ? ? ? ? ? ? ? ? ? "id":3,
 ? ? ? ? ? ? ? ? ? "store_id":1
 ? ? ? ? ? ? ? }
 ? ? ? ? ? ]
 ? ? ? },
 ? ? ? "parents":[],
 ? ? ? "children":26
 ? },
 ? ...
]

/pd/api/v1/history/Region/{RegionId}，GET 方法，查詢某個 Region 的變化歷史，返回結果同上。

/pd/api/v1/history/key/{key}，GET 方法，查詢某個 key 所屬 Region 的變化歷史，返回結果同上。

以上幾個 API 均可附加起止時間參數(shù)（時間戳），如：

/pd/api/v1/history/list?start=0&end=1544286229000000

順便一提，前端部分原先打算作為 PD 的一部分來提供，與 PD 一起構建（于是前端的代碼也放進了 PD 的一個多帶帶的文件夾里）。但是后來覺得對于不涉及這些前端代碼的開發(fā)者來說這樣做不太好，所以我們之后會抽時間將這些前端代碼放進一個多帶帶的倉庫里。

測試過程

測試的時候我們部署了1個 TiDB，6個 TiKV，3個 PD，通過 sysbench 導入少量數(shù)據(jù)，最后通過開啟 random-merge-scheduler 來進行隨機合并 Region。下圖是我們的測試過程中的結果展示：

此時通過我們的工具還意外發(fā)現(xiàn)了一個 bug。

可以在上圖看到，在第一個紅框處 Region 2 合并進 Region 28，然后第二紅框那里已經(jīng)被 merge 進 Region 28 的 Region 2 莫名其妙地又連接了后面的 Region 40，顯然這里是有問題的。經(jīng)過通過日志確認，這是由于 PD 收到了一個含有過期 Region 2 信息的心跳導致的，追根溯源發(fā)現(xiàn)是 TiKV 中的 pd-client 的一個 Bug 導致了在與 PD 重連后會發(fā)送一個過期的心跳信息（Bug 地址在 https://github.com/tikv/tikv/...）。

實際運行結果

橫軸表示時間，縱軸表示 Region 的存儲鍵值的順序（僅表示順序，不代表實際的數(shù)據(jù)量），矩形上的數(shù)字表示 Region id，為了便于理解，所有的 Region 的最終狀態(tài)都會在最后的時間點上展示出來（即使在這個時間點沒有發(fā)生 Region 的改變）。

點擊右上角可以更改查下的時間范圍。

右上角可以設置按照 key 的范圍對齊，效果如下圖：

點擊任何一個節(jié)點，會展示當時 Region 的詳細信息。

拖動下方的框可以對局部進行縮放（你也可以通過查詢更小的時間范圍達到同樣的效果）。

我們團隊的 Demo 展示是博康負責的。一開始他還擔心如果演講的時候忘詞了怎么辦，不過最后展示效果很不錯，整個 Demo show 進行得非常順利（P.S. 要是展示時間能多給幾分鐘就好了）。

在展示中，我們也看見了其他團隊的作品也都非常棒。這其中讓我最感興趣的是有個團隊做的是以 TiKV 作為數(shù)據(jù)存儲的 etcd。這個選題一開始我也考慮過，因為我在工作中實際已經(jīng)遇到了這個問題，不過最后和隊友商量后還是選擇了現(xiàn)在這個題目。

我們“矛盾螺旋”團隊最終獲得了三等獎，這對我來說簡直是意外之喜。在演示中，很多別的團隊也都做得十分優(yōu)秀，我們在觀看其它團隊的演示時幾乎都覺得獲獎無望了。最后卻拿到了三等獎，實在是意料之外。這次我們之所以能夠獲獎，一方面是選題選得恰到好處，具有一定的實際作用，同時工作量又能保證在 Hackathon 期間完成。

最后感謝我的兩位隊友，謝謝導師，謝謝評委老師，謝謝 PingCAP 的所有工作人員為這次 Hackathon 所做的努力。

視頻 | TiDB Hackathon 2018（上半場）

（