由於目前的項目把mysql換成了TiDb，所以特意來了解下tidb。其實也不能說換，由於tidb和mysql幾乎完全兼容，所以我們的程序沒有任何改動就完成了數據庫從mysql到TiDb的轉換，TiDB 是一個分佈式 NewSQL (SQL 、 NoSQL 和 NewSQL 的優缺點比較 )數據庫。它支持水平彈性擴展、ACID 事務、標準 SQL、MySQL 語法和 MySQL 協議，具有數據強一致的高可用特性，是一個不僅適合 OLTP 場景還適合 OLAP 場景的混合數據庫。下面是對有關資料的整理還有一些擴展內容以鏈接的方式展示，有興趣可以點擊瞭解一下。
一 TiDb簡介
TiDB 是 PingCAP 公司受 Google Spanner / F1 論文啓發而設計的開源分佈式 HTAP (Hybrid Transactional and Analytical Processing) 數據庫，結合了傳統的 RDBMS 和NoSQL 的最佳特性。TiDB 兼容 MySQL，支持無限的水平擴展，具備強一致性和高可用性。TiDB 的目標是爲 OLTP(Online Transactional Processing) 和 OLAP (Online Analytical Processing) 場景提供一站式的解決方案。TiDB 具備如下核心特點：
1 高度兼容 MySQL
大多數情況下，無需修改代碼即可從 MySQL 輕鬆遷移至 TiDB，分庫分表後的 MySQL 集羣亦可通過 TiDB 工具進行實時遷移。
2水平彈性擴展
通過簡單地增加新節點即可實現 TiDB 的水平擴展，按需擴展吞吐或存儲，輕鬆應對高併發、海量數據場景。
3分佈式事務
TiDB 100% 支持標準的 ACID 事務。
4 真正金融級高可用
相比於傳統主從 (M-S) 複製方案，基於 Raft 的多數派選舉協議可以提供金融級的 100% 數據強一致性保證，且在不丟失大多數副本的前提下，可以實現故障的自動恢復 (auto-failover)，無需人工介入。
5 一站式 HTAP 解決方案
TiDB 作爲典型的 OLTP 行存數據庫，同時兼具強大的 OLAP 性能，配合 TiSpark，可提供一站式 HTAP解決方案，一份存儲同時處理OLTP & OLAP(OLAP、OLTP的介紹和比較 )無需傳統繁瑣的 ETL 過程。
6雲原生 SQL 數據庫
TiDB 是爲雲而設計的數據庫，同 Kubernetes （十分鐘帶你理解Kubernetes核心概念 ）深度耦合，支持公有云、私有云和混合雲，使部署、配置和維護變得十分簡單。
TiDB 的設計目標是 100% 的 OLTP 場景和 80% 的 OLAP 場景，更復雜的 OLAP 分析可以通過 TiSpark 項目來完成。 TiDB 對業務沒有任何侵入性，能優雅的替換傳統的數據庫中間件、數據庫分庫分表等 Sharding 方案。同時它也讓開發運維人員不用關注數據庫 Scale 的細節問題，專注於業務開發，極大的提升研發的生產力.
二 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 爲單位進行調度。
三 核心特性
1 水平擴展
無限水平擴展是 TiDB 的一大特點，這裏說的水平擴展包括兩方面：計算能力和存儲能力。TiDB Server 負責處理 SQL 請求，隨着業務的增長，可以簡單的添加 TiDB Server 節點，提高整體的處理能力，提供更高的吞吐。TiKV 負責存儲數據，隨着數據量的增長，可以部署更多的 TiKV Server 節點解決數據 Scale 的問題。PD 會在 TiKV 節點之間以 Region 爲單位做調度，將部分數據遷移到新加的節點上。所以在業務的早期，可以只部署少量的服務實例（推薦至少部署 3 個 TiKV， 3 個 PD，2 個 TiDB），隨着業務量的增長，按照需求添加 TiKV 或者 TiDB 實例。
2 高可用
高可用是 TiDB 的另一大特點，TiDB/TiKV/PD 這三個組件都能容忍部分實例失效，不影響整個集羣的可用性。下面分別說明這三個組件的可用性、單個實例失效後的後果以及如何恢復。
TiDB
TiDB 是無狀態的，推薦至少部署兩個實例，前端通過負載均衡組件對外提供服務。當單個實例失效時，會影響正在這個實例上進行的 Session，從應用的角度看，會出現單次請求失敗的情況，重新連接後即可繼續獲得服務。單個實例失效後，可以重啓這個實例或者部署一個新的實例。
PD
PD 是一個集羣，通過 Raft 協議保持數據的一致性，單個實例失效時，如果這個實例不是 Raft 的 leader，那麼服務完全不受影響；如果這個實例是 Raft 的 leader，會重新選出新的 Raft leader，自動恢復服務。PD 在選舉的過程中無法對外提供服務，這個時間大約是3秒鐘。推薦至少部署三個 PD 實例，單個實例失效後，重啓這個實例或者添加新的實例。
TiKV
TiKV 是一個集羣，通過 Raft 協議（raft一致性哈算法以及Raft 爲什麼是更易理解的分佈式一致性算法 ）保持數據的一致性（副本數量可配置，默認保存三副本），並通過 PD 做負載均衡調度。單個節點失效時，會影響這個節點上存儲的所有 Region。對於 Region 中的 Leader 結點，會中斷服務，等待重新選舉；對於 Region 中的 Follower 節點，不會影響服務。當某個 TiKV 節點失效，並且在一段時間內（默認 30 分鐘）無法恢復，PD 會將其上的數據遷移到其他的 TiKV 節點上。
四 TiDb技術內幕
1 保存數據 TiDB 技術內幕 - 說存儲
2 計算（很關鍵如何做sql運算） TiDB 技術內幕 - 說計算
3 調度(Tidb集羣管理) TiDB 技術內幕 - 談調度
五 安裝部署
tidb安裝部署，可能比較麻煩，一步步照着做，如果公司有專門的運維，這個工作可以由運維來搞，但是大多數的中小公司是沒有的，都是開發者兼職運維，所以作爲一個開發者，還是瞭解下比較好。 安裝部署
聲明
以上只是對tidb資料的簡單整理和對tidb的一個基本瞭解，更詳細的資料可以轉至tidb的官方文檔，注意裏面的常見問題和解答，很有用：PingCAP Tidb官方文檔
轉載自 15分鐘瞭解TiDB