從今天開始就準備學習TIDB數據庫，初期基礎差,學習可能會比較困難入門後可能就會好很多
TIDB 是一個分佈式，強一致的可水平擴展的關係型數據庫，在TIDB 設計之初，聚焦了四個設計的要點
1 水平擴展， 在設計之初水平擴展是最基本的需求，通過添加機器的方式擴展，存儲的能力和計算的能力
2 高可用， TIDB 作爲分佈式數據庫，節點衆多，對於節點失效和數據庫滾動升級，需要解決少量節點失效的問題
3 ACID 事務， 雖然部分數據庫爲了更高效的存儲和處理數據，拋棄了SQL和事務，但在生產中的交易場景中，事務是非常重要的，另一個主要的原因在於如果事務的問題不在本地存儲，而是業務解決或者中間件解決，這樣做比較難做到高效
4 SQL 支持，提供MYSQL 的支持，讓整體使用數據庫變得簡單
下面是一張TIDB 的結構圖
TIDB 存儲引擎是TIKV 數據庫存儲引擎，採用了分層的架構來實現
1 transaction
2 MVCC
3 raft
4 local kv storage
容災與特點
高度分層，底層爲ROCKSDB，通過raft來進行數據存儲的高可用， 高度分層的主要原因是可以更獨立的進行層次的切換。通過多副本的方式進行數據的存儲，通過raft 進行強一致，多個副本中只有一個leader 其他節點爲follower，其中leader 和follower值不固定的，在leader失效後，會選擇follower通過算法變爲leader的角色變換。
Raft 本身是支持一份數據的強一致的多副本，分佈式數據如何切片，如何將不同的切片放到不同的位置上，這就需要一個分片的算法，基於hash的分片，或者基於range 劃分，但由於數據庫在查詢中會涉及到一段連續值的查詢的可能，則利用range分片比較合理。將存儲KEY 的空間進行切分，主要根據KEY VALUE存儲的閾值來進行，默認96MB進行數據的切分。
下圖是一個多節點中某個節點 region 從節點 1 到 節點4的過程
則問題是在數據的遷移中，誰主導了整體遷移的操控，Placement Driver集羣主導了。
具體可以看上圖，另外在事務模型中，PD 的leader 會根據時間算法提供時間戳，作爲事務的標籤，整體以去中心化爲設計理念。在TIDB 中3.0前以樂觀鎖爲鎖的設計，在數據事務處理中並不會上鎖，而是在提交的過程中上鎖。3.0提供了悲觀鎖，類似傳統數據庫的鎖設計。
3 TIDB SQL 引擎
下圖是一張TIDB SQL 層的整體的圖形。
整體的SQL 處理流程， 如果是計算 COUNT ， 則TIDB PD獲知這些數據在那個 region 中，region 根據where 條件，將符合的條件的數據進行累加和，最終每個region將自己的累加和彙總到 TIDB SERVER ,在進行聚合SUM。
4 DDL 在線修改，TIDB 根據 f1-schema-change 的思想來設計整體DDL 操作。具體可以參考下面的文檔，總結出幾句話
1 給與修改DDL 操作一個時間範圍
2 在DDL 操作中，每個region都會提供兩種狀態,可以刪除和可寫狀態
3 租約的概念，在系統中設定的租約到期後，需要重載SCHEMA
http://disksing.com/understanding-f1-schema-change/
