前言
古代，醫者看病講究「望、聞、問、切」，通過病人的外部綜合表現對病症做出判斷。現代，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 了：
http://PD_ADDRESS:2379/dashboard
注意：若修改過 PD 默認端口，需要自行修改上述地址中的端口爲自己設置的端口。
除了 Key Visualizer，TiDB Dashboard 還包含更多其他的診斷功能，我們將在未來的系列文章中作進一步介紹，敬請期待。
