摘要：本文由紅鳳凰粉鳳凰粉紅鳳凰隊(duì)的成員主筆，他們的項(xiàng)目在本屆中獲得了二等獎(jiǎng)。用戶在平臺(tái)上進(jìn)行第一章部署的學(xué)習(xí)，了解到可以通過進(jìn)行部署。收到事件后，更新。由于位置是由屬性給出的，因此為其加上，即可實(shí)

本文由紅鳳凰粉鳳凰粉紅鳳凰隊(duì)的成員主筆，他們的項(xiàng)目 TiDB Lab?在本屆 TiDB Hackathon 2018 中獲得了二等獎(jiǎng)。TiDB Lab 為 TiDB 培訓(xùn)體系增加了一個(gè)可以動(dòng)態(tài)觀測 TiDB / TiKV / PD 細(xì)節(jié)的動(dòng)畫教學(xué) Lab，讓用戶可以一邊進(jìn)行真實(shí)操作一邊觀察組件之間的變化，例如 SQL 的解析，Region 的變更等等，從而生動(dòng)地理解 TiDB 的工作原理。

TiDB Lab，全稱 TiDB Laboratory，是一個(gè)集 TiDB 集群狀態(tài)的在線實(shí)時(shí)可視化與交互式教學(xué)的平臺(tái)。用戶可以一邊對 TiDB 集群各個(gè)組件 TiKV、TiDB、PD 進(jìn)行各種操作，包括上下線、啟動(dòng)關(guān)閉、遷移數(shù)據(jù)、插入查詢數(shù)據(jù)等，一邊在 TiDB Lab 上以動(dòng)畫形式觀察操作對集群的影響，例如數(shù)據(jù)是怎么流動(dòng)的，Region 副本在什么情況下發(fā)生了變更等等。通過 TiDB Lab 這種對操作進(jìn)行可視化反饋的交互模式，用戶可以快速且生動(dòng)地理解 TiDB 內(nèi)部原理。

實(shí)時(shí)動(dòng)態(tài)展示 TiDB、TiKV 節(jié)點(diǎn)的新增、啟動(dòng)與關(guān)閉。

實(shí)時(shí)動(dòng)態(tài)展示 TiDB 收到 SQL 后，物理算子將具體請求發(fā)送給某些 TiKV Region Leader 并獲取數(shù)據(jù)的過程。

實(shí)時(shí)動(dòng)態(tài)展示各個(gè) TiKV 實(shí)例上 Region 副本狀態(tài)的變化，例如新增、刪除、分裂。

實(shí)時(shí)動(dòng)態(tài)展示各個(gè) TiKV 實(shí)例上 Region 副本內(nèi)的數(shù)據(jù)量情況。

瀏覽集群事件歷史（事件指上述四條功能所展示的各項(xiàng)內(nèi)容）并查看事件的詳細(xì)情況，包括事件的具體數(shù)據(jù)內(nèi)容、SQL Plan 等等。

按 TiDB、TiKV 或 Region 過濾事件歷史。

對事件歷史進(jìn)行時(shí)間穿梭：回到任意事件發(fā)生時(shí)刻重新觀察當(dāng)時(shí)的集群狀態(tài)，或按事件單步重放觀察集群狀態(tài)的變化。

在線獲取常用運(yùn)維操作的操作指南。

我們其實(shí)為 TiDB Lab 規(guī)劃了更大的愿景，但由于 Hackathon 時(shí)間關(guān)系，還來不及實(shí)現(xiàn)。我們希望能實(shí)現(xiàn) TiDB Lab + TiDB 生態(tài)組件的沙盒，從而在 TiDB Lab 在線平臺(tái)上直接提供命令執(zhí)行與 SQL 執(zhí)行功能。這樣用戶無需離開平臺(tái)，無需自行準(zhǔn)備機(jī)器下載部署，就可以直接在平臺(tái)上根據(jù)提供的操作指南進(jìn)行各類操作，并能觀察操作帶來的具體影響，形成操作與反饋的閉環(huán)，真正地實(shí)現(xiàn)零門檻瀏覽器在線教學(xué)。我們期望平臺(tái)能提供用戶以下的操作流程：

