TiDB原理與集群架構

Tidb架構

Tidb架構圖，如上圖
主要分為3部分
1.TiKV-Server
    tikv是負責存儲數據，從外部看 TiKV 是一個分布式的提供事務的 Key-Value 存儲引擎。類似map數據結構（鍵值對）
    tikv之間是有心跳的，tikv之間的數據都是互相備份的，可以保證數據一致性
    既然tikv是負責存儲數據的，為什么讀寫速度這么快？？？？
    數據存儲效率還是很高滴，tikv集群內部本身是通過RPC來交互的，，，大家都知道rpc，高性能嘛
    兩點 1.IO操作（隨機讀寫問題）即如何去保證順序讀寫的，類似於leveldb--通過分代解決寫的問題，然后通過布隆過濾器解決讀的問題
         2.數據一致性的問題（Raft算法）這個是開源算法，tikv節點與備份節點的選舉問題
2.PD-Server
    1.存儲集群的元信息的，比如說某個key在哪個節點上
    2.對tikv集群進行調度和負責均衡，包括節點擴容數據自動遷移
    3.分配全局唯一rowid
3.Tidb-Server
    它是一個mysql的數據引擎，負責解析和處理sql，，然后通過pd去找到數據在kv上面的地址，最后與kv交互拿到數據，再返回結果。
    它是個無狀態的節點，本身不存儲數據，只負責計算，並且可以配置節點個數，無限水平擴展，這個類似於k8s的中的rs
    至於服務端連接的話，可以用一下負載組件，比如說HA,nginx，來提供統一的地址

　　

Ti-Spark

Ti-Spark(tidb對應的一種策略)
    這個組件，沒太深入研究，它主要是對大數據操作中復雜的sql進行快速計算，快速的實現海量數據的統計，並且他還同時支持OLTP和OLAP 解決數據同步的問題
    至於什么是OLTP和OLAP
    解釋一下
    OLTP:它是聯機的事務處理----就是說：在盡可能短的時間內返回結果-------對應的就是我們的關系型數據庫-----------比如說mysql，oracle,sqlserver
    OLAP:它是聯機的分析處理----就是說：對歷史數據分析，然后產生決策，針對於海量的數據統計快速的給出結果----比如說數據倉庫---------hive,tidb
這個很強勢。。。

　　

tikv-剖析

IO 隨機讀寫問題

第一個大問題：IO  隨機讀寫問題  ---------損失了一部分讀的性能（最終一致性的問題），提高了大量的寫的性能
首先需要選擇一個map的數據結構的存儲方案  
RocksDB:他是一個任何持久化的存儲引擎（也是基於kv存儲的），是谷歌開源的這么一個項目，底層是lsm樹，他是樹的結合體（樹+跳躍表）
如果大家不清楚RocksDB ，，，那么應該聽過leveldb ，，，，rocksdb是leveldb的一個升級版本   ，
leveldb
他是實現順序讀寫的，是通過層級划分
如圖

　　

ps解答：

leveldb 他有一個非常牛皮的功能，，，數據快照，使得讀取操作不受寫入或其他的任何操作，可在讀的過程中始終看到一致的數據，
在快照的基礎上，實現吧隨機的數據變成順序的數據。

　

寫的問題解決了 ，，，，那么怎么快讀高效的讀取呢

　

leveldb還有一個特性----數據壓縮
布隆過濾器：可以通過非常少的內存，存放很多的key，實現高效的判斷數據是否存在硬盤中，如圖
長條代表布隆過濾器哈

　　

數據一致性

第二個大問題：數據一致性的問題
使用raft算法實現，raft的原理？？
raft是一個分布式的數據一致性算法
它底層是有兩種角色
1.領導
2.隨從者
raft不是tikv之間的數據關系的
raft是A a a A節點里面的主節點+從節點之間的一個數據同步的問題
  選舉問題
1.正常情況下
    如果主節點A宕機了，兩個從節點a 要進行選舉，怎么選舉，從節點a 向其他從節點發通知（請求選票）,
    如果出現了選票相等的情況，再過300ms，再次選舉，最遲在第二次就會成功。
    為了防止出現這種平等選票地情況,配置文件可以配置是不是候選人，只有候選人才可以讓別人投票
2.非正常情況下（網絡原因，腦裂問題）
假設A一共有6個節點，一個主節點，五個從節點， 分布在兩個服務器，分布情況如圖所示，（不詳解釋，直接上圖）

　　

C,C2,C3分別為不同的客戶端請求，如果KV1與kv2之間斷網