作者介紹： 田維繁，網易遊戲資深數據庫工程師，TUG 華南區 Co-Leader。數據庫老兵，維護過多種數據庫，目前在網易遊戲負責數據庫私有云平臺的運維和開發。
在 TUG 網易線上企業行活動中，來自網易遊戲的資深數據庫工程師田維繁老師分享了 TiDB 海量 region 集羣調優主題，以下內容整理自當天活動分享實錄。 此次分享的主題包括三個方面：
-
第一部分是關於網易遊戲以及網易遊戲目前使用 TiDB 現狀；
-
第二部分是 tombstone key 案例分享，包括整個排查過程介紹；
-
第三部分是使用 TiDB 5.0 的初體驗以及未來展望。
關於我們
我們是面向整個網易遊戲，提供一站式數據庫私有云服務的部門，提供包括 MongoDB、MySQL、Redis、TiDB 等數據庫服務。網易遊戲 99% 以上的遊戲業務都在使用我們提供的數據庫私有云服務。
TiDB 在網易遊戲的使用情況如下：整個 TiDB 的集羣數量在 50+，TiDB 環境的整體數據規模在 200TB+，最大的集羣節點數 25+，包括大部分的 TiKV 以及小部分的 TiFlash 節點，單集羣的最大數據量在 25TB+。儘管目前 TiDB 屬於初步使用階段，但是也已經達到了一定規模，整個業務使用過程中我們也碰到了諸多問題。
本次分享我挑選了一個比較有意思的案例，分享我們排查的整個過程，也非常期望大家能從中得到一定的參考借鑑。
tombstone key 引發的“血案”
我們分享的案例是 tomstone key 引發的“血案”，可能有的小夥伴們會問 tomstone key 是什麼？後面會詳細的介紹 tomstone key 的含義。
**爲什麼叫“血案”呢？**是因爲一想到血案，大家會覺得這個問題確實比較嚴重。
這個問題當時影響了網易某大型遊戲的實時和離線業務分析場景，導致整個分析業務不可用，進而影響了內部數據報表系統的可用性。另外，由於持續時間還較長，遊戲的產品運營以及公司的高層也無法及時地看到遊戲數據。
背景
在分析具體問題前，先簡單介紹一下整個業務背景：集羣單節點 region 數非常多，TiKV 節點數在 25+，單節點 region 數在 9 萬+。主要業務屬於實時分析型的業務，存在大量的事務型刪除和插入操作。
問題現狀
下面進入問題案例現場，這個案例從一個電話報警開始。某一天凌晨 4 點，我們接到了電話報警，確定問題影響之後，第一時間通知業務，然後開始問題排查，看看到底是什麼引起的報警。
如上圖所示，可以看到整個節點的 CPU 是被打滿的，此時首先猜測是否因爲熱點導致了這種現象，一般情況下單個節點 CPU 異常高，都會被認定爲是熱點問題。爲了快速處理這個問題，我們暫時先把該節點下線，以免導致整個數據庫的不可用。結果發現將該節點下線之後，其他的 TiKV 節點也會突然出現飆高的情況，即不能通過簡單的重啓節點來讓業務恢復正常。既然是熱點問題，那麼緊急排查熱點刻不容緩。首先，熱力圖確實存在一些熱點問題，可以有針對性的找出熱點對應的一些表。
其次，通過熱力圖，以及一些熱點的元數據表，鎖定大批量的熱點表，發現這些表都是聯合組建的。這樣就比較簡單了，直接批量設置一個參數 SHARD_ROW_ID_BITS 去打散。
同時，也需要聯繫業務去發現可能存在的熱點表，一起做打散。除此之外，我們還會監控 hot region 表，如果出現未打散的表，會設置參數自動打散。並且適當調整 PD 的熱點調度併發數，然後加大整個熱點的調度，可以快速處理類似的熱點問題。經過一波調整之後，發現 CPU 確實降下來了，訪問業務反饋也正常，彷彿問題已經解決了。但是到了第二天，我們在 10 點鐘又收到一波的電話報警，此時的問題在業務上已經十分緊急，我們立即對整個問題進行重新梳理。梳理過程中，我們回顧了第一次處理的情況，猜測要麼第一次處理問題不夠徹底，要麼根本就不是熱點問題導致的。於是我們迴歸問題本身進行分析。既然是 CPU 飆高，我們首先從 CPU 這個點去排查，排查完之後發現是 storeage readpool CPU 這項指標飆高。
這個指標飆高之前其實沒有碰到過，當時也比較迷茫，所以我們聯繫了 TiDB 社區的技術專家：啓斌、啓航以及躍躍，在線支持。
通過日誌，以及一些其他的指標：包括 seek duration 以及 Batch Get 等，鎖定了是 seek tombstone key 引起的問題。
回到最開始的問題，什麼是 tombstone key ? 這裏也簡單介紹一下。
一般刪完數據之後，TiDB 中會保留多版本數據，即在新插入數據覆蓋老數據時，老數據不會馬上被清理掉，而是和新數據一起保留，同時以時間戳來區分多版本。這些多版本數據什麼時候被刪除清理掉呢？ 此時有一個 GC 線程，GC 線程會通過後臺去遍歷，遍歷超過 GC 時間的一些 key 。然後將這些 key 標記爲 tombstone key。這些 key 其實只是做一個標記，即所謂的 tombstone key。這些 key 的清理是由 RocksDB 引擎後臺發起一個線程以 Compaction 的方式來進行回收。RocksDB 整個 Compaction 過程這裏也簡單介紹一下。首先數據插入 RocksDB 之後，會寫入 WAL，然後正式的寫入 memory table 的內存塊。當內存塊寫滿之後，我們會把它標記爲 immutable member table。
標記完之後，RocksDB 會把內存塊 flush 到磁盤，生成一個 SST 文件，這就是我們的所謂的 level 0 層。
當 level 0 層 SST 文件越來越多時，就會出現大量的重複數據，也即 tombstone key 會開始出現在這一層，此時 RocksDB 就會通過 compaction 的方式，將這些 SST 合併到 level 1 層。
當 level 1 層文件達到一定預值之後，又會合併到 level 2 層，這就是整個 RocksDB compaction 過程的簡單描述。
到這裏，整個問題幾乎確認了原因。
故障發生前業務刪除過大量的數據，也即在存在大量 tombstone key。在這種情況下執行大量事務，TiKV 就可能會 seek 到大量的被刪掉的 tombstone key。由於需要跳過這些 tombstone key，所以可能會導致 batch get 的性能嚴重下降，進而影響整個 Storage ReadPool CPU 飆高，使整個節點卡住。
這裏需要回顧一下，第一次處理問題的時候，我們通過熱點打散之後，整個問題彷彿就恢復了？
爲什麼當時我們熱點打散之後問題就恢復了？其實我們也做一個回顧，當時發現在打散熱點的時候，確實對整個問題有了一定的緩解，最根本原因在於處理的過程中，RocksDB 對底層的 tombstone key 做了一個 compaction，導致 tombstone key 消失了，所以問題得到了恢復。
確定問題之後，下一步就是怎麼樣去優化，徹底解決這個問題。爲此，我們制定了一些優化的措施。
如何優化
- 業務側
首先，分區表改造。某些場景如：業務在補數據時可以按天直接刪除分區，TiDB 就會走快速的 Delete Ranges 而不用等 compaction。
其次，避免熱點問題。業務讀請求改爲 follower read 方式，創建表指定打散特性，緩解讀寫熱點問題，一定程度上緩解了 seek tombstone key 的影響。
第三，儘可能拆分大事務。事務過大，對整個 TiKV 層，都會造成比較大壓力；事務過大時，需要操作大量的 key，更容易觸發 tombstone key。
在業務層做一些優化方案之後，在運維側我們也去做了一些處理的方案或者優化的方案。
- 運維側
首先，手工 compaction。問題發生時，可以緊急下掉有問題的 TiKV 節點，手工進行 compaction 後，重新接入。其次，熱點表打散。建立自動監控機制來監控集羣熱點表情況，根據熱點類型以及表類型設置自動打散。第三，更完善的溝通渠道。建立與官方的統一溝通渠道，針對 TiDB 相關問題實時溝通，同時也會不定期的組織一些線下交流活動。
- 徹底優化思路
其實這個問題最好的方案是從數據庫層做一個徹底的優化，從上述介紹中，思路應該是比較明瞭的。
存在 tombstone key 的場景下，寫操作或者是 Batch Get，只要繞過這些 tombstone key 從而避免 seek 過多的 tombstone key，就可以很徹底地避免這個問題。此外，相關的優化方案，官方已經合併到了 TiDB 5.0，並且在 4.0.12 版本也做了一個優化。
TiDB 5.0 初體驗
我們非常期待 5.0 的到來。所以在 5.0 發佈之後也第一時間做了一些相關測試。這裏針對一些測試案例，簡單地跟小夥伴們分享一下。
TiDB 5.0 測試體驗
- 穩定性
首先是穩定性，因爲我們是 4.0 或者 4.0 之前的版本，或多或少都會碰到一些問題，比如在高併發的情況下出現性能抖動，這個問題也一直困擾着我們，我們在測試的時候發現 TiDB 4.0.12，在高併發情況下，整個 duration 還有 QPS 都是有一定的波動的。
通過對比測試 5.0，發現整個 duration 和 QPS 是比較穩定的，甚至幾乎看到是一條穩定的直線。
- MPP
5.0 也開發了一些新特性，我們對一些新特性比較感興趣，所以也做了一些測試。
比如兩階段提交，可以看到在測試過程中打開異步提交之後，整體的插入性能 TPS 提升了 33%，延時響應降低了 37%，相較之前有比較大的提升。
提到 5.0，不得不提到一個 5.0 特性的重頭戲，也就是 MPP 特性，這也是我們比較關注的。
對此，我們做了很多的測試，包括基準測試和一些其他的單 SQL 測試。
這裏我想跟大家分享一個真實的數據庫場景測試案例。測試的 MySQL 大概有 6T 的數據，我們跟 TiDB 5.0 的 MPP 做了性能對比，結果發現 MPP 在 5.0 單個 TiFlash 情況下，大多數時候比 MySQL 的性能好並且很多，甚至有些會比 MySQL 性能好十幾倍。
如果有多個 TiFlash ，在使用 MPP 特性之後，性能會更佳。通過測試，我們對 5.0 充滿了信心。
TiDB 5.0 未來可期
接下來我們會去推動 5.0 的落地，比如一些實時業務分析的場景，同時也會主推一些大數據場景在 TiDB 5.0 的落地。除此之外，推進 TP 型的業務在 TiKV 5.0 的落地也在我們的計劃之中。
對於整個數據庫的私有云服務而言，我們在整個 TiDB 建設過程中，做了很多周邊的生態，比如數據庫遷移、統一監控平臺，還有一些自動化的創建、添加等等。後續我們會繼續完善整個 TiDB 的生態建設，使 TiDB 能更好的在整個網易遊戲的雲服務落地，同時解決我們業務的後顧之憂。在使用過程中，我們也得到了 TUG 小夥伴們的大力支持。所以我們在獲取 TUG 社區支持的同時，也會去深度參與整個 TUG 社區的建設，共建整個 TUG 社區。