1. 用戶獲得一個(gè) TiDB Lab 賬戶并登錄（考慮到沙盒是占用實(shí)際資源的，需要通過賬戶許可來限制避免資源快速耗盡）。

2. 用戶在 TiDB Lab 上獲得若干虛擬機(jī)器的訪問權(quán)限，每個(gè)機(jī)器處于同一內(nèi)網(wǎng)并具有獨(dú)立 IP。這些虛擬機(jī)器的實(shí)際實(shí)現(xiàn)是資源受限的虛擬機(jī)或沙盒，因?yàn)樽鳛榻虒W(xué)實(shí)驗(yàn)不需要占用很多資源。

例如：平臺(tái)為用戶自動(dòng)分配了 5 個(gè) IP 獨(dú)立的沙盒的訪問權(quán)限，地址為 192.168.0.1 ~ 192.168.0.5。

3. 用戶在平臺(tái)上進(jìn)行第零章「架構(gòu)原理」的學(xué)習(xí)。平臺(tái)提供了一個(gè)默認(rèn)的拓?fù)洳渴?，用戶可以在平臺(tái)提供的在線 SQL Shell 中進(jìn)行數(shù)據(jù)的插入、刪除、更新等操作。用戶通過平臺(tái)觀察到 SQL 是如何對應(yīng)到 TiKV 存儲(chǔ)節(jié)點(diǎn)上的，以及數(shù)據(jù)是怎么切分到不同 Region 的等等。

4. 用戶在平臺(tái)上進(jìn)行第一章「TiDB 部署」的學(xué)習(xí)，了解到可以通過 ansible 進(jìn)行部署。教學(xué)樣例是一個(gè)典型的 TiDB + TiKV 三副本部署。對于這個(gè)教學(xué)樣例，平臺(tái)告知用戶 inventory.ini 具體內(nèi)容應(yīng)當(dāng)寫成什么樣子。用戶可以在平臺(tái)提供的在線 Terminal 上修改 inventory 文件，并執(zhí)行部署與集群啟動(dòng)命令。部署和啟動(dòng)均能在平臺(tái)上實(shí)時(shí)反饋可視化。

5. 用戶繼續(xù)進(jìn)行后續(xù)章節(jié)學(xué)習(xí)，例如「TiDB 單一服務(wù)啟動(dòng)與關(guān)閉」。用戶在可視化界面上點(diǎn)擊某個(gè)剛才已經(jīng)部署出來的節(jié)點(diǎn)，可以了解啟動(dòng)或關(guān)閉單個(gè) TiDB 的命令。用戶可以在平臺(tái)提供的在線 Terminal 上執(zhí)行這些命令，嘗試啟動(dòng)或關(guān)閉單一 TiDB。

6. 用戶繼續(xù)學(xué)習(xí)基礎(chǔ)運(yùn)維操作，例如「TiKV 擴(kuò)容」。平臺(tái)告知 inventory.ini 應(yīng)當(dāng)如何進(jìn)行修改，用戶可以根據(jù)指南在在線 Terminal 上進(jìn)行實(shí)踐，并通過可視化界面觀察擴(kuò)容的過程，例如其他節(jié)點(diǎn)上的副本被逐漸搬遷到新節(jié)點(diǎn)上。

我們團(tuán)隊(duì)有三個(gè)人，是一個(gè) PingCAP 同學(xué)與 TiDB 社區(qū)小伙伴錢同學(xué)的混合組隊(duì)，其中 PingCAP 成員分別來自 TiKV 組與 OLAP 組。我們本著搞事情的想法，團(tuán)隊(duì)取名叫「紅鳳凰粉鳳凰粉紅鳳凰」，想圍觀主持人念團(tuán)隊(duì)名稱（然而機(jī)智的主持人小姐姐讓我們自報(bào)團(tuán)隊(duì)名稱）。

鑒于從報(bào)名開始直到 Hackathon 正式開始前幾小時(shí)，我們都在為原計(jì)劃做準(zhǔn)備，因此值得詳細(xì)說一下…

我們一開始規(guī)劃的 Hackathon 項(xiàng)目是換掉 TiKV、TiDB 之間的 RPC 框架 gRPC，原因有幾個(gè)：

