TiDB 是什么？
TiDB 是一個分布式 NewSQL 數據庫。它支持水平彈性擴展、ACID 事務、標準 SQL、MySQL 語法和 MySQL 協議，具有數據強一致的高可用特性，是一個不僅適合 OLTP 場景還適合 OLAP 場景的混合數據庫。
TiDB怎么來的？
著名的開源分布式緩存服務 codis 的作者，PingCAP聯合創始人& CTO ，資深 infrastructure 工程師的黃東旭，擅長分布式存儲系統的設計與實現，開源狂熱分子的技術大神級別人物。即使在互聯網如此繁榮的今天，在數據庫這片邊界模糊且不確定地帶，他還在努力尋找確定性的實踐方向。
直到 2012 年底，他看到 google 發布的兩篇論文，如同棱鏡般，折射出他自己內心微爍的光彩。這兩篇論文描述了 Google 內部使用的一個海量關系型數據庫 F1/Spanner ，解決了關系型數據庫、彈性擴展以及全球分布的問題，并在生產中大規模使用。“如果這個能實現，對數據存儲領域來說將是顛覆性的”，黃東旭為完美方案的出現而興奮， PingCAP 的 TiDB 在此基礎上誕生了。
TiDB架構
??TiDB 集群主要分為三個組件：
１TiDB Server
TiDB Server 負責接收 SQL 請求，處理 SQL 相關的邏輯，并通過 PD 找到存儲計算所需數據的 TiKV 地址，與 TiKV 交互獲取數據，最終返回結果。 TiDB Server是無狀態的，其本身并不存儲數據，只負責計算，可以無限水平擴展，可以通過負載均衡組件（如LVS、HAProxy 或F5）對外提供統一的接入地址。
２PD Server
Placement Driver (簡稱 PD) 是整個集群的管理模塊，其主要工作有三個： 一是存儲集群的元信息（某個 Key 存儲在哪個 TiKV 節點）；二是對 TiKV 集群進行調度和負載均衡（如數據的遷移、Raft group leader的遷移等）；三是分配全局唯一且遞增的事務 ID。
PD 是一個集群，需要部署奇數個節點，一般線上推薦至少部署 3 個節點。
３TiKV Server
TiKV Server 負責存儲數據，從外部看 TiKV 是一個分布式的提供事務的 Key-Value 存儲引擎。存儲數據的基本單位是 Region，每個 Region 負責存儲一個 Key Range （從 StartKey 到EndKey 的左閉右開區間）的數據，每個 TiKV 節點會負責多個 Region 。TiKV 使用 Raft協議做復制，保持數據的一致性和容災。副本以 Region 為單位進行管理，不同節點上的多個 Region 構成一個 RaftGroup，互為副本。數據在多個 TiKV 之間的負載均衡由 PD 調度，這里也是以 Region 為單位進行調度。
以上三個分別是指計算、調度、存儲三個技術點：
這次重點講一下存儲：
TIKV采用的key-》value的數據模型，我們可以把TIKV想象為一個巨大的Map，里面的是按照Key的二進制的順序進行排序，也就是可以認為里面存儲的都是一個個key-》value對，在這里我們需要記住的是這里的存儲模型與SQL中的Table無關！
RocksDb
任何持久化的存儲引擎，數據終究都是要存儲在磁盤之上的，TIKV也不例外，但是TIKV是沒有選擇直接將數據寫在磁盤之上的，而是采用了RocksDB，將數據交給OocksDB，由它將數據寫在磁盤上，他們采用這個的原因是開發單機的引擎要把各種細致化的話，還要滿足他們的各種需求，工作量較大。所以他們直接采用了Fecebook開發的RocksDB來使用，這樣的話，就是存儲的數據模型和數據的落地已經選擇好。
Raft
目前已經有一個高效可靠的本地存儲機制，現在要做的就是要求數據的分布，單機的存儲就算再強大，也會丟失數據，機器掛掉了，或者機房斷電了，再或者地震了等等情況，都會造成數據的丟失，所以他們要實現數據的分布，也就是分布式。單機不可能支持高可用。他們在這里采用Raft協議，Raft是一致性協議，在這里我們簡單的講解一下Raft，采用這個協議可以達成三個目標：
1. Leader 選舉
2. 成員變更
3. 日志復制
TIKV通過Raft來做數據復制，每個數據變更都會落地成為一條Raft日志，通過Raft的日志復制功能，將數據安全可靠地同步到group的多數節點中。
?
??到這里我們總結一下，通過單機的RocksDB，我們可以將數據快速地存儲在磁盤上；通過Raft，我們可以將數據復制到多臺機器上，以防單機失效。數據的寫入是通過Raft這一層的接口寫入，而不是直接寫RocksDB。通過實現Raft，我們擁有了一個分布式的KV，現在再也不用擔心某臺機器掛掉了。
Region
前面提到，我們將 TiKV 看做一個巨大的有序的 KV Map，那么為了實現存儲的水平擴展，我們需要將數據分散在多臺機器上。這里提到的數據分散在多臺機器上和 Raft 的數據復制不是一個概念，在這一節我們先忘記 Raft，假設所有的數據都只有一個副本，這樣更容易理解。
對于一個 KV 系統，將數據分散在多臺機器上有兩種比較典型的方案：一種是按照 Key 做 Hash，根據 Hash 值選擇對應的存儲節點；另一種是分 Range，某一段連續的 Key 都保存在一個存儲節點上。TiKV 選擇了第二種方式，將整個 Key-Value 空間分成很多段，每一段是一系列連續的 Key，我們將每一段叫做一個 Region，并且我們會盡量保持每個 Region 中保存的數據不超過一定的大小(這個大小可以配置，目前默認是 64MB)。每一個 Region 都可以用 StartKey 到 EndKey 這樣一個左閉右開區間來描述。
?
??注意，這里的 Region 還是和 SQL 中的表沒什么關系！ 請各位繼續忘記 SQL，只談 KV。
將數據劃分成 Region 后，我們將會做兩件重要的事情：
- 以 Region 為單位，將數據分散在集群中所有的節點上，并且盡量保證每個節點上服務的 Region 數量差不多
- 以 Region 為單位做 Raft 的復制和成員管理
這兩點非常重要，我們一點一點來說。
先看第一點，數據按照 Key 切分成很多 Region，每個 Region 的數據只會保存在一個節點上面。我們的系統會有一個組件來負責將 Region 盡可能均勻的散布在集群中所有的節點上，這樣一方面實現了存儲容量的水平擴展（增加新的節點后，會自動將其他節點上的 Region 調度過來），另一方面也實現了負載均衡（不會出現某個節點有很多數據，其他節點上沒什么數據的情況）。同時為了保證上層客戶端能夠訪問所需要的數據，我們的系統中也會有一個組件記錄 Region 在節點上面的分布情況，也就是通過任意一個 Key 就能查詢到這個 Key 在哪個 Region 中，以及這個 Region 目前在哪個節點上。至于是哪個組件負責這兩項工作，會在后續介紹。
對于第二點，TiKV 是以 Region 為單位做數據的復制，也就是一個 Region 的數據會保存多個副本，我們將每一個副本叫做一個 Replica。Repica 之間是通過 Raft 來保持數據的一致（終于提到了 Raft），一個 Region 的多個 Replica 會保存在不同的節點上，構成一個 Raft Group。其中一個 Replica 會作為這個 Group 的 Leader，其他的 Replica 作為 Follower。所有的讀和寫都是通過 Leader 進行，再由 Leader 復制給 Follower。
大家理解了 Region 之后，應該可以理解下面這張圖：
?
??我們以 Region 為單位做數據的分散和復制，就有了一個分布式的具備一定容災能力的 KeyValue 系統，不用再擔心數據存不下，或者是磁盤故障丟失數據的問題。這已經很 Cool，但是還不夠完美，我們需要更多的功能。
MVCC
很多數據庫都會實現多版本控制（MVCC），TiKV 也不例外。設想這樣的場景，兩個 Client 同時去修改一個 Key 的 Value，如果沒有 MVCC，就需要對數據上鎖，在分布式場景下，可能會帶來性能以及死鎖問題。
TiKV 的 MVCC 實現是通過在 Key 后面添加 Version 來實現，簡單來說，沒有 MVCC 之前，可以把 TiKV 看做這樣的：
Key1 -> Value
Key2 -> Value
……
KeyN -> Value
有了 MVCC 之后，TiKV 的 Key 排列是這樣的：
Key1-Version3 -> Value
Key1-Version2 -> Value
Key1-Version1 -> Value
……
Key2-Version4 -> Value
Key2-Version3 -> Value
Key2-Version2 -> Value
Key2-Version1 -> Value
……
KeyN-Version2 -> Value
KeyN-Version1 -> Value
……
注意，對于同一個 Key 的多個版本，我們把版本號較大的放在前面，版本號小的放在后面（回憶一下 Key-Value 一節我們介紹過的 Key 是有序的排列），這樣當用戶通過一個 Key + Version 來獲取 Value 的時候，可以將 Key 和 Version 構造出 MVCC 的 Key，也就是 Key-Version。然后可以直接 Seek(Key-Version)，定位到第一個大于等于這個 Key-Version 的位置。
事務
TiKV 的事務采用的是 Percolator 【
https://research.google.com/pubs/pub36726.html】模型，并且做了大量的優化。事務的細節這里不詳述，大家可以參考論文以及我們的其他文章（點擊閱讀原文可查看）。這里只提一點，TiKV 的事務采用樂觀鎖，事務的執行過程中，不會檢測寫沖突，只有在提交過程中，才會做沖突檢測，沖突的雙方中比較早完成提交的會寫入成功，另一方會嘗試重新執行整個事務。當業務的寫入沖突不嚴重的情況下，這種模型性能會很好，比如隨機更新表中某一行的數據，并且表很大。但是如果業務的寫入沖突嚴重，性能就會很差，舉一個極端的例子，就是計數器，多個客戶端同時修改少量行，導致沖突嚴重的，造成大量的無效重試。
