在大數據時代，如何高效、可靠地存儲海量數據成為眾多企業面臨的挑戰。TiDB作為一款開源的分布式NewSQL數據庫，其獨特的數據存儲架構使其能夠同時支持在線事務處理（OLTP）和在線分析處理（OLAP）場景。本文將深入剖析TiDB的數據存儲原理，并結合實戰應用，揭示其如何實現數據的高可用與水平擴展。

一、 TiDB整體架構與存儲定位

TiDB的整體架構分為三層：

1. TiDB Server（計算層）：無狀態的SQL處理層，負責接收客戶端連接、解析SQL、制定查詢計劃，并通過TiKV API與存儲層交互。它本身不存儲數據，因此可以輕松水平擴展。
2. PD（Placement Driver，調度層）：整個集群的“大腦”，負責管理元數據、分配全局唯一且遞增的時間戳（TSO），以及最關鍵的任務——調度Region，確保數據負載均衡和高可用。
3. TiKV Server（存儲層）：這是數據存儲的核心。TiKV是一個分布式的、支持事務的鍵值存儲引擎，數據持久化存儲于此。

本文聚焦的“數據存儲”，其核心戰場正是在TiKV層。

二、 TiKV存儲引擎核心原理

TiKV的存儲設計巧妙地融合了多項成熟技術，構建了一個強大而可靠的基石。

1. 數據模型：有序的Key-Value Map
TiKV對外暴露的是一個有序的、支持事務的Key-Value Map。這個“有序”特性至關重要。所有數據（包括表數據、索引）最終都會被編碼成Key-Value對（KV對）。

• Key的設計遵循特定格式，例如對于表數據，其結構通常為：t{table<em>id}</em>r{row_id}，這確保了同一張表的數據在鍵空間中是連續存儲的。
• 這種有序排列為高效的范圍查詢（Range Scan）奠定了基礎，也是實現分布式事務和多版本并發控制（MVCC）的關鍵。

2. 底層存儲：RocksDB
TiKV沒有重復造輪子，而是選擇將數據持久化工作交給了業界久經考驗的單機存儲引擎——RocksDB（一個基于LSM-Tree的KV存儲庫）。每個TiKV節點內部都運行著一個RocksDB實例，負責將數據高效地寫入磁盤。RocksDB出色的寫性能和順序讀性能，為TiKV提供了堅實的單機存儲能力。

3. 數據分片與調度：Region
這是TiDB實現水平擴展的核心。TiKV不會將整個巨大的KV Map存儲在一個節點上，而是將其動態切分為一系列連續的片段，每個片段稱為一個Region。

• 每個Region默認大小約為96MB~144MB，負責存儲一個連續鍵范圍（[startkey, endkey)）內的所有數據。
• Region是數據移動、復制和負載均衡的最小單位。PD會持續監控所有TiKV節點上Region的數量和大小，一旦發現某個節點負載過高（Region過多），就會自動將部分Region調度到負載較低的節點上，整個過程對應用透明。

4. 高可用保障：Raft共識算法
單機存儲必然存在單點故障風險。TiKV通過Raft協議解決了這一問題。

• 每個Region的數據都會在多個TiKV節點（通常為3個副本）之間復制，形成一個Raft Group。
• 該Group中有一個Leader副本負責處理該Region的所有讀寫請求，其他Follower副本同步數據。
• 當Leader所在節點發生故障時，剩余的Follower副本會通過Raft協議快速選舉出新的Leader，繼續提供服務，實現了自動故障轉移（Failover），通常能在秒級內恢復，保證了高可用性（HA）。

5. 事務與MVCC：分布式事務的核心
TiDB支持完整的分布式ACID事務，其實現依賴于在KV模型上構建的多版本并發控制（MVCC）。

• 每次對數據的修改（增刪改）都不會直接覆蓋原數據，而是會生成一個帶時間戳（從PD獲取的TSO）的新版本。
• 每個KV對都可能關聯著多個按時間戳排序的版本。讀操作根據事務開始的時間戳，讀取對應時間點之前的最新數據版本，從而實現無鎖的快照讀（Snapshot Read），避免了讀寫沖突。
• 對于寫操作，TiDB采用了優化的兩階段提交（2PC）協議，結合MVCC來保證跨多個Region（即跨多個TiKV節點）的事務的原子性和隔離性。

三、 實戰視角：數據存儲操作流程示例

讓我們通過一個簡單的SQL寫入操作，串聯起上述原理：

場景：向用戶表users（假設table_id=1）插入一行數據 (id=100, name='張三')。

1. SQL解析與計劃：客戶端連接TiDB Server，發送INSERT語句。TiDB Server解析SQL，確定需要寫入的表和行。
2. Key編碼與路由：TiDB Server根據數據模型，將這一行數據編碼為KV對。Key可能類似 t1_r100，Value包含name等信息。TiDB Server知道需要將此KV對寫入哪個鍵范圍，進而通過查詢PD或緩存，定位到負責該鍵范圍的Region Leader所在的具體TiKV節點地址。
3. Raft提案與復制：TiDB Server將寫請求發送給目標Region的Leader TiKV節點。該節點的Raft層將此寫操作作為一個提案（Proposal）提交給本地的Raft狀態機，并同時通過Raft協議復制給該Region Group內的其他Follower節點。
4. 多數派提交與持久化：當提案被集群中的多數派（如3副本中的2個）確認并持久化到各自的RocksDB中后，Raft協議認為該日志已提交（Committed）。
5. 應用狀態機與返回：Leader TiKV將已提交的日志條目應用到本地的KV狀態機，即實際寫入（或更新）其RocksDB實例。寫入成功后，Leader將成功響應返回給TiDB Server。
6. 客戶端確認：TiDB Server收到TiKV的成功響應后，向客戶端返回執行成功。

整個過程中，PD持續在后臺監控所有Region的狀態，如有節點宕機或數據分布不均，會觸發平滑的Region調度。

四、 存儲相關實戰優化要點

1. 熱點Region處理：如果某一行或某一個小范圍的數據被極高頻率訪問（如電商秒殺商品），可能導致單個Region成為熱點。解決方案包括：使用TiDB的SHARD<em>ROW</em>ID_BITS等特性打散行ID，或者從業務設計上避免極端熱點。PD也會通過拆分（Split）過熱的Region來分散壓力。
2. 存儲容量規劃：TiKV的存儲容量取決于節點數量、副本數（通常3）和單機磁盤大小。規劃時需預留空間，因為Region分裂、RocksDB壓縮等操作需要額外空間。
3. 監控關鍵指標：在運維中，需密切關注 TiKV集群存儲容量、Region分布均衡度、Raft IO延遲、Leader/Follower數量以及RocksDB的讀寫放大等指標，這些是集群健康度的關鍵信號。

###

TiDB通過將數據抽象為有序KV模型，并基于RocksDB、Region分片、Raft復制協議和MVCC這四大支柱，構建了一個既彈性擴展又穩定可靠的分布式存儲層。理解TiKV的存儲原理，不僅有助于更好地使用TiDB，也能為設計分布式系統提供寶貴思路。在實際應用中，結合具體的業務負載模式進行合理的集群部署、參數調優和監控，是發揮TiDB存儲威力的關鍵。