一是發(fā)現(xiàn) TiKV、TiDB 中 gRPC 經(jīng)常占用了大量 CPU，尤其是在請求較多但很簡單的 benchmark 場景中經(jīng)常比 Coprocessor 這塊兒還高，這在客戶機(jī)器 CPU 資源比較少的情況下是性能瓶頸；

二是發(fā)現(xiàn) gRPC 性能一般，在各類常用 RPC 框架的性能測試中 gRPC 經(jīng)常是墊底水平；

三是 gRPC 主要設(shè)計(jì)用于用戶產(chǎn)品與 Google 服務(wù)進(jìn)行通訊，因而考慮到了包括負(fù)載均衡友好、流量控制等方面，但對 TiKV 與 TiDB 這類內(nèi)部通訊來說這些都是用不上的功能，為此犧牲的性能是無謂的開銷；

另外近期 TiKV 內(nèi)部有一個(gè)實(shí)驗(yàn)是將多個(gè) RPC 請求 batch 到一起再發(fā)送（當(dāng)然處理時(shí)候再拆開一個(gè)一個(gè)執(zhí)行原來的 handler），性能可以瞬間提高一倍以上，這也從側(cè)面說明了 gRPC 框架自身開銷很大，因?yàn)橛脩魝?cè)請求總量是一致的，處理模式也是一致的，唯一的區(qū)別就是 RPC 框架批量發(fā)送或一條一條發(fā)送。

我們早在幾周前就開始寫簡單 Echo Server 進(jìn)行可行性驗(yàn)證和性能測試，是以下三個(gè)方面的正交：

1. 協(xié)議：CapnProto RPC、brpc over gRPC、裸寫 echo。

2. 服務(wù)端：Rust、C++，對應(yīng)用于 TiKV。

3. 客戶端：Golang，對應(yīng)用于 TiDB。

其中 TiKV 側(cè)調(diào)研了 Rust 和 C++ 的服務(wù)端實(shí)現(xiàn)，原因是 Rust 可以通過 binding 方式調(diào)用 C++ 服務(wù)端。而 TiDB 側(cè)客戶端實(shí)現(xiàn)不包含 C++ 的原因是 Golang 進(jìn)行 C / C++ FFI 性能很差，因此可以直接放棄 C/C++ 包裝一層 binding 用于 TiDB 的想法。最后測試下來，有以下結(jié)果：

CapnProto：序列化性能很高，但其 RPC 性能沒有很突出。最重要的是，CapnProto 的 Golang Client 實(shí)現(xiàn)有 bug，并不能穩(wěn)定地與 Rust 或 C++ 的 Server 進(jìn)行 RPC 交互。作者回復(fù)說這是一個(gè)已知缺陷，涉及重構(gòu)。這對于 Hackathon 來說是一個(gè)致命的問題，我們并沒有充足的時(shí)間解決這個(gè)問題，直接導(dǎo)致我們放棄這個(gè)方案。

brpc over gRPC：可以實(shí)現(xiàn)使用 brpc C++ 客戶端 & gRPC Golang 服務(wù)端配合（注：brpc 沒有 Golang 的實(shí)現(xiàn)）。但這個(gè)方案本質(zhì)只是替換服務(wù)端的實(shí)現(xiàn)，并沒有替換協(xié)議，并不徹底，我們不是特別喜歡。另外在這個(gè)換湯不換藥的方案下，測試下來性能的提升有限，且隨著 payload 越大會(huì)越小。我們最終覺得作為一個(gè) Hackathon 項(xiàng)目如果僅有有限的性能提升（雖然可以在展示的時(shí)候掩蓋缺陷只展示優(yōu)點(diǎn)），那么意義不是很大，最終無法用于產(chǎn)品，因而放棄。

裸寫：我們?nèi)齻€(gè)成員都不是這方面的老司機(jī)，裸寫大概是寫不完的。。

在 Hackathon 開始的前一個(gè)晚上，我們決定推翻重來，于是 brain storm 了幾個(gè)想法，最后覺得做一個(gè)用于教學(xué)的可視化比較可行，并且具有比較大的實(shí)際意義。另外，這個(gè)新項(xiàng)目「集群可視化」相比原項(xiàng)目「換 RPC」來說更適合 Hackathon，主要在于：

