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个节点,一个主节点,五个从节点, 分布在两个服务器,分布情况如图所示,(不详解释,直接上图)