一 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，從應用的角度看，會出現單次請求失敗的情況，重新連線後即可繼續獲得服務。單個例項失效後，可以重啟這個例項或者部署乙個新的例項。
pdpd 是乙個集群，通過 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的乙個基本了解，更詳細的資料可以轉至tidb的官方文件
六 tidb 的典型的應用場景是：
(1) 原業務的 mysql 的業務遇到單機容量或者效能瓶頸時，可以考慮使用 tidb 無
縫替換 mysql。tidb 可以提供如下特性：
吞吐量、儲存和計算能力的水平擴充套件
水平伸縮時不停服務
強一致性分布式 acid 事務
(3) 大資料量下，資料增長很快，接近單機處理的極限，不想分庫分表或者使用資料庫中介軟體等對業務侵入性較大、對業務有約束的 sharding 方案。
(4) 大資料量下，有高併發實時寫入、實時查詢、實時統計分析的需求。
(5) 有分布式事務、多資料中心的資料 100% 強一致性、auto-failover 的高可用的需求。
七 tidb 不適合的場景：
(1) 單機 mysql 能滿足的場景也用不到 tidb。
(2) 資料條數少於 5000w 的場景下通常用不到 tidb，tidb 是為大規模的資料場景
設計的。
(3)如果你的應用資料量小（所有資料千萬級別行以下），且沒有高可用、強一致性或
者多資料中心複製等要求，那麼就不適合使用 tidb。
TiDB 的適用場景和不適用場景
典型的oltp場景 當您需要對海量資料 數十億行 進行隨機 實時讀 寫訪問時 實時 htap 場景 實時htap 混合事務 分析處理 要是有乙個使用tidb的類似oltp的場景，並且希望在tiflash的幫助下原地進行 olap分析時，新鮮的資料，對oltp效能無干擾 資料整合 有多個資料來源時，可...
TiDB適用和不適用場景
tidb 的典型的應用場景是 1 原業務的 mysql 的業務遇到單機容量或者效能瓶頸時，可以考慮使用 tidb 無 縫替換 mysql。tidb 可以提供如下特性 2 大資料量下，mysql 複雜查詢很慢。3 大資料量下，資料增長很快，接近單機處理的極限，不想分庫分表或者使用資料庫中介軟體等對業務...
TiDB適用和不適用場景
tidb 的典型的應用場景是 1 原業務的 mysql 的業務遇到單機容量或者效能瓶頸時，可以考慮使用 tidb 無 縫替換 mysql。tidb 可以提供如下特性 吞吐量 儲存和計算能力的水平擴充套件 水平伸縮時不停服務 強一致性分布式 acid 事務 2 大資料量下，mysql 複雜查詢很慢。3...