1. 具有圖形化界面，容易拿獎(jiǎng)可以直觀地展現(xiàn)成果。

2. 并不是一個(gè)「非零即一」的任務(wù)。新項(xiàng)目有很多子功能，可以逐一進(jìn)行實(shí)現(xiàn)，很穩(wěn)妥，且不像老項(xiàng)目那樣只有換完才知道效果。

我們繼續(xù)在這個(gè)「可視化」的想法上進(jìn)行了進(jìn)一步的思考，想到如果可以做成在線教學(xué)的模式，則可以進(jìn)一步擴(kuò)展其項(xiàng)目意義，形成一個(gè)完整的在線教學(xué)體系，因此最終決定了項(xiàng)目的 scope。

在 TiKV、TiDB 與 PD 中各個(gè)關(guān)鍵路徑上將發(fā)生的具體「事件」記錄下來，并在前端進(jìn)行一一可視化。

我們將 TiDB Lab 進(jìn)行可視化所需要的信號(hào)稱為「事件」，并規(guī)劃了以下「事件」：

Ansible 事件：Ansible 部署 TiDB

Ansible 事件：Ansible 部署 TiKV

TiDB 事件：TiDB 啟動(dòng)

TiDB 事件：TiDB 關(guān)閉

TiDB 事件：TiDB 收到一條 SQL

TiKV 事件：TiKV 啟動(dòng)

TiKV 事件：TiKV 關(guān)閉

TiKV 事件：TiKV 收到一條 KvGet 請求

TiKV 事件：TiKV 收到一條 PreWrite / Commit 請求

TiKV 事件：TiKV 收到一條 Coprocessor 請求

TiKV 事件：TiKV Region Peer 創(chuàng)建

TiKV 事件：TiKV Region Peer 刪除

TiKV 事件：TiKV Region 分裂

TiKV 事件：TiKV Region Snapshot 復(fù)制

TiKV 事件：TiKV Region 數(shù)據(jù)量發(fā)生顯著變化

最后，由于時(shí)間關(guān)系、技術(shù)難度和可視化需要，實(shí)際實(shí)現(xiàn)的是以下事件：

TiDB 事件：TiDB 啟動(dòng)，若首次啟動(dòng)認(rèn)為是新部署

TiDB 事件：TiDB 關(guān)閉

TiDB 事件：TiDB 收到 SQL 并發(fā)起 KvGet 讀請求

TiDB 事件：TiDB 收到 SQL 并發(fā)起 PreWrite / Commit 寫入請求

TiDB 事件：TiDB 收到 SQL 并發(fā)起 Coprocessor 讀請求

TiKV 事件：TiKV 啟動(dòng)，若首次啟動(dòng)認(rèn)為是新部署

TiKV 事件：TiKV 關(guān)閉

PD 事件：TiKV Region Peer 創(chuàng)建（通過 Region 心跳實(shí)現(xiàn)）

PD 事件：TiKV Region Peer 刪除（通過 Region 心跳實(shí)現(xiàn)）

PD 事件：TiKV Region 分裂（通過 Region 心跳實(shí)現(xiàn)）

PD 事件：TiKV Region 數(shù)據(jù)量發(fā)生顯著變化（通過 Region 心跳實(shí)現(xiàn)）

可視化部分由前端（lab-frontend）和事件收集服務(wù)（lab-gateway）組成。

事件收集服務(wù)是一個(gè)簡單的 HTTP Server，各個(gè)組件通過 HTTP Post 方式告知事件，事件收集服務(wù)將其通過 WebSocket 協(xié)議實(shí)時(shí)發(fā)送給前端。事件收集服務(wù)非常簡單，使用的是 Node.js 開發(fā)，基于 ExpressJs 啟動(dòng) HTTP Server 并基于 SocketIO 實(shí)現(xiàn)與瀏覽器的實(shí)時(shí)通訊。ExpressJs 收到事件 JSON 后將其通過 SocketIO 進(jìn)行廣播，總代碼僅僅十幾行。

可視化前端采用 Vue 實(shí)現(xiàn)，動(dòng)畫使用 animejs 和 CSS3。

