TiDB

因爲目前的項目把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官方文檔

出處：http://www.javashuo.com/article/p-kpyqzkco-kt.html