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之间断网