通過模板實(shí)現(xiàn)的可視化

一部分事件通過「由事件更新集群狀態(tài)數(shù)據(jù) – 由集群狀態(tài)通過 Vue 渲染模板」進(jìn)行可視化。

這類可視化是最簡單的，以 TiDB 啟動(dòng)與否為例，TiDB 的啟動(dòng)與否在界面上呈現(xiàn)為一個(gè)標(biāo)簽顯示為「Started」或「Stopped」，那么就是一個(gè)傳統(tǒng)的 Vue MVVM 流程：

1. 數(shù)據(jù)變量 instances.x.online 代表 TiDB x 是否已啟動(dòng)。

2. 收到 TiDB Started 事件后，更新 instances.x.online = true 。

3. 收到 TiDB Stopped 事件后，更新 instances.x.online = false 。

4. 前端模板上，根據(jù) instances.x.online 渲染成 Started 或 Stopped 對應(yīng)的界面。

這類可視化的動(dòng)畫采用的是 CSS3 動(dòng)畫。由于 Region Peer 位置是由 left, top CSS 屬性給出的，因此為其加上 transition，即可實(shí)現(xiàn) Region Peer 在屏幕上顯示的位置改變的動(dòng)畫。位置改變會(huì)主要發(fā)生在分裂時(shí)，分裂時(shí) Region 列表中按順序會(huì)新增一個(gè)，那么后面各個(gè) Region 都要向后移動(dòng)（或換到下一行等）。

最后，使用 Vue Group Transition 功能，即可為 Region Peer 的新增與刪除也加入動(dòng)畫效果。

通過動(dòng)畫實(shí)現(xiàn)的可視化

另一部分事件并不反應(yīng)為一個(gè)持久化 DOM 的變化，例如 TiDB 收到 SQL 并發(fā)請求到某個(gè)具體 TiKV 上 Region peer 的事件，在前端展示為一個(gè) TiDB 節(jié)點(diǎn)到 TiKV Region Peer 的過渡動(dòng)畫。動(dòng)畫開始前和動(dòng)畫結(jié)束后，DOM 沒有什么變化，動(dòng)畫是一個(gè)臨時(shí)的可視元素。這類動(dòng)畫通過 animejs 實(shí)現(xiàn)。

時(shí)間穿梭

時(shí)間穿梭是一個(gè)在目前前端框架中提供的很時(shí)髦的功能，我們準(zhǔn)備借鑒一波。主要包括：1. 回退到任意一個(gè)歷史事件發(fā)生的時(shí)刻展示集群的狀態(tài)；2. 從當(dāng)前事件開始往后進(jìn)行單步可視化重現(xiàn)。

時(shí)間穿梭的本質(zhì)是需要實(shí)現(xiàn)兩個(gè)基礎(chǔ)操作：

1. 對于單一事件實(shí)現(xiàn)正向執(zhí)行，即事件發(fā)生后，更新對應(yīng)集群數(shù)據(jù)信息（如果采用「通過模板實(shí)現(xiàn)的可視化」），或創(chuàng)建臨時(shí)動(dòng)畫 DOM（如果采用「通過動(dòng)畫實(shí)現(xiàn)的可視化」）。另外允許跳過「通過動(dòng)畫實(shí)現(xiàn)的可視化」這一步。

2. 對于單一事件實(shí)現(xiàn)反向執(zhí)行，即撤銷這個(gè)事件造成的影響。對于「通過模板實(shí)現(xiàn)的可視化」，我們需要根據(jù)事件內(nèi)容反向撤銷它對集群數(shù)據(jù)信息的修改。對于「通過動(dòng)畫實(shí)現(xiàn)的可視化」，我們什么都不用做。

時(shí)間穿梭的功能可以通過組合這兩個(gè)基礎(chǔ)操作實(shí)現(xiàn)。

1. 回退到任意歷史事件發(fā)生時(shí)刻：若想要前往的事件早于當(dāng)前呈現(xiàn)的事件，則對于這期間的事件逐一進(jìn)行反向執(zhí)行。若想要前往的事件晚于當(dāng)前呈現(xiàn)的事件，則進(jìn)行無動(dòng)畫的正向執(zhí)行。

