作者：鄭向升，駱迪安，施聞軒
古代，醫者看病講究「望、聞、問、切」，通過病人的外部綜合表現對病症做出判斷。現代，CT 的發明使得人們可以使用 X 光穿透身體各組織内部，将整體的情況以圖像的方式展現出來，醫生可以根據這個資訊快速地排查問題。CT 的出現不僅将診斷的效率提升到了新的高度，也給客觀描述身體狀态提供了一個标準，是醫學史上重要的裡程碑。
一個工作中的 TiDB 叢集如果隻有個别節點非常繁忙，而其他節點相對比較空閑，我們就稱這個叢集存在熱點（問題）。TiDB 作為一個分布式資料庫，雖然會自動且動态的進行資料的重新分布以到達盡可能的均衡，但是有時候由于業務特性或者業務負載的突變，仍然會産生熱點，這時候往往就會出現性能瓶頸。
在 TiDB 4.0 版本之前，如果我們要診斷叢集中的讀寫熱點問題，一般也需要經過「望、聞、問、切」，通過叢集的對外表現逐漸摸清熱點問題所在：
- 檢查各元件 CPU 和 IO 是否均衡；
- 根據叢集熱區域清單逐一檢查熱點表；
- 通過表進一步分析業務邏輯檢視熱點成因；
- ……
整個過程比較繁瑣，涉及到不同的工具群組件，需要一定的學習成本，而且整個結果也很不直覺。
Google 在 Bigtable 的雲服務中提供了一個可視化的工具：Key Visualizer，它可以優雅的解決熱點排查的問題。 在 4.0 版本中 TiDB 也實作了 Key Visualizer 功能。現在，我們可以很輕松地給叢集拍個 “CT”，快速直覺地觀察叢集整體熱點及流量分布情況，如下圖所示：
為什麼會有熱點？
一個叢集中隻有少數節點在賣力工作，其他節點在劃水，這個現象聽上去像是 TiDB 的 bug，其實不然，它是一種 feature ?。正經地說，大多數情況下熱點的出現是業務讀寫模式不能很好地适配分布式的場景的結果。
例如，如果 90% 的流量都在讀寫一小塊資料，那麼這就是一個典型的熱點，因為 TiDB 架構上一行資料會由一個 TiKV 節點進行處理，而不是所有節點都能用于處理這一行資料。因而，如果大多數業務流量都在頻繁通路某一行資料，那麼大多數業務流量最終都會由某一個 TiKV 節點來處理，最終這個 TiKV 機器的性能就成為了整個業務的性能上限，無法通過增加更多機器來提高處理能力。
由于 TiDB 實際上是以 Region（即一批相鄰資料）為機關劃分處理，是以除了上述場景以外還有更多會産生熱點的場景，如使用自增主鍵連續寫入相鄰資料導緻的寫入表資料熱點、時間索引下寫入相鄰時間資料導緻的寫入表索引熱點等，在這裡就不一一介紹了，感興趣的同學可以閱讀 TUG 社群上的文章《TiDB 熱點問題詳解》。
如何發現産生熱點的元兇？
工作原理
由前文描述可知，熱點的本質是大多數讀寫流量都隻涉及個别 Region，進而導緻叢集中隻有個别 TiKV 節點承載了大部分操作。 TiDB Key Visualizer 将所有 Region 的讀寫流量按時間依次展示出來，使用顔色明暗表示讀寫流量的多少，以熱力圖的方式呈現。熱力圖使使用者能對叢集内 Region 熱度情況快速地一窺究竟，直覺了解叢集中熱點 Region 在哪裡及其變化趨勢，如下圖所示：
圖檔說明：
- 熱力圖的縱軸 Y 表示叢集裡面的 Region，橫跨 TiDB 叢集上所有資料庫和資料表，橫軸 X 表示時間；
- 顔色越暗（cold）表示該區域的 Region 在這個時間段上讀寫流量較低，顔色越亮（hot）表示讀寫流量越高，即越熱。
使用者也可以控制隻顯示讀流量或寫流量。以上面這個圖為例，它的下半部分有六條明顯的亮色線條，表明各個時刻都有 6 個左右的 Region（或相鄰 Region）讀寫流量非常高。使用者将滑鼠移到亮色線條處，即可知道這個大流量 Region 屬于什麼庫什麼表。
常見熱力圖解讀
1. 均衡：期望結果
如圖所示，熱力圖顔色均勻或者深色和亮色混合良好，說明讀取或寫入在時間和 Region 空間範圍上都分布得比較均衡，說明通路壓力均勻地分攤在所有的機器上。這種負載是最适合分布式資料庫的，也是我們最希望見到的。
2. X 軸明暗交替：需關注高峰期的資源情況
如圖所示，熱力圖在 X 軸（時間）上表現出明暗交替，但 Y 軸（Region）則比較均勻，說明讀取或寫入負載具有周期性的變化。這種情況可能出現在周期性的定時任務場景，如大資料平台每天定時從 TiDB 中抽取資料。一般來說可以關注一下使用高峰時期資源是否充裕。
3. Y 軸明暗交替：需關注産生的熱點聚集程度
如圖所示，熱力圖包含幾個明亮的條紋，從 Y 軸來看條紋周圍都是暗的，這表明，明亮條紋區域的 Region 具有很高的讀寫流量，可以從業務角度觀察一下是否符合預期。例如，所有業務都要關聯一下使用者表的話，勢必使用者表的整體流量就會很高，那麼在熱力圖中表現為亮色區域就非常合理。需要注意的是，TiKV 自身擁有以 Region 為機關的熱點平衡機制，是以涉及熱點的 Region 越多其實越能有利于在所有 TiKV 節點上均衡流量。換句話說，明亮條紋越粗、數量越多則意味着熱點越分散、更多的 TiKV 能得到利用；明亮條紋越細、數量越少意味着熱點越集中、熱點 TiKV 越顯著、越需要 DBA 介入并關注。
4. 局部突然變亮：需關注突增的讀寫請求
如圖所示，熱力圖中某些區域突然由暗色變為了亮色。這說明在短時間内這些 Region 資料流量突然增加。例如，微網誌熱搜或者秒殺業務。這種時候，需要 DBA 依據業務關注流量突變是否符合預期，并評估系統資源是否充足。值得注意的是，和第 3 點一樣，明亮區域 Y 軸方向的粗細非常關鍵，明亮區域如果非常細，說明短時間内突然增加大量流量，且這些流量都集中到了少量 TiKV 中，這就需要 DBA 重點關注了。
5. 明亮斜線：需關注業務模式
如圖所示，熱力圖顯示了明亮的斜線，表明讀寫的 Region 是連續的。這種場景常常出現在帶索引的資料導入或者掃描階段。例如，向自增 ID 的表進行連續寫入等等。圖中明亮部分對應的 Region 是讀寫流量的熱點，往往會成為整個叢集的性能問題所在。這種時候，可能需要業務重新調整主鍵，盡可能打散以将壓力分散在多個 Region 上，或者選擇将業務任務安排在低峰期。
需要注意的是，這裡隻是列出了幾種常見的熱力圖模式。Key Visualizer 中 實際展示的是 整個叢集上所有資料庫、資料表的熱力圖，是以非常有可能在不同的區域觀察到不同的熱力圖模式，也可能觀察到多種熱力圖模式的混合結果。使用的時候應當視實際情況靈活判斷。
如何解決熱點
無論是之前的望、聞、問、切，還是現在的 Key Visualizer，都是幫助找到形成熱點的「元兇」。找到了元兇自然可以進一步着手進行處理，提高叢集整體性能和健康度。TiDB 其實内置了不少幫助緩解常見熱點問題的功能，本文限于篇幅就不再贅述，對此感興趣的同學可以閱讀《TiDB 高并發寫入常見熱點問題及規避方法》一文。
實戰案例
看完上面那麼長安利，不如再看一個實際例子直覺感受一下 Key Visualizer 的威力。我司的開發同學經常使用各種标準評測中的得分來協助判斷 TiDB、TiKV 性能提升的結果。有了 Key Visualizer 之後，我們最近就發現了一個性能測試程式自身 SQL 寫法引發的問題，如下圖所示：
這是 TPC-C 測試在 TiDB 上的讀熱力圖，我們假設這是一個真實的業務，現在我們要為它進行調優，該圖的左半部分是标準測試的導入資料階段，右半部分是标準測試的性能測試階段。
由圖可見，在性能測試階段（右半部分）bmsql_new_order 表的流量顯著地高于其他所有表。雖然熱點圖中亮色帶高度較高，即該熱點表的 Region 個數還比較多，應當能比較好地分散到各個 TiKV 上使得負載比較均衡，但從設計上來說該表有大量讀流量本身是一個不合理現象。
由此，我們分析了這個表相關的 SQL 語句，發現測試程式中存在一些備援 SQL 會重複從這個表中讀取資料，是以我們在資料庫層面對優化器做了一些改進，提升了這個情況下的性能。
其他應用場景
除了以上提到的場景，Key Visualizer 對以下場景也會有一些幫助：
1. 發現業務負載的變化
資料庫上所承載的業務負載往往會随着時間慢慢發生變化，如使用者需求或關注度逐漸發生了轉移等。使用 Key Visualizer 就能對業務負載進行細粒度的觀察，通過對比整個業務負載的曆史情況，就能及時發現變化趨勢，進而取得先機。
2. 觀察業務健康度
目前不少使用者的應用架構已經從單體系統逐漸轉變為了微服務架構。系統中調用鍊持續增加的複雜性，讓整個系統的監控難度也随着架構轉變而提升。資料庫作為這些調用鍊的最後一環，往往也是最重要的一環。使用 Key Visualizer 觀察資料庫負載的曆史變化情況，可以從側面觀察出業務運作的健康情況，及時發現業務異常。
3. 活動預演
線上業務競争越來越激烈，“造節” “促銷” 一周一次，預防翻車自然是 DBA 必不可少的工作。有了 Key Visualizer 提供的熱力圖，可以對促銷提前進行預演，在更低層面對業務行為有一個直覺、定性的認識，提前了解流量模式對應模拟的場景。後續在生産環境中觀察到類似模式時，就能得心應手進行應對，降低翻車的可能性。
快速嘗鮮
目前，想嘗鮮的使用者可以啟動 PD master 版本（或在使用 Ansible 部署時将 tidb_version 設定為 latest），然後浏覽器打開以下位址就可以體驗 Key Visualizer 了：