2. 從當(dāng)前事件開始單步可視化：執(zhí)行一次有動(dòng)畫的正向執(zhí)行。

3. 實(shí)時(shí)展示新事件：執(zhí)行一次有動(dòng)畫的正向執(zhí)行。

TiDB 的歷史事件收集略為 Hack。由于需要過濾任何非用戶發(fā)起的查詢（類似 GC 或者 meta 查詢會(huì)由背景協(xié)程頻繁發(fā)起打擾使用體驗(yàn)），因此在用戶鏈接入口處添加了 context 標(biāo)記一路攜帶到執(zhí)行層，再修改相應(yīng)的協(xié)程同步數(shù)據(jù)結(jié)構(gòu)添加需要轉(zhuǎn)發(fā)的標(biāo)記信息。比較麻煩的是類似 Point Get 這樣接口允許攜帶信息非常少的調(diào)用，只好將標(biāo)記位編碼進(jìn) Key 本身了。Plan 的可視化其實(shí)并沒有花多少功夫，因?yàn)檎业?TiDB 本身已經(jīng)做了類似的功能，我們無非只是將這塊代碼直接偷來了。

原本不少事件希望在 TiKV 端完成偵聽，不過顯然 KV 一小時(shí)編譯一次的效率無法滿足 Hackathon 中多次試錯(cuò)的需要。因此我們改為在 PD 中偵測心跳和匯報(bào)事件。其實(shí)并沒有什么神秘，在原本 PD 自己檢查 Region 變更的代碼拆分成 Region 和 Peer 變更：每次 PD 接到 Region 心跳會(huì)在 PD Cache 中進(jìn)行 Version 和 confVer 變更的檢測，主要涉及 Peer 的增加和減少等。而 Region Split 會(huì)多帶帶由 RegionSplitReport 進(jìn)行匯報(bào)，這里也會(huì)做一次 Hook。另外就是每次心跳會(huì)檢查是否有未上報(bào)給 Lab 的 Region 信息，如果有就轉(zhuǎn)換成 Peer 信息進(jìn)行補(bǔ)發(fā)。

如上，原本我們計(jì)劃了很多 TiKV 事件，但由于開發(fā)機(jī)器配置不佳，每次修改都要等待一小時(shí)進(jìn)行一次編譯，考慮到 Hackathon 上時(shí)間緊迫，因此最終大大縮減了 TiKV 上收集的事件數(shù)量，改為只收集啟動(dòng)和停止?；炯軜?gòu)是事件發(fā)生的時(shí)候，事件異步發(fā)送給一個(gè) Channel，Channel 的另一端有一個(gè)異步的 worker 負(fù)責(zé)不斷處理各個(gè)事件并通過 Hyper HTTP Client 發(fā)送出去。這個(gè)流程其實(shí)與 TiKV 中匯報(bào) PD 事件有些類似，只是事件內(nèi)容和匯報(bào)目標(biāo)不一樣。

以下文字 by 馬曉宇 @ OLAP Team, PingCAP
“由于比較能調(diào)侃干的活相對少一些，所以大王要我來巡山寫感悟?！?/pre>
就像隊(duì)長說的，這個(gè)項(xiàng)目原本是希望做一個(gè) bRPC 替換 gRPC 的試驗(yàn)，只是由于種種原因臨到 Hackathon 前夜我們才確定這是個(gè)大概率翻車的點(diǎn)子。于是乎我們只好在酒店里抓耳撓腮，一邊討論可能的補(bǔ)救措施。
參加過、圍觀過幾次 Hackathon，見過現(xiàn)場 Demo 效果最震撼的一次其實(shí)并不是一個(gè)技術(shù)上最優(yōu)秀的作品，但是它的確贏得了大獎(jiǎng)。那是一個(gè)腦洞奇大的點(diǎn)子：用 Kinect 體感加上 DirectX 的全 3D 展示做的網(wǎng)絡(luò)流量實(shí)時(shí)展示；程序根據(jù)實(shí)時(shí)數(shù)據(jù)（舉辦方提供了實(shí)時(shí)網(wǎng)絡(luò)測量統(tǒng)計(jì)信息）聚合顯示不同粗細(xì)的炫酷弧光特效，而演示者則用手勢操控地球模型的旋轉(zhuǎn)。
于是在完全不了解大家是否能搞定前端的情況下，我們還是很輕率地決定了要做個(gè)重前端的項(xiàng)目。至于展示什么？既然時(shí)間不夠，那么秀一個(gè)需要生產(chǎn)上線的可視化工具，翻車的概率就大的多，不如直接定位為 For Educational Purpose Only。而且大概是過度解讀了炫酷對于成功的重要性，因此隊(duì)長也輕率地決定了這個(gè)項(xiàng)目的基調(diào)是「極盡浮夸」。就在這樣友好且不靠譜的討論氛圍下，這個(gè)項(xiàng)目的策劃出爐了。
之后就是艱苦卓絕連綿無休的代碼過程了。
龍毛二哥，曉峰和胡家屬的?TiNiuB Team?就在我們對面開工。講道理這其實(shí)是我個(gè)人最喜歡的項(xiàng)目之一。第一天放學(xué)的時(shí)候，看著他們的進(jìn)度其實(shí)我心里虛得不行：看看別人家的項(xiàng)目，我們的絕對主力還在折騰 TiDB Logo 動(dòng)畫，是我敢怒不敢言的狀態(tài)。

原來我想偷一下懶回家睡個(gè)覺啥的，就臨時(shí)改變主意繼續(xù)配合隊(duì)長努力干活；錢同學(xué)也抱著「TiKV 一天只能 Build 24 次必須珍惜」的態(tài)度寫著人生的第一個(gè) Rust 項(xiàng)目。
因此，這里必須鳴謝龍哥他們對我們的鞭策。
事實(shí)證明，誤打誤撞但又深謀遠(yuǎn)慮的浮夸戰(zhàn)略是有效的。Demo 的時(shí)候我很認(rèn)真地盯著評(píng)委：在本項(xiàng)目最浮夸的 Logo 展示環(huán)節(jié)，大家的眼睛是發(fā)著光的，一如目睹了摩西分開紅海。我個(gè)人認(rèn)為這個(gè)動(dòng)畫 Logo 生生拉高了項(xiàng)目 50% 的評(píng)分。
只是具體要說感悟的話（似乎好多年沒寫感悟了呢），首先這次我們?nèi)齻€(gè)組員雖然有兩個(gè)是 PingCAP 員工，不過由于技能的缺口大于人力，因此負(fù)責(zé)的任務(wù)都不是自己所屬的模塊：隊(duì)長是 TiKV 組的但是在寫前端，我是 OLAP 組的但是在改 PD 和 DB，錢同學(xué)也在做自己從來沒寫過的 Rust（參賽前一周簡單入門了一下），因此其實(shí)還蠻有挑戰(zhàn)的（笑）。然后偶爾寫寫自己不熟悉的語言，搞搞自己不熟悉的模塊，會(huì)有一種別樣的新鮮刺激感，這大概就是所謂的路邊野花更香吧（嗯）？除此之外，Hackathon 更像一個(gè)大型社交活動(dòng)，滿足了貓一樣孤僻的程序員群體被隱藏的社交欲，有利于碼農(nóng)的身心發(fā)展，因此可以多搞搞 :) 。
回到我們項(xiàng)目本身的話，其實(shí) TiDB 的源碼閱讀或者其他介紹類文章其實(shí)并不能非常直觀地幫助一頭霧水的初學(xué)者理解這個(gè)系統(tǒng)。我們做這個(gè)項(xiàng)目的最大目的是能降低學(xué)習(xí)門檻，讓所有人能以非常直觀，互動(dòng)的方式近距離理解她。所以希望這個(gè)項(xiàng)目能給大家?guī)矸奖惆伞?/p>
TiDB Hackathon 2018 共評(píng)選出六個(gè)優(yōu)秀項(xiàng)目，本系列文章將由這六個(gè)項(xiàng)目成員主筆，分享他們的參賽經(jīng)驗(yàn)和成果。我們非常希望本屆 Hackathon 誕生的優(yōu)秀項(xiàng)目能夠在社區(qū)中延續(xù)下去，感興趣的小伙伴們可以加入進(jìn)來哦。